GDG – Generation Data Groups operations in JCL

GDG Stands for ‘Generation data group’ & is used to catalog a group of datasets that have common and similar data formats, and these datasets can be referenced by relative generation and version number. It is mostly used to take periodic backups of critical data for future reference. 

All datasets within GDG share the same name except the last qualifier which is made of generation number and version number. The individual files within a group have a generation number added to the end of the name to make each file name unique. e.g. if the base is “XXXXX.YYYYY.ZZZZZ” then the first file created will be given the name “XXXXX.YYYYY.ZZZZZ.G0001V00″. Subsequent files are named by incrementing the generation number resulting in filenames ending in G0002V00 through G9999V00. Once the G9999V00 is reached the numbering will start again from G0001V00. 

• G – Stands for Generation number – Value range 0000 – 9999
• V – Stands for Version number – Value range 00 – 99
• The two zeroes on the end of the name are used to represent a volume number.

Rules for coding GDG

• All datasets belonging to a GDG must have same DCB parameters such as record length, record format and so on.
• Maximum of 255 datasets can exist within a GDG
• GDGs must be cataloged
• Generations of GDG should be sequential and must reside on disk or tape
• For all new generation data sets, DISP parameter must be set to CATLG
• For all new generation data sets, DSN and UNIT parameter must be coded

The benefits are

• We do not need to create a new JCL or change the name of the JCL every time in a weekly run or daily run or monthly run or yearly run of a JCL.
• You can set the limit of the related files(generations)
• We can easily keep track of all generation of data sets
• We can delete or un-catalog the older generation
• Any particular generation can be referred easily.

Note: Generations are updated only at the end of the job i.e. For any executing job, the current generation remains the same until it ends. If the job abends then the next version is also not created.

Create a GDG Base using IDCAMS

In this example 20 is the number of generations to create and keep.

 //STEP1 EXEC PGM=IDCAMS
 //SYSPRINT DD SYSOUT=*
 //SYSIN DD *
 DEFINE GDG(NAME(XXXXX.YYYYY.ZZZZZ.GDGVER) -
 LIMIT(20) -
 NOEMPTY -
 SCRATCH)
 /*

NAME – This parameter is used to specify the name of the data set that is to be created.
LIMIT – This parameter is used to specify the total number of generations that the GDG may contain. The maximum value for LIMIT is 255. 
EMPTY/NOEMPTY – These two parameters are mutually exclusive. EMPTY specifies that all existing generations of the GDG are to be uncataloged whenever the generations of GDG reached the maximum limit i.e. let’s say the limit is defined as 5 and we are creating the 6th version. In this case version, 1 will be uncataloged while creating the 6th version. NOEMPTY specifies that only the oldest generation of the GDG is to be uncataloged if the limit is reached i.e. let’s say the limit is defined as 5 and we are creating the 6th version. In this case version, 1 to 5 will be uncataloged while creating the 6th version.
SCRATCH/NOSCRATCH – These two parameters are mutually exclusive. SCRATCH parameter specifies that whenever entry of the GDG is removed from the index, it should be deleted physically and uncataloged. NOSCRATCH parameter specifies that whenever entry of the GDG is removed from the index, it should be uncataloged, not physically deleted.