Page 2 of 3

Re: Opening an assembler file from a variable

PostPosted: Mon Dec 19, 2011 6:19 pm
by steve-myers
Your program should use the IKJEFF18 service routine to generate fairly reasonable error messages after a dynamic allocation error (reg 15 is not equal to 0). IKJEFF18 is a TSO routine and is documented with TSO, but it has an option to return one or two messages in a buffer that your program can then print; when called in this fashion it runs perfectly in a batch environment. The TS did not state he was using dynamic allocation in the initial post; as I read it the TS did not know about dynamic allocation.

By the way, "To enrico's post I would like to reply that for both the conditions (already existing dataset and insufficient space) the dynamic allocation routine returns same RC" is basically meaningless; the return codes are not the same. Yes, reg 15 is the same, but S99ERROR and S99INFO in the dynamic allocation request block are different. Another issue: "insufficient space" has multiple meanings; many cases of "insufficient space" cannot be detected until you open and write to the dataset; allocation cannot detect this problem.

Another issue for the TS: a field name like x_retcode means nothing to most of us; Enrico is better than me at guessing these things. Use standard field names like S99ERROR. The format of dynamic allocation data areas is in the IEFZB4D0 macro: use this macro when you do dynamic allocation.

If you are not certain if the dataset already exists, you should attempt the allocation twice; first to allocate an existing cataloged dataset and then to allocate a new dataset if the first allocation fails.

Re: Opening an assembler file from a variable

PostPosted: Mon Dec 19, 2011 8:42 pm
by steve-myers
vinodj wrote:Is it possible to associate an already existing dataset name with a DCB in assembler?
You have the cart before the horse. The purpose of a DCB is to connect a program to a dataset using just the DD name in the DD statement that specifies the dataset.

Yes, it is, provided the dataset is allocated. You can use code like this to retrieve the dataset name of an allocated dataset.
         RDJFCB (DCBADDR)
         MVC   DSN,JFCBDSNM
         ...
DCBADDR  DCB   DSORG=PS,MACRF=GL,
               DDNAME=xxx,EXLST=XLISTADD
XLISTADD DC    0A(0),AL1(X'87'),AL3(JFCBADDR)
JFCBADDR DC    0XL176'00'
         IEFJFCBN ,
         ...
MSG      DC    0CL80'THE DATASET IS '
         DC    C'THE DATASET IS '
DSN      DC    CL44' ',CL(80-(*-MSG))' '
Obviously, the first line of the DCB needs continuation flags, which we can't easily do here. The 0A(0) in XLISTADD is to force alignment to a full word, which AL1(X'87'),AL3(JFCBADDR) will not do.

This method works only if you are doing a single dataset. The IEFJFCBN macro does not define a DSECT; it just defines the field names. If you have multiple datasets you need multiple JFCB areas and you need to define a JFCB DSECT like this -
JFCB     DSECT
         IEFJFCBN ,
You use the DSECT to obtain the fields from the multiple data areas.

The data area defined by XLISTADD is called an "exit list" and it consists of one or more words that contain flags in the first byte and an address in the next 3 bytes. Obviously these addresses (and the exit list itself and the DCB) must be located below the 16-meg line. The high order bit in the flags field must be on to indicate the end of list, the remaining 7 bits indicate the purpose of the address. Most of the time I specify the flags as something like AL1(X'80'+7) to separate the end of list flag from the purpose flags.

Remember the original design of OS/360 was to use JCL to define the environment used for the program, not for the program to create its environment as it executes using methods like dynamic allocation. I think the goal was to simplify program design by moving environment creation to the system. JCL also serves to hide (in many respects) the environment from the program; tools like RDJFCB serve mainly for the program to retrieve details about its environment. Other details like QSAM and BSAM were designed so the program did not need knowledge about its environment.

In most respects I think the designers got it right, though others, like Dennis Ritchie and Ken Thompson wanted a more interactive system that responded to user requirements much more immediately than a batch oriented system like OS/360.

The other thing we forget is OS/360 was one of the earliest attempts to define a true disk operating system. Operating systems like DOS/360 were disk based implementations of a tape based operating system (TOS/360), and many DOS/360 limitations were enforced by its roots. Even disk based 2nd generation operating systems like IBSYS for 709x and 704x mainframe systems really just moved the SYSRES tape to disk; the remainder of the system was very tape oriented.

