Dyamic allocation of files using PUTENV

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

1. Regarding your allocation questions:

It doesn't matter what properties your dsn has as all you're doing with this C++ program called PUTENV is changing COBOL's DDNAME-to-DSNAME assignment (the environment variable) the 1st time before you perform I/O on the file. I did RECFM=FB and DSORG=PS and LRECL=083 but the dsn properties should not matter.

2. In your code above when you display the file-name you gave me:

FILE-NAME:DINAMIC1=DSN('AVE0288.DYNALLOC.TEST.FILE')

However I don't see the SHR and the X'00' which come after the DINAMIC1=DSN('AVE0288.DYNALLOC.TEST.FILE')--did you forget this when you did COPY/PASTE ?

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

yep, I forgot it...
indeed, it displays
DINAMIC1=DSN('AVE0288.DYNALLOC.TEST.FILE') SHR

The working is
01 WS-DYNA-FILE.
10 WS-DYNA-FILE-DSN.
15 DDNAME PIC X(08) VALUE 'DINAMIC1'.
15 FILLER PIC X(06) VALUE '=DSN('''.
15 DSNAME PIC X(55) VALUE SPACE.
15 FILLER PIC X(05) VALUE ' SHR '.
* NULL TERMINATED STRING NEEDED BY C ROUTINE
15 FILLER PIC X(01) VALUE X'00'.

10 WS-DYNA-FILE-PTR POINTER.
10 WS-RC PIC S9(9) BINARY VALUE +0.

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

there are more spaces between the DSNAME and the SHR than displayed above... it seems that HTML cuts off extra blanks and so they are not displayed in the message above

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

The COBOL/3 compiler that I'm using is IBM Enterprise COBOL for z/OS 3.3.1

My compiler options (for my main program called DYNALLTS which CALLs the inner nested program DYNALLOC) are:

PP 5655-G53 IBM Enterprise COBOL for z/OS 3.3.1
Invocation parameters:
F(I,W),LIST,MAP,NOSEQ,XREF,LIB,TEST(NONE,SYM,SEPARATE)
Options in effect:
NOADATA
NOADV
APOST
ARITH(COMPAT)
NOAWO
BUFSIZE(4096)
NOCICS
CODEPAGE(1140)
NOCOMPILE(S)
NOCURRENCY
DATA(31)
NODATEPROC
NODBCS
NODECK
NODIAGTRUNC
NODLL
NODUMP
NODYNAM
NOEXIT
NOEXPORTALL
NOFASTSRT
FLAG(I,W)
NOFLAGSTD
INTDATE(ANSI)
LANGUAGE(EN)
LIB
LINECOUNT(60)
LIST
MAP
NONAME
NSYMBOL(DBCS)
NONUMBER
NUMPROC(NOPFD)
OBJECT
NOOFFSET
NOOPTIMIZE
OUTDD(SYSOUT)
PGMNAME(COMPAT)
RENT
RMODE(AUTO)
NOSEQUENCE
SIZE(MAX)
SOURCE
SPACE(1)
NOSQL
NOSSRANGE
NOTERM
TEST(NONE,SYM,SEPARATE)
NOTHREAD
TRUNC(OPT)
NOVBREF
NOWORD
XREF(FULL)
YEARWINDOW(1970)
ZWB

-----------------------------------------------------------

The BINDER that I'm using is: z/OS V1 R6 BINDER.

My BINDER PROCESSING Options are:

ALIASES NO
ALIGN2 NO
AMODE UNSPECIFIED
CALL YES
CASE UPPER
COMPAT UNSPECIFIED
DCBS NO
DYNAM NO
EXTATTR UNSPECIFIED
EXITS: NONE
FILL NONE
GID UNSPECIFIED
HOBSET NO
LET 04
LINECT 060
LIST SUMMARY
LISTPRIV NO
MAP YES
MAXBLK 032760
MSGLEVEL 00
OVLY NO
PRINT YES
RES NO
REUSABILITY UNSPECIFIED
RMODE UNSPECIFIED
STORENX NO
TERM NO
TRAP ON
UID UNSPECIFIED
UPCASE NO
WKSPACE 000000K,000000K
XCAL NO
XREF YES
***END OF OPTIONS***

