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.
DCBADDR DCB DSORG=PS,MACRF=GL,
XLISTADD DC 0A(0),AL1(X'87'),AL3(JFCBADDR)
JFCBADDR DC 0XL176'00'
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 -
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.