Re: Opening an assembler file from a variable

PostPosted: Tue Dec 20, 2011 5:12 pm
by vinodj
Hello Steve,

The dataset has already been allocated but not in this program (this means the dataset is already present on mainframe) this also means there is no DD name available. Is there any possibility this can be done without the DD name (and only DS name)?

Regards,
Vinod

Re: Opening an assembler file from a variable

PostPosted: Tue Dec 20, 2011 5:50 pm
by steve-myers
One word: No.

Re: Opening an assembler file from a variable

PostPosted: Wed Dec 21, 2011 11:58 pm
by dick scherrer
Hello,

Most likely i'm missing something, but if the dataset name is known, why is it difficult to make up a dd name and use it with the existing dataset?

Re: Opening an assembler file from a variable

PostPosted: Thu Dec 22, 2011 12:20 am
by steve-myers
Disk, the TS want to use the dataset name directly, but all you can specify with a DCB is a DD name, not a DS name. I think the TS thinks in terms of the C language fopen function, not an OS/360 idea.

Re: Opening an assembler file from a variable

PostPosted: Thu Dec 22, 2011 1:07 am
by dick scherrer
Hi Steve,

Disk, the TS want to use the dataset name directly, but all you can specify with a DCB is a DD name, not a DS name
Yup, but it should be no effort to just make up a ddname and use it to open the dsn :?

As i said, i'm probably missing something. . .

The "assembler file" in the subject had me scratching my head as well. Maybe i'll do better next year ;)

d

Re: Opening an assembler file from a variable

PostPosted: Thu Dec 22, 2011 1:41 am
by steve-myers
dick scherrer wrote:... Yup, but it should be no effort to just make up a ddname and use it to open the dsn :? ...
Well, you can always insert an arbitrary text string into DCBDDNAM and then try to OPEN the DCB, but if the DD name has not been allocated by JCL or dynamic allocation, OPEN won't do anything.

Re: Opening an assembler file from a variable

PostPosted: Thu Dec 22, 2011 8:23 am
by steve-myers
Basic dynamic allocation. What's so hard about this?
         LA    1,RBADDR
         DYNALLOC ,
         LTR   15,15
         BZ    ALLOCOK
* Insert code to process a bad allocation here
         ...
ALLOCOK  MVC   DCBDDNAM,ADDN
         ...
RBADDR   DC    A(X'80000000'+RB)
RB       DC    AL1(S99RBEND-S99RB,S99VRBAL,0,0)
         DC    2AL2(0)
         DC    A(TXTPP,0,0)
TXTPP    DC    A(TXT01,TXT02,TXT03)
         DC    A(X'80000000'+TXT04)
TXT01    DC    AL2(DALDSNAM,1,L'ADSN)
ADSN     DC    CL44'Insert the dataset name here'
TXT02    DC    AL2(DALRTDDN,1,L'ADDN)
ADDN     DC    CL8' '
TXT03    DC    AL2(DALRTORG,1,L'ADSORG)
ADSORG   DC    AL2(0)
TXT04    DC    AL2(DALSTATS,1,1),X'08' DISP=SHR
* Define S99xxx data areas
         IEFZB4D0 ,
* Define dynamic allocation text unit keys
         IEFZB4D2 ,
This code requests dynamic allocation to create a DD name and return the DD name in ADDN. It also asks dynamic allocation to retrieve the DSORG code for the dataset and return it in ADSORG. If the dataset is cataloged on disk, but the dataset does not exist the allocation will fail. Allocating a new dataset is more complicated, just as with JCL allocation, but it really means specifying more keys than the 3 or 4 for basic allocation.

Re: Opening an assembler file from a variable

PostPosted: Thu Dec 22, 2011 11:44 am
by dick scherrer
Hello,

but if the DD name has not been allocated by JCL or dynamic allocation, OPEN won't do anything.
Agreed, but with my old-fashioned way, i'd just make up this
//THEDD DD DSN=THEDSN,DISP. . . .
and OPEN the DD (whether allocated via JCL or ALLOC or whatever.

As it has been a long year and i should have hibernated weeks ago. . . 8-)

d