My BINDER SAVE MODULE Attributes are:

AC 000
AMODE 31
DC NO
EDITABLE YES
EXCEEDS 16MB NO
EXECUTABLE YES
MIGRATABLE YES
OL NO
OVLY NO
PACK,PRIME NO,NO
PAGE ALIGN NO
REFR NO
RENT NO
REUS NO
RMODE ANY
SCTR NO
SSI 58342C90
SYM GENERATED NO
TEST NO
XPLINK NO
MODULE SIZE (HEX) 00002128

I hope this helps.

By the way, just in case you want to do it the REXX way: I'm a REXX Expert and I have implemented this functionality in REXX many years ago but it was a big complex long-drawn-out solution and this PUTENV IS SO MUCH SIMPLER AND MUCH MORE STRAIGHT-FORWARD. (Also I am a BAL expert as well, and this could be done using SVC99, but this extreme overkill compared to this much simpler PUTENV solution !)

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

Found the solution!!! (not me, someone very knowledged workmate did...)
it was necessary to add option NODYNAM to the cobol compiler so it links the routine in compilation time and not at run time....

Thanks a lot for your help!!!!!!!!!!!!!

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

Great !!!

And if you look at my last post: I gave you the COMPILE and BINDER options. And I have NODYNAM in the COMPILER options.

Also you can go back to static CALL if you like--dynamic CALL wasn't necessary.

Take care.

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

I'm seeing now your posted message with your compiler options... I didn't see it before... sorry

