Dyamic allocation of files using PUTENV

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.