Absolute Generation and Version Numbers

While it is technically possible to define an explicit generation of G0000V00, such a definition is discouraged because it can cause unpredictable results when deleting generation data sets using relative generations.

The number of generations and versions is limited by the number of digits in the absolute generation name; that is, there can be 9,999 generations. Each generation can have 100 versions. To maintain relative order when the highest generation is 9999 and a new generation is added, the new generation is assigned a wrap flag. The wrap flag causes the new generation to behave as if it had 10,000 added to it. This causes the ordering to be correct when going from 9999 to 0001. Note: the next higher generation from 9999 is not 0000, it is 0001. When all of the generations in the generation index have the wrap flag set, the wrap flags are all turned off. For example if we have a generation index with 3 entries, and the generations are 9999, 0001, and 0002, with 0001 and 0002 having their wrap flags on, the order would be 9999, 0001, 0002. If a new generation is created, 0003, it also has the wrap flag set. The LIMIT causes the 9999 to be rolled off from the index. 0001, 0002 and 0003 all have the wrap flag set, so the wrap flag is turned off for all three generations. The order is still valid and is 0001, 0002, 0003. If a generation exceeds 2000 generations from the current generation, the wrap flag is not set. You should not create large relative generation gaps which can lead to order problems.

The system automatically maintains the generation number. The number of generations kept depends on the size of the generation index. For example, if the size of the generation index permits ten entries, the ten latest generations can be maintained in the GDG.

The version number lets you perform normal data set operations without disrupting the management of the GDG. For example, if you want to update the second generation in a 3-generation group, replace generation 2, version 0, with generation 2, version 1. Only one version is kept for each generation.

You can catalog a generation using either absolute or relative numbers. When a generation is cataloged, a generation and version number is placed as a low-level entry in the GDG. To catalog a version number other than V00, you must use an absolute generation and version number.

You can catalog a new version of a specific generation automatically by specifying the old generation number along with a new version number. For example, if generation A.B.C.G0005V00 is cataloged and you now create and catalog A.B.C.G0005V01, the new entry is cataloged in the location previously occupied by A.B.C.G0005V00. The old entry is removed from the catalog, to make room for the newer version, and may or may not be scratched depending on what limit processing options are specified for the GDG base. For system-managed data sets, if scratch is specified, the older version is scratched from the volume. If noscratch is specified, or if the attempt to scratch the DSCB fails, the older version is not scratched and the generation data sets is recataloged as a non-VSAM data set with the GnnnnVnn name not associated with the GDG base. For non-system-managed data sets, the older version is also governed by the GDG base limit processing options. If noscratch is specified for the base, the older GDS version is not scratched. To scratch the old version and make its space available for reallocation, include a DD statement, describing the data set to be deleted, with DISP=(OLD,DELETE) when the data set is to be replaced by the new version.