GDG

GDG is a collection of historically related non-VSAM data sets that are arranged in chronological order; each data set is known as a Generation Data Set.

The DEFINE GENERATIONDATAGROUP command creates a catalog entry for a Generation Data Group (GDG).  The syntax of this command is:

DEFINE      GENERATIONDATAGROUP

(NAME(entryname)  

LIMIT(limit)      

{EMPTY|NOEMPTY}   

{OWNER(ownerid)}  

{SCRATCH|NOSCRATCH}

{TO(date)|FOR(days)})

{CATALOG(catname{/password})}

Mandatory parameters:

GENERATIONDATAGROUP: Specifies that a generation data group (GDG) entry is to be defined. A GDG can contain both SMS- and non-SMS-managed generation data sets. A generation data set (GDS) cannot be a VSAM data set.  If you create a GDG and its catalog is on an SMS-managed volume, you should remove any dependencies on pattern DSCBs.  See DFSMS/MVS V1R3 Using Data Sets for information about GDGs and GDSs. Abbreviation GDG.

NAME(entryname): Specifies the name of the GDG being defined.

LIMIT(limit): Specifies the maximum number, from 1 to 255, of GDSs that can be associated with the GDG being defined. Abbreviation LIM.

Optional parameters:

CATALOG(catname./password.): identifies the catalog in which the generation data group is to be defined.  If the catalog's volume is physically mounted, it is dynamically allocated.  The volume must be mounted as permanently resident or reserved.  See "Catalog Selection Order for DEFINE" in topic 1.6.4 for the order in which a catalog is selected when the catalog's name is not specified. Here 'catname' and 'password' specifies catalog name and password. If the catalog is not SMS-managed and is password protected, one must supply the update (or higher level) password. Passwords are ignored for SMS-managed data sets and catalogs. Abbreviation CAT.

EMPTY|NOEMPTY: specifies what action is to be taken when the maximum number of GDSs for the GDG is exceeded and another GDS is to be cataloged.  The disposition of the data set's DSCB in the volume's VTOC is determined with the SCRATCH|NOSCRATCH parameter.  For SMS-managed data sets, the data set's NVR is also determined with the SCRATCH|NOSCRATCH parameter.  If NOSCRATCH is specified for an SMS-managed GDS, the GDS is uncataloged from its GDG base and can be recataloged outside its GDG base as an SMS non-VSAM entry with the roll-off status.

EMPTY specifies that all the generation data sets are to be uncataloged when the maximum is exceeded (each data set's non-VSAM entry is automatically deleted from the catalog). Abbreviation:  EMP.

NOEMPTY specifies that only the oldest generation data set is to be uncataloged when the maximum is reached. Abbreviation:  NEMP.

OWNER(ownerid): Identifies the generation data set's owner. Note to TSO Users:  If the owner is not identified with the OWNER parameter, the TSO userid is the default ownerid.

SCRATCH|NOSCRATCH: specifies whether a generation data set's DSCB is to be deleted from the volume's VTOC when the data set is uncataloged (that is, when its entry is deleted from the catalog automatically, as described under EMPTY|NOEMPTY, or explicitly as a result of a user entered DELETE request).  For SMS-managed GDSs, SCRATCH|NOSCRATCH specifies if the NVR is to be removed from the VVDS when the data set is uncataloged.

You can override the SCRATCH|NOSCRATCH attribute when issuing the DELETE command.

SCRATCH specifies that the generation data set's DSCB is to be deleted from the volume's VTOC when the generation data set is uncataloged.  Direct access device space management (DADSM) removes the data set's DSCB from the VTOC, erases the data set's space on the volume, and makes the space available to other system users.  The generation data set ceases to exist.  For SMS-managed GDSs, SCRATCH also specifies that the NVR is to be removed from the VVDS when the data set is uncataloged. Abbreviation:  SCR.

NOSCRATCH specifies that the generation data set's DSCB is not to be removed from the volume's VTOC when the generation data set is uncataloged.  The data set's DSCB in the volume's VTOC is left intact and can be used to locate the data set.  Your program, however, can process the data set by using a JCL DD statement to describe and allocate the data set. Abbreviation:  NSCR.

TO(date)|FOR(days): specifies the retention period for the GDG being defined.

TO(date) specifies the date through which to keep the GDG being defined. The date appears in the form .yy.yyddd, where yyyy is a four-digit year, yy is a two-digit year, and ddd is the three-digit (001 through 366) day of the year.  Two-digit years are treated as if "19" is specified as the first two digits of yyyy.

FOR(days) specifies the number of days to keep the GDG being defined.  The maximum number that can be specified is 9999.  If the number specified is 0 through 9998, the GDG is retained for the number of days specified; if the number is 9999, the GDG is retained indefinitely.  If neither TO nor FOR is specified, the GDG can be deleted at any time.

Note:

1.    The general naming convention of new Generation Data Sets is GDGbasename.GxxxxVyy, where 'xxxx' is the generation number and 'yy' is the version number.

2.    While referring to a GDG, omission of version number specifies all available versions to be included.

3.    Within a job, if step 1 creates a new version of GDG then in step 2 to refer to that version (+1) should be specified. But for several file transfer utilities like NDM, FTP, XCOM, to refer to the specified version of GDG one has to specify (0) th version.

·         Define GDG base and create empty version

//STEPDEF1 EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSIN    DD *

  DEFINE   GDG(NAME('G1SG00AT.GDGNAME1') -

           NOEMPTY,SCRATCH,LIMIT(30))

//STEPEMPT EXEC PGM=IEFBR14

//         IF ( STEPDEF = 0 ) THEN

//NEWVER01 DD DSN= G1SG00AT.GDGNAME1(+),

//         DISP=(,CATLG),

//         SPACE(TRK,(5,2))

//SYSPRINT DD SYSOUT=*

//SYSIN    DD *

//         ENDIF

Here a new GDG base is created as 'G1SG00AT.GDGNAME1' in the first step. In the second step a new empty version of the same is created with name 'G1SG00AT.GDGNAME1.G0001V00'.

 

·         Delete all existing versions of GDG

//STEPDEL1 EXEC PGM=IEFBR14

//DELVER01 DD DSN= G1SG00AT.GDGNAME1,

//         DISP=(OLD,DELETE,DELETE),

//         SPACE(TRK,(1,1))

//SYSPRINT DD SYSOUT=*

//SYSIN    DD DUMMY

Here by specifying no version number of the existing GDG, all the existing versions of the GDG is deleted. However, the GDG base itself is not deleted.

 

·         Delete GDG versions as well as base

//STEPDELV EXEC PGM=IEFBR14

//DDNAME01 DD DSN=G1SG00AT.GDGNAME1,

//         DISP=(OLD,DELETE,DELETE),

//         SPACE=(TRK,(1,1),RLSE)

//SYSIN    DD DUMMY

//STEPDELG EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSOUT   DD *

//SYSIN    DD *

  DELETE   G1SG00AT.GDGNAME1 

/*

Here by IDCAMS utility deletes the GDG base. But for this step to execute successfully no versions of this GDG should be existing. In that case the JCL will complete with RC=08 and will not delete any versions as well as the base. So all the existing versions are to be deleted first by IEFBR14 and then the base is to be deleted by IDCAMS. However, on JEM/JSCAN, this JCL shows RC=04 warning as no catalog entry for G1SG00AT.GDGNAME1 found in the IDCAMS SYSIN. But the on execution the JCL completes with RC=00.