This is an important update regarding versions of a GDG generation.
Is it possible to retain 2 versions for a single generation in GDG???
Answer for the above question is absolutely NO.
Here is the detailed explanation for the above question
Absolute Generation and Version Numbers
An absolute generation and version number is used to identify a specific generation of a generation data group. The generation and version numbers are in the form GxxxxVyy, where xxxx is an unsigned 4-digit decimal generation number (0001 through 9999) and yy is an unsigned 2-digit decimal version number (00 through 99). For example:
A.B.C.G0001V00 is generation data set 1, version 0, in generation data group A.B.C.
A.B.C.G0009V01 is generation data set 9, version 1, in generation data group A.B.C.
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.
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 generation data group.
The version number lets you perform normal data set operations without disrupting the management of the generation data group. 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 generation data group. 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 generation data group (GDG) base.
For system-managed data sets, if scratch was specified, the older version will be scratched from the volume. If noscratch was specified, or if the attempt to scratch the DSCB failed, the older version will not be scratched and the general data sets (GDS) will be 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 likewise governed by the GDG base limit processing options. If noscratch was 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.
In this Mainframe Forum - You can post your queries on JCL, OS/390 JCL, MVS JCL, z/OS JCL, JES2 & JES3
1 post • Page 1 of 1
Free tutorials from mainframegurukul
- JCL Tutorial
Covers all important JCL concepts.
- Cobol Tutorial
This tutorials covers all Cobol Topics from STRING to COMP-3.
- DB2 Tutorial
DB2 Tutorial focuses on DB2 COBOL Programming.
- SORT Tutorial
This Tutorial covers all important aspects of DFSORT with examples
- CICS Tutorial
This CICS tutorial covers CICS concepts and CICS Basics, CICS COBOL Programming.
Mainframe Tools and others
- XPEDITER Reference
Explains how we can debug a program
- FILEAID Reference
Explains how to browse , edit and delete datasets
- Change Man Reference
Quick Start tutorial on Changeman
- Abend Reference
Important Abend codes explained
- FaceBook Page
MainframeGurukul FaceBook Page
- LinkedIn Page
MainframeGurkul Linkedin Page