DISP parameter

Parameter Type

Keyword, optional

Purpose

Use the DISP parameter to describe the status of a data set to the system and tell the system what to do with the data set after termination of the step or job. You can specify one disposition for normal termination and another for abnormal termination. Note that if an abend occurs within a step, the step itself may terminate normally or abnormally, depending on whether an ESTAE (or ESPIE routine) intercepts the abend and requests that processing continue. Normal termination of a step is indicated by the presence of message IEF142I; abnormal termination of a step is indicated by the presence of message IEF472I.

Note: Disposition of the data set is controlled solely by the DISP parameter; disposition of the volume(s) on which the data set resides is a function of the volume status when the volume is demounted. If the UNIT parameter specifies a device, such as a printer or telecommunications device, that does not involve a data set, do not code the DISP parameter.

If the system obtains unit and volume information for an OLD, MOD, or SHR status, the data set is treated as if it exists, whether or not it is physically on the device.

When any step of a job requests exclusive control of a data set, Start of change

with an exception of when the job is allowed to downgrade ENQs via the DSENQSHR specification End of change

, the system converts all requests for shared control of that data set within that job (DISP=SHR) to requests for exclusive control. One of two methods can be used to request exclusive control:

DISP=NEW, DISP=MOD, or DISP=OLD on a JCL request.
DISP=NEW, DISP=MOD, or DISP=OLD on a dynamic allocation request, including dynamic allocation requests that result from the use of certain utility control statements. For example, utility control statements that delete/scratch a data set will result in exclusive use of that data set.

If a dynamic allocation requests exclusive control of a data set then all subsequent DISP=SHR JCL references to that data set within that job will be upgraded to exclusive control. The job will retain exclusive control of that data set until the end of the last step of that job which references that data set in its JCL. For example:

//STEP1  EXEC PGM=anypgm1
//DD1    DD  DSN=A.B.C,DISP=SHR
//STEP2  EXEC PGM=IDCAMS
   DELETE  A.B.C
   DEFINE  A.B.C
//STEP3  EXEC PGM=anypgm3  
//DD3    DD  DSN=A.B.C,DISP=SHR
//STEP4  EXEC PGM=anypgm4

Before the start of STEP1, the job will request shared control of data set A.B.C. In STEP2, the DELETE/DEFINE of data set A.B.C will cause the shared control from STEP1 to be upgraded to exclusive control. In STEP3, control of data set A.B.C will remain exclusive, since it is not possible to downgrade an ENQ from EXCL to SHR Start of change in the case that a dynamic allocation upgrades the ENQ. End of change At the end of STEP3, control of data set A.B.C will be released. The ENQ on data set A.B.C will therefore not be held at all during STEP4. If, however, the job also contained a STEP5 which requested use of data set A.B.C, then exclusive control of that data set would continue to be held by the job all the way through both STEP4 and STEP5.

DISP and ENQ: Before starting the first step of a job, the initiator requests control of all of the data sets in that job by issuing an ENQ for each of them, using the value specified for DISP to determine the kind of ENQ issued. The initiator issues the ENQ for each data set at the highest level required for that data set by any step of the job. For example, if all steps of the job request shared control of a specific data set (DISP=SHR) then the ENQ for that data set is requested as SHR. If, on the other hand, any step of the job requests exclusive control of a specific data set (DISP=NEW, DISP=MOD, or DISP=OLD), then the ENQ for that data set is requested EXCL.

Start of change If the job is allowed to downgrade ENQs, then ENQs will be downgraded from exclusive control to shared control at the last step for which the data set is referenced EXCL. The downgrade will not occur if the ENQ has been upgraded by a dynamic allocation request in the current or a previous step. End of change

Start of change If the job is not allowed to downgrade ENQs, then ENQs cannot be downgraded from EXCL to SHR. If one step needs the ENQ EXCL and a following step only needs it SHR, the ENQ is still held as EXCL. End of change

Start of change In both cases, the ENQ is held until the end of the last step which references that data set, at which point the ENQ is released entirely. End of change

DISP and ENQ for generation data sets: The way the initator issues an ENQ to control generation data sets can be different than with other data sets. The initiator only issues the ENQ for the GDG base name for a generation data set that is referenced by either:

Their relative GDG names (for example, DSN=TEST.GDG.DATASET(0)).
As GDG ALLs (for example, DSN=TEST.GDG.DATASET)

For example, the initiator issues the ENQ for the GDG base name, TEST.GDG.DATASET for the generation data sets shown in the previous list. Generation data sets referenced by either their relative GDG names or as GDG ALLs are processed this way because the initiator does not know which specific absolute generation names will be required. This is because the conversion from relative generation name to absolute generation name is done during the allocation for the step referencing the data set. The ENQ for the specific, absolute, generation (G0000V00) data set name or names is issued at the start of the step requesting the relative GDG or GDG ALL.

Note that the initiator does not issue an ENQ for the GDG base name for a generation data set that is referenced by its absolute GDG name. Instead it issues an ENQ for that specific G0000V00 data set name.

References

For information about tape data set processing, see z/OS DFSMS Using Magnetic Tapes.