Retrieving all generation data sets

To retrieve all generations of a GDG as a single data set, specify the GDG name without a generation number in the DSNAME parameter; this is called a GDG ALL request. For example:
DSNAME=PAYROLL
For all generations

To use a GDG ALL request, the DCB attributes and data set organization of all generations must be identical.

The system treats a GDG ALL request as a concatenation of all existing data sets in the GDG, which can affect the meaning of system messages in the job output listing. You can use the DD GDGORDER JCL parameter to control the order of GDS concatenation. If the GDGORDER parameter is not specified, the order specified in the GDG data set catalog entry is used. The GDG data set catalog entry specifies LIFO (last in, first out) by default. LIFO concatenation orders the most recent generation data set first, followed by the next most recent data set, continuing to the oldest generation data set, which is last. This default behavior can also be specified explicitly using the LIFO keyword on the GDGORDER parameter.

To specify an alternative order for GDS concatenation, you can use the FIFO or USECATLG keyword on the GDGORDER parameter. FIFO (first in, first out) concatenation orders the oldest data set first, continuing to the most recent data set, which is last. (FIFO concatenation can be useful for SMF log data, for example.) To specify a unique GDS concatenation order, specify the order in the GDG data set catalog entry and then specify the USECATLG keyword. If you do not specify the GDGORDER parameter, the order specified in the GDG data set catalog entry is used.

For details on using the DD GDGORDER parameter, refer to z/OS MVS JCL Reference.

In the following example, a GDG named PAYROLL has two generations, and is defined to be retrieved in LIFO order (or uses LIFO by default):
//DD1 DD DSN=PAYROLL,DISP=SHR
The previous line of code is allocated as follows:
//DD1 DD DSN=PAYROLL(0),DISP=SHR
//    DD DSN=PAYROLL(-1),DISP=SHR
Alternatively, if the GDG named PAYROLL is defined to be retrieved in FIFO order, the allocation is as follows:
//DD1 DD DSN=PAYROLL(-1),DISP=SHR
//    DD DSN=PAYROLL(0),DISP=SHR
You could override the catalog definition of the GDG retrieval order by using the GDGORDER JCL keyword. For example:
//DD2 DD DSN=PAYROLL,DISP=SHR,GDGORDER=LIFO
This example is allocated as follows, regardless of the catalog definition:
//DD2 DD DSN=PAYROLL(0),DISP=SHR
//    DD DSN=PAYROLL(-1),DISP=SHR
Alternatively, consider the same example using FIFO:
//DD3 DD DSN=PAYROLL,DISP=SHR,GDGORDER=FIFO
This example is allocated as follows, regardless of the catalog definition:
//DD3 DD DSN=PAYROLL(-1),DISP=SHR
//    DD DSN=PAYROLL(0),DISP=SHR
The corresponding keyword GDGORDER=USECATLG is the default setting, which uses the retrieval order that is defined in the catalog.
In the following complex concatenation example, data set GDGDS has two generations which are defined to be retrieved in LIFO order, and data sets A and B are not generation data sets. To concatenate A, all generations of GDGDS, and B, you would code the following JCL:
//DD1     DD  DSN=A,DISP=SHR
//        DD  DSN=GDGDS,DISP=SHR,UNIT=AFF=DD1
//        DD  DSN=B,DISP=SHR,UNIT=AFF=DD1  
Because of the GDG ALL request, the system treats DD1 as if you had coded the following statements, and assigns the following relative position numbers:
//DD1     DD  DSN=A,DISP=SHR                              +000
//        DD  DSN=GDGDS(0),DISP=SHR,UNIT=AFF=DD1          +001
//        DD  DSN=GDGDS(-1),DISP=SHR,UNIT=AFF=DD1         +002
//        DD  DSN=B,DISP=SHR,UNIT=AFF=DD1                 +003  
The generated DD statements will automatically have unit affinity to each other even if you did not code UNIT=AFF:
//DD2     DD  DSN=A,DISP=SHR
//        DD  DSN=GDGDS,DISP=SHR
//        DD  DSN=B,DISP=SHR  
The system treats DD2 as though you had coded the following JCL statements, and assigns the following relative position numbers:
//DD2     DD  DSN=A,DISP=SHR                              +000
//        DD  DSN=GDGDS(0),DISP=SHR                       +001
//        DD  DSN=GDGDS(-1),DISP=SHR,UNIT=AFF=(DD2+001)   +002
//        DD  DSN=B,DISP=SHR                              +003  

Of course, it is not actually possible to code UNIT=AFF=(DD2+001), but the system internally is able to treat the DD statements as though that is what you had coded.

Any error message uses the relative position based on each generation included, not the position you explicitly specified. For example, an error message that includes a relative position of +002 refers to GDGDS(-1), not data set B.

All older generations have unit affinity to the newest data set.

For a GDG on tape, when you use a GDG ALL request and specify parallel mounting in the UNIT parameter, the system mounts all volumes of only the first generation.

For a GDG on direct access, when you use a GDG ALL request and specify parallel mounting in the UNIT parameter, the system mounts all volumes of all generations.

DISP parameter: For both SMS-managed and non-SMS-managed data sets, always code the DISP parameter. The first subparameter of the DISP parameter must be OLD, SHR, or MOD. If you code MOD for a generation data set and the specified relative generation does not exist in the catalog, the system changes the status to NEW.

A normal termination disposition is optional when retrieving a generation data set but is required in a GDG ALL request. Do not code PASS in a GDG ALL request.

UNIT parameter: For non-SMS-managed data sets, code the unit-count subparameter in the UNIT parameter when you want more than one device assigned to the data set. Or, if the data set resides on more than one volume and you want as many devices as there are volumes, code P in the UNIT parameter.

VOLUME parameter: For non-SMS-managed data sets, use the VOLUME parameter to request a private volume, PRIVATE, and to indicate that more volumes might be required, volume count. For an old generation data set, do not specify either a volume serial number or a volume reference to another data set or to an earlier DD statement.

LABEL parameter: For non-SMS-managed data sets, code the LABEL parameter when the data set is on tape and has other than standard labels. If the data set is not the first data set on the volume, specify the data set sequence number. If the data set sequence number is coded for a GDG ALL request, it is ignored; the data set sequence number is obtained from the catalog.

DCB parameter: For non-SMS-managed data sets, code DCB=(list of attributes) when the data set has other than standard labels and DCB information is required to complete the data control block. Do not code DCB=dsname.