z/OS DFSMS Using Magnetic Tapes
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Generation data groups

z/OS DFSMS Using Magnetic Tapes
SC23-6858-00

A cataloged data set that is frequently updated, such as a weekly payroll, can be grouped with its earlier generations to form a named generation data group. A lower-level index in the catalog structure allows generation and version numbers to be included in the data set name. For example, the original generation of the data set group A.PAYROLL is named A.PAYROLL.G0001V00. The fourth generation of the data set is identified as A.PAYROLL.G0004V00. The absolute generation and version numbers are in the form GxxxxVyy, where:
xxxx
is a decimal number (0001 to 9999) showing the relationship to the original generation. The maximum number of generations that can be cataloged is established when the index is built for the particular generation data group.
yy
is a decimal number (00 to 99) identifying a version of the same generation. Only the latest version is cataloged.

You usually refer to a generation data set by specifying its relative generation number. For example, A.PAYROLL(0) refers to the latest cataloged generation; A.PAYROLL(-1) refers to the next-to-the-latest generation; and A.PAYROLL(+1) refers to a new generation to be added to the group.

These are methods to specify attributes for a new generation data set:
  • When a generation data group base is established, the GDG is cataloged. The GDG can be cataloged in either an SMS or non-SMS managed catalog. If the catalog resides on an SMS managed volume, then the model DSCB can not exist. (All SMS data sets must be cataloged and the model DSCB has the same name as the GDG. Therefore the model DSCB can not be defined on an SMS volume because its name would conflict with the existing GDG name.) If the catalog resides on a non-SMS managed volume, then the model DSCB can exist; however, if the generation is SMS-managed, then it will not use the model DSCB. The LIKE, REFDD, and DATACLAS attributes can be used for both SMS and non-SMS generation data sets.
  • Only explicitly specified DCB attributes, REFDD, LIKE, and DATACLAS are used with SMS to allocate a new generation data set. If a model DSCB exists, it is ignored. However, model DSCBs are still valid. The LIKE keyword specifies the allocation attributes of a new data set by copying the attributes of a cataloged model data set. The following attributes are copied from the model data set to the new data set:
    • Record format (RECFM)
    • Record length (LRECL)
    • Data set organization (DSORG)
    • Record organization (RECORG) (to VSAM only)
    • Key length (KEYLEN) (to DASD only)
    • Key offset (KEYOFF) (to VSAM only)
    • Type, PDS, or PDSE (DSNTYPE) (to DASD only)
    • Space allocation (AVGREC and SPACE) (to DASD only)
    Examples of allocating a tape generation data set by supplying its DCB attributes through DATACLAS and LIKE are:
    //DDNAME DD DSN=HLQ.----.LLQ(+1),DISP=(NEW,CATLG),DATACLAS=dc_name
     
    //DDNAME DD DSN=HLQ.----.LLQ(+1),DISP=(NEW,CATLG),LIKE=dsname

If you do not specify a block size in the JCL, the system calculates a block size. Note that the block size is not obtained from the data class or LIKE data set. For further information, see z/OS DFSMS Using Data Sets. The expiration date from the data class is stored in the JFCB. Note that the expiration date from the LIKE data set is not used.

Information on creating and retrieving generation data groups can be found in z/OS DFSMS Using Data Sets, z/OS MVS JCL User's Guide, and z/OS DFSMSdfp Utilities.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014