Dyamic allocation of files using PUTENV

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

Please refer to my post dated Thu Nov 23, 2006 3:13 am (and other posts after that if you need to).

I don't know PL/1 but I know this COBOL example works as I've tested it on my system; and I've helped another poster get his code working on his system.

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

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

Great job and great tech tip.
Will try this out myself later tonight.

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

Got the dynamic case of this utility to work thanks to your help.

For the dynamic file file-status, you must additionally say that the "04" file-status is OK; for example:

77 DALDUMMY-STATUS PIC X(02) VALUE SPACES.
88 DALDUMMY-STATUS-OK VALUE '00' '04'.

My FD:

FILE SECTION.
FD DYNAMIC-OPEN-FILE
RECORDING MODE IS U
RECORD CONTAINS 0 CHARACTERS
LABEL RECORDS ARE STANDARD.
01 DYNAMIC-OPEN-RECORD.
10 DYNA-FILE-REC-BYTE PIC X(001)
OCCURS 0 TO 32767 TIMES
DEPENDING ON
WS-DYNA-FILE-INDEX.

In my working-storage I have a copybook that I READ INTO which has an "01" level.

In my working-storage, I have:

77 WS-DYNA-FILE-INDEX PIC S9(5) BINARY VALUE +32767.

I could not say READ INTO working-storage-01-area (1:WS-DYNA-FILE-INDEX)--I got S0C4 in that case; rather I had to say READ INTO working-storage-01-area.

I tested this routine with different sized files and I was able to CALL-DYNALLOC/OPEN/READ/display-the-contents/CLOSE each of these files; hence this routine is now TOTALLY DYNAMIC.

Thanks for your help on this. Take care.

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

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

Thanks...This discussion thread contains my program which uses the PUTENV; and these modifications were against that program.

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

Great!... now is opening the file dynamically...
but I'm not getting filled the DEPENDING ON WS-DYNA-FILE-INDEX variable, it always has 32767 ... so when I do a READ I get 32767 characters of data, in spite of the dynamic file I'm opening is 80 lrecl ...

FD DYNA-FILE
RECORDING MODE IS U
RECORD CONTAINS 0 CHARACTERS
LABEL RECORDS ARE STANDARD.
01 DYNA-FILE-REC.
10 DYNA-FILE-REC-BYTE PIC X(001)
OCCURS 0 TO 32767 TIMES
DEPENDING ON WS-DYNA-FILE-INDEX.

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

Great!... now is opening the file dynamically...
but I'm not getting filled the DEPENDING ON WS-DYNA-FILE-INDEX variable, it always has 32767 ... so when I do a READ I get 32767 characters of data, in spite of the dynamic file I'm opening is 80 lrecl ...

FD DYNA-FILE
RECORDING MODE IS U
RECORD CONTAINS 0 CHARACTERS
LABEL RECORDS ARE STANDARD.
01 DYNA-FILE-REC.
10 DYNA-FILE-REC-BYTE PIC X(001)
OCCURS 0 TO 32767 TIMES
DEPENDING ON WS-DYNA-FILE-INDEX.

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

You must have WS-DYNA-FILE-INDEX in your FD and you need to load it with the max size of 32767, but don't reference (1:WS-DYNA-FILE-INDEX) on your READ (it won't work anyway--you'll get SOC4). Rather reference your 1 or more "01"'s in your FD in your READ--they will be correctly sized because of COBOL IMPLICIT REDEFINITION IN THE FILE SECTION ! Let me know if you still have problems.

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

bummer... I don't follow exactly what you are trying to explain me...
I tried using RECORD VARYING IN SIZE FROM 0 TO 32767 DEPENDING ON ... but is not working, compiler says should be from 1 at least...

I have the DEPENDING ON in the 01 section of the FD declaration , what do you mean when you tell me "you must have WS-DYNA-FILE-INDEX in your FD" ...

My FD declaration is :

FD DYNA-FILE
RECORDING MODE IS U
RECORD CONTAINS 0 CHARACTERS
LABEL RECORDS ARE STANDARD.
01 DYNA-FILE-REC.
10 DYNA-FILE-REC-BYTE PIC X(001)
OCCURS 0 TO 32767 TIMES
DEPENDING ON WS-DYNA-FILE-INDEX.