I have done dynamic allocation in REXX with
ALLOC DA('DATA.SET.NAME') F(FSEARCH) SHR REUSE
EXECIO 0 DISKR (OPEN
EXECIO 1 DISKR (FIFO
EXECIO 1 DISKW
etc...
commands ..

isn't possible to call IDCAMS utility from a COBOL? , in that way maybe dynamic allocation could be done as well...

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

First the political:

Yes, BUT your manager may go berserk (ballistic) like mine did because:

Most shops ONLY have COBOL programmers and NO REXX coders and mgr ALSO knows COBOL so you're going to have a tough FIGHT on your hands.

Also, your operations staff may not like this approach and/or may have their own approach: My advice is don't tell them otherwise you're asking for trouble !

---------------------------

Now for the technical:

Yes you can do IDCAMS in COBOL but you have to CALL the IDCAMS interface and pass it a proper parmlist and check all 3 return-codes coming back.
I've read about this but I haven't done it but I think you may have addressing-mode problems but I'm not sure here.

I still think this PUTENV approach is a SIMPLIER approach that is MANAGER FRIENDLY AND OPERATIONS FRIENDLY.

What do you think ?

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

Also:

You can embed REXX code within your COBOL program because REXX is a SAA language.

I've never done it but I've read about it and seen it in the manuals.

However CALLing IDCAMS or REXX is not a good solution because then you couldn't have a NATURAL TRADITIONAL COBOL OPEN/READ/CLOSE--in other words, you couldn't hook up the IDCAMS/REXX allocation with the COBOL I/O VERBS and the SELECT-ASSIGN and the FD/"01" !

Hence, because of the above reasons, I believe that PUTENV is a more pleasing and easier to swallow solution in a COBOL shop (because mgrs are always worried about: what if you, the only REXX coder, leave the firm--then who will support this inventory--if it's COBOL-like then it's easier to maintain and there's more coders who know COBOL than REXX).

What do you think ?

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

I do not have too much experience in the mainframe world (working almost for 2 years so far) , so everything you tell me is very educational to me.

In fact, I agree with you about Rexx is not so popular and so could not be well accepted by mgrs. Also, as I guess Rexx is not a full-compiled language but a "interpreted" language, maybe the performance of a Rexx program wouldn't be as good as a COBOL one, what is your opinion about that?... and also is important what you tell me about that with Rexx or IDCAMS option then is not possible to use OPEN, READ etc COBOL verbs...
But perhaps I see useful to call Rexx code from COBOL, specially for some built-in functions available in Rexx that makes it a "modern" language. For example for string handling, where it has several functions for string searching, pattern matching, etc... if those routines could be called from a COBOL program (and be able to get the function result of course), then would be pretty useful...

I have a document with another way to do dynamic allocation, but too much more complex than PUTENV. I'll search it and paste it here...
By the way, I think would be good to know what is the functionality of the other functions in SCEELKED, I'm sure there are lot of useful stuff there...
Is out there any guide that expains how to use each one?...

Thanks!, see you

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

You're pretty knowledgeable for only 2 years !

REXX Language from IBM is typically an interpreted language unless ... see below.

Also REXX can only work with sequential and PDS; it cannot work with VSAM and DB2 unless....see below.

EXCEPTION to Compilation: If the company installs REXX/370 in foreground option 4, THEN YOU CAN COMPILE REXX !!!

IF COMPANY BUYS REXXTOOLS (it's a vendor product) THEN YOU CAN ACCESS VSAM AND DB2 IN REXX !!!

The "other document" you have probably involves ASSEMBLER and SVC99 which I've done in the past but PUTENV is so much more simpler.

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

well, I have a question regarding dynamic file atributes...
The issue is that when I declare FD for the dynamic file I have to state the LRECL , as for example
FD DYNA-FILE
RECORDING MODE IS F
LABEL RECORD STANDARD.
01 DYNA-FILE-REC PIC X(80).

Then, if the file I'm opening dynamically has different lrecl than the one declared in FD statement (80 in the example), I get a 39 file status error..
So my question would be how can I know the lrecl of the file that I'm opening dynamically and after that how can I set the FD "at run-time" in a properly way?...

Thanks!

William Thompson · Posted: Tue Dec 12, 2006 1:27 am

Recfm U and deblock as needed?

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

Just got back from lunch and got your 2 posts.

Working on this...will let you know.

I think you'd add to the string the LRECL and RECFM operands but I'm not sure and have to test this first.

-------------------------------

To get the lrecl before opening you could capture "01-name (-3:2)" against a pre-defined "01" but this is not totally dynamic--I'll have to get home--I'm at work now--and check my "mainframe library and listings" and get back to you on that.

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

Will get back to you on this later tonight...I'm busy at work now...thanks for your understanding.

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

Tried adding the LRECL and RECFM to the DYNAMIC ALLOCATION string but got error:

FILE-NAME = PMNF.S.MNFD498.AICTRANS.BKUP.G0167V00')

ENV-VAR PASSED STRING = DALDUMMY=DSN('PMNF.S.MNFD498.AICTRANS.BKUP.G0167V00') LRECL(083) RECFM(FB) SHR

IGZ0251W An invalid keyword LRECL was found at position 61 in environment variable DALDUMMY while processing file

DYNAMIC-OPEN-FILE in program DYNALLTS.

***** OPEN ERROR, DSN= PMNF.S.MNFD498.AICTRANS.BKUP.G0167V00 ; STATUS = 98

I think this happens because we can only change the DD-to-DSN connection by updating this environment variable; but the LRECL and the RECFM have nothing to do with this connection and environment variable.

On the other issue (how to get the dynamic-file length):

Using the LENGTH COBOL special register on the FD's "01" definitely works. The 01-area (-3:2) technique only works for variable but we have fixed in our example.

I think the way to do this is to change RECORDING MODE TO U (which means Fixed or Variable and DON'T supply BLOCK CONTAINS because RECFM=U cannot have BLOCK CONTAINS) and then convert the 01-area to an occurs from 0 to 65535 depending on a working-storage halfword binary field ( S9(4) BINARY ) which you'll load with the highest-possible number that can fit in a halfword which is 65535 because you want max allocation for the I/O and because you don't want SOC4.
Then after a good OPEN and a good READ, the working-storage halfword binary field will contain the actual record length which you can then DISPLAY.

Check it out and let me know...thanks.

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

Wow!...
I'll try to understand and code what you tell me...

Besides, while I try the solution you provided me, I have another question:
How could be done to get the name of a dataset from a DD?
I mean, for example, if there is some JCL like:

//pgm exec pgm=DDLOOKUP
//FILEIN DD DSN=dataset1,DISP=SHR
//FILEIN DD DSN=dataset2,DISP=SHR
//FILEIN DD DSN=dataset3,DISP=SHR
//FILEIN DD DSN=dataset4,DISP=SHR

and then I would like DDLOOKUP to iterate thru each FILEIN DD, get the DSN name and process it...
How could I do this?... it's also some sorta of dynamic allocation I guess..

We have these kind of JCLs created "on the fly" by COBOL programs, where the number of DDs is undefined but depend on the COBOL program logic that creates the JCL ...

I hope you can understand me...

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

First a clarification on my previous post:
In the program, after you convert to RECFM un-blocked and to the occurs-depending on that I gave you, you can pass any fixed or variable file into your program and open it--I think I might have mislead you into thinking that the input file has to be RECFM=U--it does NOT have to be RECFM=U. RECFM un-blocked in the program is a technique so that any type of file can be OPENed and READ.

I will answer your question in my next post.

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

Answer:

This code will display all of your DD's dataset names.

Code:

IDENTIFICATION DIVISION.
PROGRAM-ID. PROGXX.
INSTALLATION.
AUTHOR. KEVIN.
DATE-WRITTEN. 11/07/2005.

ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.

DATA DIVISION.
FILE SECTION.

WORKING-STORAGE SECTION.
01 TCB-ADDRESS-POINTER.
05 TCB-ADDR-POINTER USAGE IS POINTER.
01 TIOT-SEG-POINT.
05 TIOT-SEG-POINTER USAGE IS POINTER.
05 TIOT-SEG-PNT REDEFINES TIOT-SEG-POINTER
PIC S9(9) COMP.
01 JFCB-POINT.
05 JFCB-POINTER USAGE IS POINTER.
05 JFCB-POINT-RED REDEFINES JFCB-POINTER.
10 FILLER PIC X.
10 JFCB-LOW-3 PIC X(3).

LINKAGE SECTION.
01 DDNAME-DSN-ARRAY.
05 DDNAME-DSN OCCURS 100 TIMES INDEXED BY NDX1.
10 DDA-DDNAME PIC X(8).
10 DDA-DSN PIC X(44).

01 TCB-POINTER USAGE IS POINTER.
01 TCB.
05 FILLER PIC X(12).
05 TIOT-POINTER USAGE IS POINTER.
01 TIOT-START PIC X(24).
01 TIOT-SEG.
05 TIO-LEN PIC X.
05 FILLER PIC X(3).
05 DD-NAME PIC X(8).
05 JFCB-ADDR PIC X(3).
01 JFCB.
05 FILLER PIC X(16).
05 DS-NAME PIC X(44).

PROCEDURE DIVISION USING DDNAME-DSN-ARRAY.
MOVE LOW-VALUES TO JFCB-POINT.
MOVE X'0000021C' TO TCB-ADDRESS-POINTER.
SET ADDRESS OF TCB-POINTER TO TCB-ADDR-POINTER.
SET ADDRESS OF TCB TO TCB-POINTER.
SET ADDRESS OF TIOT-START TO TIOT-POINTER.
SET TIOT-SEG-POINTER TO TIOT-POINTER.
ADD 24 TO TIOT-SEG-PNT.
SET ADDRESS OF TIOT-SEG TO TIOT-SEG-POINTER.
SET NDX1 TO 1.
PERFORM UNTIL TIO-LEN = LOW-VALUES OR NDX1 > 100
MOVE DD-NAME TO DDA-DDNAME(NDX1)
MOVE JFCB-ADDR TO JFCB-LOW-3
SET ADDRESS OF JFCB TO JFCB-POINTER
MOVE DS-NAME TO DDA-DSN(NDX1)
DISPLAY DDA-DDNAME(NDX1) DDA-DSN(NDX1)
ADD 20 TO TIOT-SEG-PNT
SET ADDRESS OF TIOT-SEG TO TIOT-SEG-POINTER
SET NDX1 UP BY 1
END-PERFORM.
GOBACK.

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

well... I'm really learning...
before go and paste the code in a program, I would like to understand what it is doing, so... :
what is the TCB?
what is the TIOT?
what is the JFCB?
what does it reference X'0000021C' address? why it is hardcoded-fixed? is it the TCB always there?

Sorry for to many questions!!...

acevedo · Active User Joined: 11 May 2005 Posts: 344 Location: Spain

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

I actually got this code from prior posts.

They are internal MVS Control Blocks/Structures.

Don't worry about all of this coding--this is a "tried and true" method of "dumping/displaying" all of your JCL's DD-DSN assignments--I myself have used it for many years--it's just a black box that is always guarenteed to work.

To answer your question:

TCB = Task Control Block
TIOT = Task Input-Output Table
JFCB = Job File Control Block

TCB+21C points to TIOT.
TIOT contains an array of DD names.
TIOT points to the JFCB.
JFCB contains an array of DSN names.
As we bump the TIOT and the JFCB, we extract the DD-to-DSN assignments from your JCL.

Again, don't worry--just use it--it's always guarenteed to work.

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

Where can I look at in order to get the whole layout of these structures(TCB, TIOT, JFCB)? , I mean, some online documentation or book...

Also, what is the relation between these structures and PUTENV? , is PUTENV updating some of these structures? (I think ASSIGN TO DYNAFILE as an additional DD to the TIOT and the DSN of the dynamic file as added to a JFCB entry...)

See you,

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

MVS Data Areas manual.

I think there's no relationship between MVS-control-blocks and PUTENV as PUTENV's requirement is "FILE MUST NOT EXIST IN THE JCL" and the MVS-control-blocks method ONLY looks at the JCL (aka TIOT); however, I'm not sure.

PUTENV is updating the environment variable that corresponds to the DDNAME in the SELECT/ASSIGN clause.
I'm pretty sure that this environment variable INITIALLY points to a NON-JCL allocation.
However, I'm not sure if AFTER you have a successful PUTENV as to whether or not this allocation is "added" to the JCL (aka TIOT)--however I can check this out for you and get back to you !

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

I tried the record format = U way and I still get 39 error.
Here is my coding, perhaps I made something wrong:

SELECT DYNA-FILE ASSIGN TO DYNAMIC1
FILE STATUS WS-FS-DYNA-FILE.

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 32767 TIMES
DEPENDING ON
WS-DYNA-FILE-INDEX.

10 WS-DYNA-FILE-INDEX PIC 9(5) BINARY VALUE 32767.

And this is the Info of the files I'm trying to open dynamically:
Management class . . : TSOSMAL Allocated cylinders : 1
Storage class . . . : TSO Allocated extents . : 1
Volume serial . . . : TSS508
Device type . . . . : 3390
Data class . . . . . : **None** Current Utilization
Organization . . . : PS Used cylinders . . : 1
Record format . . . : FB Used extents . . . : 1
Record length . . . : 80
Block size . . . . : 27920
1st extent cylinders: 1
Secondary cylinders : 10
Data set name type : SMS Compressible : NO

I didn't use 65535 as I got a compiler error telling that the maximum value can be 32767...

Thanks!