Dyamic allocation of files using PUTENV

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

Sorry , the FD statement is:
FD DYNA-FILE
RECORDING MODE IS U
RECORD IS VARYING IN SIZE FROM 1 TO 32767 CHARACTERS
DEPENDING ON WS-DYNA-FILE-INDEX.
01 DYNA-FILE-REC.
10 DYNA-FILE-REC-BYTE PIC X(1) OCCURS 1 TO 32767 TIMES
DEPENDING ON
WS-DYNA-FILE-INDEX.

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

Sorry...no time for this today...have some deadlines to meet.

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

Were you able to to look at the file status 39 issue? ... any advice to get rid of it?

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

Still lots of deadlines now...will be busy all night and all weekend...this is the life of a programmer !

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

ok, thanks! ... I'll wait so...
Let me know if you need some help! :-) ...

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

It was the Holidays and I was away and on Jan 2nd we were off due to market closed due to Gerard Ford; and I just got back and caught up.

Change "RECORD IS VARYING IN SIZE FROM 1 TO 32767 CHARACTERS"
(which means ONLY VARIABLE) to "RECORD CONTAINS 1 to 32767 CHARACTERS" (which means FIXED or VARIABLE which is what RECORDING MODE U means); and then re-run--problem should disappear.

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

Actually I just did some testing:

- I tried that fix and I got same result: the file-status = 39
- then I tried many other coding permutations and kept getting file-status = 39

Maybe you can have multiple different sized "01"'s in the "FD". One of the "01"'s would be the actual size of your fixed or variable sized file and the other one would have the max of 32K. Then you'd use the 01-area
(-3:2) to dump the record-length for the variable file; and you'd use the LENGTH OF special register to dump the record-length for the fixed file.

Can you please try this and let me know ?

I think this would probably work but then it would be too hard-coded and not the dynamic solution that we both desire.

Let me know. Thanks. Take care.

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

well,.. I'm trying to orginize my ideas...
Actually, I was able to open the file if the file has been created Record format = U , for example doing
FD DYNA-FILE
RECORDING MODE IS U ( RECORDING MODE IS V also worked)
RECORD CONTAINS 1 TO 32767 CHARACTERS.
01 DYNA-FILE-REC.

But I was not able to open the file when the file has been created Record format = VB , neither as
FD DYNA-FILE
RECORDING MODE IS V
RECORD IS VARYING FROM 1 TO 32767
DEPENDING ON
WS-DYNA-FILE-INDEX.
01 DYNA-FILE-REC-MIN PIC X(1).
01 DYNA-FILE-REC-MAX PIC X(32767).
01 DYNA-FILE-REC PIC X(80).

Indeed, if with some FD declaration I would be able to open fixed, with another FD would be able to open variable, and with another FD declaration would be able to open U , then I could code 3 different SELECT clauses and 3 different PUTENV , one for each FD type, and try opening the file with each one until one doesn't fail... But I was not able to open VB ... also if the file is fixed but record length declared in FD is different from the one the file has been created, 39 error also...

Really, I would like to open any kind of file, of any length, just with a FD declaration, (or as few FD declarations as possible) , so the program is all the dynamic as possible...

I thought that with a RECORDING MODE V , RECORD CONTAINS x TO y , would be possible to open either fixed or variable files...

Well, I'm learning about all this stuff, and keep trying...
Please let me know if you find something...

See you

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

This knowledge is way beyond an Applications Programmer's job but here are 2 design ideas (and I've only read about them but I have never have done them):

1. Search your shop to see if they have an assembler program that CALLs SVC99 and that accepts parms. Figure out how to pass it parms for DDNAME and DSNAME and for DISP=SHR. Then CALL it with parms and test the return-code coming back and only proceed if return-code is OK.

Issues:

a. Does this process replace the COBOL Select/Assign/FD/"01" and the COBOL OPEN ?

I'm not sure.

b. Can you perform a COBOL READ against this SVC99 Allocation ?

I'm not sure.

Note: If you cannot find this SVC99 assembler program in your shop: Search the TSOTIMES WebSite for an article that has the SVC99 assembler code and make your own.

*** OR if you cannot find this SVC99 assembler program, then do this ***

2. Search this site for how to CALL REXX from COBOL (use an IRXJCL REXX which doesn't require the ISPF/TSO platform to be setup, NOT the IRXEXEC REXX). Create a REXX that allocates an existing dataset via supplying DDNAME, DSNAME and DISP(SHR).

Issues:

a. Does this process replace the COBOL Select/Assign/FD/"01" and the COBOL OPEN ?

I'm not sure.

b. Can you perform a COBOL READ against this REXX Allocation ?

I'm not sure.

ruhamah lam · New User Joined: 23 Jan 2007 Posts: 1 Location: hong kong

May I ask if "IBM Enterprise COBOL for z/OS 3.4.1" have the "PUTENV".

I want to dynamic allocate a certain file from a list of files if condition fullfilled. Before, I write a PL/I program to do it, but now I need to rewrite it to COBOL.
How do I convert it. Do COBOL have file variable concept ?
The code is simplified as follows.

Thx a lot
===============================================
DCL (FILE01,FILE02,FILE03,FILE04,FILE05)
KEYED SEQUENTIAL INPUT RECORD FILE ENV(VSAM ...);
DCL FILEMT(MXFILENO) FILE INIT (FILE01,FILE02,FILE03,FILE04,FILE05);
ON ENDFILE(FILEMT(1)) EOFSTMT(1) = '1'B;
ON ENDFILE(FILEMT(2)) EOFSTMT(2) = '1'B;
ON ENDFILE(FILEMT(3)) EOFSTMT(3) = '1'B;
ON ENDFILE(FILEMT(4)) EOFSTMT(4) = '1'B;
ON ENDFILE(FILEMT(5)) EOFSTMT(5) = '1'B;

DO WHILE (...);
......
OPEN FILE(FILEMT(CNT));
......
CALL DYNA_STMT(1,CNT);
/* an asembly user program to dynamic allocate file) */
......
READ FILE(FILEMT(CNT)) INTO(....) KEY(....);
END;
===============================================

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 ?