Defining GDGs with more than 255 generations

Generation Data Groups (GDGs) can be defined with more than the traditional 255 generations by using the LIMIT parameter in conjunction with the EXTENDED attribute. These parameters control the maximum number of Generation Data Sets (GDSs) that can be associated with a GDG.

Source : https://www.ibm.com/docs/en/zos/3.1.0?topic=dgp-required-parameters
LIMIT(limit)
Specifies the maximum number, from 1 to 255, of GDSs that can be associated with the GDG being defined. If EXTENDED is specified, 1 to 999 GDSs can be associated with the GDG being defined.

Source: https://www.ibm.com/docs/en/zos/3.1.0?topic=dgp-optional-parameters
EXTENDED|NOEXTENDED
Specifies whether the GDG is to be an extended GDGr or not.
     EXTENDED
        allow up to 999 generation data sets (GDSs) to be associated with the GDG.
        Abbreviation: EXT
 
     NOEXTENDED
        allow up to 255 generation data sets (GDSs) to be associated with the GDG. This is the default value.
        Abbreviation: NEXT
 
Sample JCL to define a GDG with 999 Generations
 
//STEP1    EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
  DEFINE GDG(NAME(USERID.GDG.LIMIT999) -
             EXTENDED                  -
                   LIMIT(999)                -
                   NOEMPTY                   -
                   SCRATCH)
/*
 
Converting a NOEXTENDED GDG to a EXTENDED GDG
 
Source:  https://www.ibm.com/docs/en/zos/3.1.0?topic=generationdatagroup-converting-noextended-extended
 
You can use the following procedure to convert a generation data group defined as NOEXTENDED to one that is EXTENDED. IBM advises that the original user catalog should be backed up before starting the procedure.

1. Define a temporary user catalog.
2. REPRO MERGECAT the GDG from the original user catalog to the temporary user catalog. This moves the GDG and all GDSes to the temporary user catalog and removes them from the original user catalog.
3. DEFINE a new GDG with the same name as the original GDG specifying the EXTENDED parameter and a new LIMIT parameter as desired.
4. REPRO MERGECAT only the GDSes using wild card notation from the GDG in the temporary user catalog into the new GDG now in the original user catalog.
5. Use DELETE RECOVERY to delete the temporary user catalog.

The process is complete. You can use LISTCAT to prove that the new GDG has the EXTENDED attribute and that a new LIMIT has been set.

Example JCL and IDCAMS statements:
 
//* GDG NOEXTENDED TO GDG EXTENDED CONVERSION
//*
//CONVERT EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
/* 1. DEFINE A TEMPORARY CATALOG */
 
DEFINE -
UCAT -
(NAME (TEMP.UCAT) STORCLAS(SMSSTORC) -
CYL (1 1))
 
/* 2. REPRO GDG AND GDSES TO THE TEMPORARY CATALOG */
 
REPRO -
INDATASET(ORIG.CAT) -
OUTDATASET(TEMP.UCAT) -
ENTRIES(SMSA.GDG) -
MERGECAT
 
/* 3. DEFINE GDG EXTENDED IN THE ORIGINAL CATALOG */
 
DEFINE GDG (NAME(SMSA.GDG) -
EXTENDED LIMIT(999) SCRATCH PURGE)
 
/* 4. REPRO GDSES BACK TO THE ORIGINAL CATALOG */
 
REPRO -
INDATASET(TEMP.UCAT) -
OUTDATASET(ORIG.CAT) -
ENTRIES(SMSA.GDG.*) -
MERGECAT
 
/* 5. DELETE TEMPORARY CATALOG */
 
DELETE TEMP.UCAT USERCATALOG RECOVERY
/* LISTCAT TO SHOW EVERYTHING BUILT CORRECTLY */
 
LISTCAT ENTRY(SMSA.GDG) ALL
/*