What is a GDG and How its used in JCL
In Mainframe Programming, Generation Data Group is known as GDG which is multiple generations of the same file base. So if there is a GDG base(consider like a parent file) with a name ABC then its generations(children of the parent file ABC) will be ABC.G01, ABC.G02 and so on. When you are defining the GDG Base, you will be giving instructions on how many generations are needed.

Referring GDG in JCL
The current generation is referred with a suffix of 0 which is like ABC(0), the previous generation will be referred as ABC(-1) and the next generation as ABC(+1).
Generations are defined at the end of the job or JCL execution. It means, if the first step creates one generation, code it as ABC(+1) and if the second step creates another generation, then it SHOULD be coded as ABC(+2) as the (+1) version is not yet promoted to current version. Similarly to refer the GDG created in the second step, refer it by ABC(+2).
GDG datasets can be also referenced with their generation number like ‘ABC.G001V00’ which is an actual filename. Referring it as (0) and (-1) are relative references.
Advantages of using GDG
- GDG datasets are referred in the JCL using GDG base and a relative number. So the same JCL can be used many times without changing the dataset name and this is the biggest advantage of GDG.
- GDG Base has pointers to all its generations. So reading the GDG base in a JCL without specifying the generation will read all generations created under the base. If flat files are used instead of GDG, then a manual concatenation of datasets to be done in the JCL.
How to create a GDG using IDCAMS
GDG Base is created using the utility called IDCAMS. Below are the parameters or PARMs given while creating the GDG
Parameter | Purpose |
NAME | GDG base Name |
LIMIT | The maximum number of GDG versions you needed. S value can range from 1 – 256 |
EMPTY/NOEMPTY | This Parm defines what needs to be done if the generation is exceeded than specified limit. EMPTY keeps the most recent generation. NOEMPTY keeps the LIMIT number of newest generation. |
SCRATCH/ NOSCRATCH | SCRATCH option forces to un-catalogue and deletes the versions that are not kept. NOSCRATCH option does un-cataloguing without deleting it physically from the volume. |
OWNER | Owner of the GDG. |
FOR DAYS (n) / TO (DATE) | Expiry date till when the dataset has to be preserved. |
Model dataset has to be defined after or along with the creation of base. Once model DCB is defined, then during the allocation or creation of the generations, we don’t need to code DCB parameter. There is an option to override this set DCB parameter by coding new parameter while creating the GDG version. So two GDG version can exist in two different file formats.
Sample JCL to create GDG
Below is a sample JCL to create a GDG base using IDCAMS and MODEL DCB parms.
//GDG EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//MODEL DD DSNAME=TEST.SAMPLE.MASTER,DISP=(,KEEP),
// UNIT=SYSDA,VOL=SER=XXX800,SPACE=(CYL,(0)),
// DCB=(DSORG=PS,RECFM=FB,LRECL=400)
//SYSIN DD *
DEFINE GDG ( NAME(TEST1.SAMPLE.MASTER) –
LIMIT(5) –
NOEMPTY –
SCRATCH )
/*