Can someone help me understand these GDG's? Though a search in google can give some info, I thought this is the best place to find answers.
There was a reply posted on the documentation abt GDG a while back, but that link doesn't seem to work any longer. If someone can post a link or doc, that will be helpful.
GENERATION DATA GROUPS
__________ ____ ______
APPLICATION OF GENERATION DATA GROUPS
___________ __ __________ ____ ______
A Generation Data Group, often abbreviated GDG, is a facility of the oper- ating system that keeps track of periodic or cyclical data sets. As the name suggests, each new data set that is created forms a new "generation" in a series. Generation data groups typically follow this pattern:
1. A new generation of the data set is added.
2. Some number of the previous generations of the data set are
3. The oldest generation of the data set is deleted.
Of course, you don't have to delete the oldest generation of the data set, but there are few data sets for which you need to keep all generations forever.
Typical nomenclature for the generations of data sets is:
Current version Current generation
Previous version Parent or minus 1 version
Next previous version Grandparent or minus 2 version
The data set naming convention uses a number to indicate the generation.
DSN=data-set-name(0) Current generation
DSN=data-set-name(-1) Previous generation or parent
DSN=data-set-name(-2) Next previous generation or grandparent
The biggest advantage of using generation data groups is that the system keeps track of the generations for you so you don't have to change your JCL each time you run.
Generation data groups consist of data sets that are normal except for their names. The data sets can be sequential, partitioned, or direct. The benefit of using generation data groups is that the system keeps track of the generations for you. You don't have to keep track of many individual data set names.
With normal data set names: With generation data group names:
If you used individual data set names instead, you would need to do the following:
1. Change the JCL to create the new data set name, such as
2. Delete the previous third generation, such as ACCT.SEPT.DATA (if
you wanted to keep only three generations).
With generation data groups, there is no need to change the JCL. You just run it each time you want to create a new generation. The system keeps track of generation data groups in the catalog. Of course, this means that when you specify the disposition for a new generation data set, you must specify CATLG.
To make things consistent within a given job, generation data group numbers are not updated at the end of the job step in which a new generation is created. Instead, they are updated at the end of the job. This is important to as (+1) throughout the job.
You refer to generation data group generations as:
name(+n) or name(0) or name(-n)
The system actually names the data sets as follows:
nnnn is the absolute generation number, 0000-9999.
vv is the version number. Usually this is 00. (You can create
different versions of the same generation, but not with JCL, and
we get into that here.)
Name you use Name you use Actual name (used during
during the job: after the job: and after the job):
you don't need to keep track of the real data set name:
The system does that for you. But if you're looking at your data sets with a tool such as ISPF, it's nice to know how your data sets are actually named, because the actual name is what you'll see with ISPF.
If the generation data group contains partitioned data sets, you must use the real data set name to refer to a member:
Generation data groups are rarely used for partitioned data sets, however. When you create the first generation of a generation data group:
it is actually named name.G0000V00. The next generation of the data set is named name.G0001V00, the next name.G0002V00, and so on. You must not exceed 10,000 (0000-9999) total generations. Furthermore, you can keep only 256 ((0) to (-255)) generations active at any one time. That is, generation data groups are numbered from 0 to 9999. Only 256 of these can be active at any one time. So generations 6000 to 6255 could be active, and generations 0 to 5999 would all be inactive.
The individual generations in a generation data group don't all have to have the same DCB attributes. The RECFM, LRECL, BLKSIZE, and even DSORG can all be different. However, the DCB attributes are usually the same. If they are the same, you can refer to the generation data group without a generation number.
The system then concatenates all the generations (current to oldest generation) for the processing. This might be used to produce such things as year-to-date reports.
Generation data groups can reside on disk or tape.
TOPIC 11.2: CREATING AND USING GENERATION DATA GROUPS
_____ _____ ________ ___ _____ __________ ____ ______
To create a generation data group, you must first do these two things:
1. Create a generation data group base entry in a VSAM catalog. This
entry names the generation data group and specifies how many
generations to keep.
2. Create a data set label on the same volume as that used for the
VSAM catalog entry. The data set label is used as a model for the
generation data group. The DCB sub-parameters on the label may or
may not be used for the data sets for the generation data group.
CREATING A GENERATION DATA GROUP BASE ENTRY
o Sets up the catalog entry used to keep track of the generation data
o Names the generation data group.
o Specifies how many generations are to be kept.
o Tells what to do with old generations (those that get bumped).
o As an option, tells how long to keep the entire generation data
You create a generation data group base entry by executing a VSAM utility
program called IDCAMS. Here is an example:
The NAME parameter names this generation data group as X2222.ANNUAL.DATA.
The VSAM utility programs have a different syntax from the regular utility programs, which in turn are different from JCL. The dash at the end of a line continues a statement only for the VSAM utilities.
Here's an explanation for the DEFINE statement used to create a generation data group base entry:
DEFINE GDG ( -
(The items following GDG are enclosed in parentheses. The - indi-
cates that the statement is continued.)
NAME (generation-data-group-name) -
(The number of generations to be kept. The value can be 1 through
(This tells what to do with the old generations. Coding NOEMPTY
requests that the LIMIT number of newest generations be kept and
the remainder be deleted. If you code EMPTY instead, all the old
generations are deleted, and only the (+1) generation is kept when
the LIMIT is reached.)
Here's the DEFINE statement with EMPTY coded rather than NOEMPTY:
NOEMPTY - When the LIMIT number is exceeded, NOEMPTY keeps the LIMIT
number of newest generations.
EMPTY - When the LIMIT number is exceeded, EMPTY keeps only the most
EMPTY is mainly used to wipe out all the old data sets for the beginning of a new time period.
Here's some more of the DEFINE statement:
DEFINE GDG ( -
NAME (generation-data-group-name) -
(EMPTY or NOEMPTY)
(SCRATCH tells the system to uncatalog and delete the old gener-
ations--those not kept. You could code NOSCRATCH instead, and the
system would uncatalog the data sets and keep them. Generally you
would back up the data set to tape and then just code SCRATCH to
keep things simple.)
(FOR is optional. It specifies the number of days to keep a
generation data group. As an alternative, you can specify the
retention period as TO(yymmdd).)
CREATING A MODEL DATA SET LABEL
The second step in creating a generation data group, after the IDCAMS program is used to create a base entry, is to create a data set to be used as a model for the generation data group. Actually, the system doesn't need an entire data set. It just requires the DCB information contained in the data set label. The following JCL can be used to create a data set label. The IEFBR14 program doesn't do anything--it just allows a step to be executed so that the DD statement is processed.