z/OS Generation Data GroupsTHIS ARTICLE COPYRIGHTED BY HTTP://WWW.CONCEPTSOLUTIONSBC.COM IF YOU CAN READ THIS, THE POSTER STOLE MY PROPERTY
If you have to produce one each day of the week, you will probably end up with seven files per week:
You will need to change the JCL every day if you want to access the most current file.
GDGs: A Simpler Way
z/OS has a simpler way to do this. You can define a GDG called BILLING.TRANSACT.DETAILS and say it will have seven generations. As you create a file, MVS will create one generation. Each created file is added as a generation to the GDG. So if you created seven files, there will be seven generations to the GDG. In this case, if you defined seven generations as the maximum, you will always have seven generations.
The data set name for each file will be in this format:
BILLING.TRANSACT.DETAILS.G0000V00 - where G0000V00 is the generation number. Generally, the generation number is incremented by one every time a file is created. So the first time a file is created, it will have generation one. The data set name will be:
The second file created will have generation two, making it:
- BILLING.TRANSACT.DETAILS.G0002V00 and so on.
When the limit of generations has been reached, in our example, seven generations, the oldest generation will roll off the GDG and a new generation will be created.
Before creation of eighth generation, existing data sets are:
- BILLING.TRANSACT.DETAILS.G0007V00 <- current generation (generation zero) or BILLING.TRANSACT.DETAILS(0)
- BILLING.TRANSACT.DETAILS.G0001V00 <- oldest generation (generation -six) or BILLING.TRANSACT.DETAILS(-6)
On the creation of the new generation, the first generation rolls off and is deleted and the newest generation is added. After creation of eighth generation, data sets in GDG will be:
- BILLING.TRANSACT.DETAILS.G0008V00 <- current generation (generation zero) or BILLING.TRANSACT.DETAILS(0)
- BILLING.TRANSACT.DETAILS.G0002V00 <- oldest generation (generation -six) or BILLING.TRANSACT.DETAILS(-6)
Generation G0001V00 has rolled off. THIS ARTICLE IS COPYRIGHTED. IF YOU CAN READ THIS THE POSTER STOLE MY WORK
There are several ways to use these files. One is to specify the absolute generation number such as DSN=BILLING.TRANSACT.DETAILS.G0002V00. The other way is to specify the relative generation. In this case, the current generation (G0008V00) has a relative generation of zero. The JCL to access this file will be: DSN=BILLING.TRANSACT.DETAILS(0).
You normally use the relative generation so you do not need to change the JCL every time you run. For example, if your datasets are non-GDG and you always want to use the newest generation as input, you will need to specify unique identifiers for each day. With GDG, you just specify
- DSN=BILLING.TRANSACT.DETAILS(0). MVS will know that you want the current generation.
If you want the previous day's file you specify the -one relative generation.
- DSN=BILLING.TRANSACT.DETAILS(-1). MVS knows it has to pick up the previous generation.
When you create a new generation, you specify +one as the relative generation.
- DSN=BILLING.TRANSACT.DETAILS(+1). MVS knows this is the new generation. The file remains the +one generation until the end of the job where the +one generation will be the zero generation.
Another neat feature of GDG is if you want to use all the GDGs as an input, you can specify all of them in the JCL or you can specify the GDG only like this:
DSN=BILLING.TRANSACT.DETAILS. In this case, MVS will pick out all the generations and use them as input. However, you need to be careful because MVS does not process the files on a first come first served basis (meaning from oldest to newest). MVS processes from newest to oldest. This becomes a problem if you want to process the records as they were processed. Say if you want to update records based on the oldest to the latest, specifying just the GDG base will cause an error.
You define GDGs by using the IDCAMS utility.
DEFINE GDG (gdgname LIMITS(numberofgenerations) )