and my READ statement is:

READ DYNA-FILE.
MOVE DYNA-FILE-REC
TO WS-DYNA-FILE-REC
DISPLAY 'WS-DYNA-FILE-REC:' WS-DYNA-FILE-REC
MOVE WS-DYNA-FILE-INDEX TO WS-DYNA-FILE-REC-LEN
DISPLAY 'WS-DYNA-FILE-INDEX:' WS-DYNA-FILE-INDEX

this way the program works, but is reading as much as 32767 bytes (whenever available) each time I do a READ DYNA-FILE statement...

For example, I have a fixed 80 lrecl file with three records (3 lines) , I open this file dynamically and when I do a READ DYNA-FILE I get all the 3 records (lines) read at once , and WS-DYNA-FILE-INDEX set to 32767.
If I'm opening dynamically a 80 lrecl file , then I would like to pick up 80 characters of data each time I do READ DYNA-FILE ...
Could be this possible?... if your code is working as I would want, please let me know your SELECT , FD , and WS declarations!! :-)

Thanks!

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

Cannot do this now due to deadlines and I will probably be here all night catching-up and finishing assignment (sorry)...will revisit this tomorrow.

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

Just experimented with this approach tonight and put in debugging.

This dynamic routine actually does not work correctly: it experiences the symptoms that you described in your prior post: one READ actually reads as many records that will fit in a 32K block because of RECFM=U.

I tried READ INTO and just READ; and I tried setting the ODO from 32767 to 0 but I am still getting the same results.

Maybe we could "deblock" the 32,767 block (by the lrecl, maybe?) and then store these future records in a working-storage table; and then you'd have to modify the CALLing program to CALL you for each READ instead of the CALLing program doing the READS directly, but this approach is probably not practical.

But then if you go back to the prior approach it's not totally dynamic.

So this is an outstandiing issue. Thanks.

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

Ok, thanks...
I have been thinking about the "deblock" approach .
In fact, if the files that are going to be opened dynamically are passed for example as a parameter or by an input control file, there should state the name of the file and the lrecl, so the program can deblock the records properly...
Or, is out there any way to get the lrecl easy for the going to be opened dynamic file? ...

Indeed, I do not understand why this stuff is so difficult to be done by COBOL and is a stright forward thing in REXX .. Maybe doing REXX routines for the operations over the dynamic file, compile them, and calling them from COBOL would be another solution.. never done something like that before (compiling rexx code and calling it from COBOL). And really don't know if this solution would and could be a "production" solution accepted by managers, or would stay just as a try and play ..

See you ...

dick scherrer · Posted: Sat Apr 21, 2007 9:12 am

Hello,

Interesting topic. . . Been watching since the beginning.

I'd like to offer a thought on this

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

Dick Scherrer:

Regarding point#1: This forum thread was actually spawned from my collegue and myself having a real business problem: We were needing to read 1 or more absolute-GDG-goovels but we did't know the actual dataset names--they change all the time so they couldn't be put into the JCL. The actual absolute-GDG-goovel-dataset names are being stored in a parm file. Then I wrote/tested/presented this PUTENV utility to my collegue who used it in his COBOL program and it solved this problem. Note that the layout for all of these goovels was the same.
Then we thought to make this called module dynamic so that any-sized datasets could be opened and read. Then, after lots of permutations, we discovered that only the RECFM=UNBLOCKED approach "worked", but actually it never worked (see previous posts for what went wrong).

Regarding point#2:
I know REXX and IBM BAL well; and I read in IBM Manulas that REXX can be put into COBOL. Two (2) questions:

a. Which approach do you think would be the most SEAMLESS to Applications Developers (note I am also an applications developer)--REXX placed into COBOL program or a BAL CALLed module using SVC99 with parms ? BAL, right ?
But then, if we go with any of these approaches, we'd have to abandon PUTENV, right ?

b. Since you say this can be done easily in REXX and/or BAL, can you please give me some code ?

Different Unrelated Issue: How can I change the name of this thread from GETENV to PUTENV because we're using PUTENV not GETENV ?

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.