Dyamic allocation of files using PUTENV

dick scherrer · Posted: Sat Apr 28, 2007 5:28 am

Hello Al,

Last things first - i'll send a note and ask how the title might be changed - i may even have the ability, but just don't know how.

b.

galecra · New User Joined: 11 Sep 2006 Posts: 33

I have tried and processed file dynamically by calling IKJEFTSR thru COBOL...
but keeps similar problems as putenv... as the allocated file and the "FD" file must be of the same record length...
I guess rexx does not have this problem because there is no "FD" file... just allocate and perform execio over the allocated file...

dick scherrer · Posted: Thu May 03, 2007 6:54 am

Hello,

Yes, COBOL was designed to work with known resources. REXX, tso/ispf, sort, etc were designed to be dynamic.

What kind of functionality do you want in the "dynamic allocation" code?

galecra · New User Joined: 11 Sep 2006 Posts: 33

Nothing specific. In my case it's just research to learn something new...
At work, there are some programs that accept a dynamic quantity of input files. All of them stated by the same DD name in the jcl , and the jcl is dynamically created with the input DD's for each specific run... the open and read of each of these DD's is performed by assembler routines called by a cobol program... so one reason of my research was trying to know if there is a better/easier/nicer/etc way to do this other than assembler...
(I know that sometimes assembler could be the best way to do something, but to be honest, few people know it, I don't know it, I have not been taught in assembler at school , neither managers set time for us to do it..)

for example:
//exec pgm=dynamic
//ddinput dsn=file1
//ddinput dsn=file2
//ddinput dsn=file3

and the program open and processes the files one by one ...

dick scherrer · Posted: Thu May 03, 2007 8:25 pm

Hello galecra,

In your case, it sounds like learning assembler will be "on your own" (which is why there are nights and weekends

).

Depending on how deep you want to go into assembler, you might start by compiling a simple COBOL program and look at the generated assembler. This is not the way you would write code, but you can get an appreciation of what instructions were generated to accomplish different COBOL statements.

From my perspective, there are 2 main types of assembler code - application code and "system support" code. There are places that still have their application inventory written in assembler (there is rarely a new organization that uses assembler for applications). Assembler applications are quite similar to COBOL apps - just the syntax is different. They typically do not use instructions that work directly with the operating system.

System support code (database engines, sorts, terminal monitors, communicatin software, utilities) typically uses more complex code and there is usually a need to know the relationship of system control blocks.

The kind of code that will deal with files that are "undefined" in the source is more of a utility than an application program.

For this

adiovanni · New User Joined: 22 Nov 2006 Posts: 40 Location: USA

Dick Scherrer: Thanks for changing this thread's title to PUTENV.

Both:

The requirement that Galecra has, which is that we have lots of input dsns but their names keep changing every run, in my opinion, is a VERY COMMON business applications requirement--I had this need a few years ago and then again about 3 months ago; however, for both of these times, their file layouts were the same and we could use the RECFM=FB approach (actually, the first time, I used the all-REXX-approach--but it was not REXX within COBOL). So hence your FIXED requirement is a very good candidate for PUTENV (my original version).

Now when those dsns have DIFFERENT FILE LAYOUTS and hence DIFFERENT LRECLS, as we've observed, RECFM=U causes everything to break.

Hence, for this DIFFERENT FILE LAYOUTS case, either hardcode all of the possible FIXED layouts and do PUTENV against each one of them (AND I WILL TEST THIS TODAY TO SEE WHAT HAPPENS, WHAT'S REQUIRED, BUT I'M PRETTY SURE IT WILL WORK);

- OR -

If you cannot standardize on all of the possible FIXED layouts then...

Your existing BAL solution should be employed (or a BAL solution or a REXX solution or a REXX-within-COBOL solution).

dick scherrer · Posted: Thu May 03, 2007 9:52 pm

You're welcome

As far as the "same file" with many dsns, what i've seen implemented several places is that the jobs creating the "common" data create an entry in a GDG that is used as input to the job needing the various input files.

Each time the "file" is read, all of the cataloged generations are read. Every time they are read, the entire collection of GDG entries is deleted and one new "empty" version/file is created. If the data from all of the files is needed for backup, a full copy is made before deleting the GDG versions.

A couple of the places i've supported had between 100 and 350 distribution sites that uploaded sales and inventory activity every day. Due to one thing and another, the number of inputs was not predictable. Before we changed the process, the jcl was modified every day to only include those locations that had transmitted a file. This was unmanagable. By using a common GDG, we were able to remove a very convoluted process (also had to deal with the case where multiple files were sent from the same location on the same day).

Maybe this will offer an alternative for some of the current "opportunities".

adiovanni · New User Joined: 22 Nov 2006 Posts: 40 Location: USA

I hardcoded all of the possible FIXED layouts (2 in my case) and I did a PUTENV against each one of them and everything worked out OK.

dick scherrer · Posted: Fri May 04, 2007 5:38 am

Cool

adiovanni · New User Joined: 22 Nov 2006 Posts: 40 Location: USA

Took a long time due to compiles running very slowly today.

So what country r u from Pink Panther ? I'm from USA.

dick scherrer · Posted: Fri May 04, 2007 5:48 am

Hi Al,

I, too, am from the USA.

And that would be Inspector Clouseau

For extra credit, do you recognize the street address?

adiovanni · New User Joined: 22 Nov 2006 Posts: 40 Location: USA

Sherlock Holmes' and John Watson's London address under the rent of Ms Hudson (and Sherlock was a consulting detective ?)--I cheated...I used GOOGLE, btw.

Anyway going home now...speak with u tomorrow.

dick scherrer · Posted: Fri May 04, 2007 6:58 am

Heh heh heh - not cheating - just resourceful

Have a good evening

TG Murphy · Posted: Sat May 12, 2007 12:41 am

This was an interesting thread. It is always an eye-opener to see what other folks are up to.

We have being using PUTENV in production for about 2 years now. It works great.

In our source library I counted 20 Assembler programs that do dynamic file allocation - 19 of these programs are specific and cannot be reused by others. But one is a generic Assembler program - the guy did a really nice job with it. It can do everything PUTENV can do plus a few more things that it can't.

However, since discovering the Assembler routine, we have not needed it. PUTENV and REXX are able to handle all situations so far.

Unfortunately, the Assembler utility is only available to the group that wrote it. If we want to use it, we have to clone and rename. Nice to know it is there if PUTENV or REXX isn't up to the task.

REXX is awesome. Last time I checked dynamic file allocation via REXX I could not make it work with tape files. Is it possible?

adiovanni · New User Joined: 22 Nov 2006 Posts: 40 Location: USA

I'm recalling 6 1/2 yrs ago when I did this in REXX (and I'd have to check my inventory at home--I'm at work now), but I'm pretty sure you're right: REXX cannot handle TAPES.

jasorn · Active User Joined: 12 Jul 2006 Posts: 191 Location: USA

I couldn't figure out how to open a pds with putenv so I wrote a program that using the bpx* program. Or whatever it is. I forgot now. Seems to work better so I've been using it instead.