I created this JCL example for you. Except for the use of &SYSUID in the data set name it would have worked 52 years ago!
//A EXEC PGM=IEFBR14
//GUSTAV DD DISP=(MOD,DELETE),UNIT=SYSDA,SPACE=(TRK,0),
// DSN=&SYSUID..GUSTAV.DATA(GUSTAV)
//B EXEC PGM=IEFBR14
//GUSTAV DD DISP=(NEW,CATLG),UNIT=SYSDA,SPACE=(TRK,(1,1,1)),
// DCB=(RECFM=FB,LRECL=80),
// DSN=*.A.GUSTAV
//C EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//SYSUT2 DD DISP=OLD,
// DSN=*.A.GUSTAV
//SYSUT1 DD *
THIS IS MEMBER GUSTAV
In some ways the DD statement with DD name GUSTAV in the job step with step ID A is the trickiest part of the JCL. Surprisingly it is also the most dangerous JCL statement in the job.
DISP=(MOD,...) tells the system to determine if the data set exists in the catalog. If it does, use the catalog data to allocate the data set. If the data set does not exist in the catalog, use the data in the UNIT and SPACE keywords to allocate and subsequently delete the data set. It is dangerous because if the data set is allocated on a tape the system would attempt to load the tape.
The IEFBR14 program, which existed 52 years ago but was seldom used - few of us (and I was not one of them, in fact I didn't know it existed!) really understood its value - is about the simplest possible program. In C it would look like this -
int iefbr14( NULL )
{
return 0;
}
So, step A deletes the data set, if it existed when the job started.
Step B creates the data set. After the step completes, there is no member in the data set, as IEFBR14 writes nothing to the data set.
The IEBGENER program in step C created member GUSTAV in data set userid.GUSTAV.DATA. As proof, I used ISPF to see what is in the data set -
BROWSE XXXXXX.GUSTAV.DATA Row 00001 of 00001
Command ===> Scroll ===> PAGE
Name Prompt Size Created Changed ID
. GUSTAV
**End**
and
BROWSE XXXXXX.GUSTAV.DATA(GUSTAV) Line 00000000 Col 001 080
Command ===> Scroll ===> PAGE
********************************* Top of Data **********************************
THIS IS MEMBER GUSTAV
******************************** Bottom of Data ********************************
The DSN=*.A.GUSTAV in steps B and C refers to the data set as it is specified in the JCL in step A; this includes the member name.
The order of the DD statements in step C seems unusual today, but 52 years ago the more commonly used versions of OS/360 required that any DD statement that defined a data set within the job stream had to be the last DD statement in the job step, so this way of writing the JCL was common.
It is difficult to understand these days how fluid things were in the early days of mainframes. Seemingly every day something new and useful was available, or something that worked yesterday didn't work today. Well, it wasn't really quite that fluid, but that gives you the idea how exciting things were!