steve-myers
Active Member
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
|
|
|
|
Now this is what goes on with Generation Data Group (GDG) data sets.
First, the programmer creates a GDG index. A GDG index can contain up to 35 characters. When you create the index you specify a few attributes about the index. The most important attribute is the maximum number of data sets within the index that can be created at any time. In traditional GDG indexes you can retain up to 255 data sets. Now you can create “extended” indexes to retain as many as 999 data sets.
In these examples, we will use a GDG index as simply GDG.
In JCL, to add a new generation data set (to use the official terminology) to the index you specify a data set name as DSN=GDG(+n) where n is usually 1 or 2, rarely more. You specify an existing generation as DSN=GDG(0) or GDG(-n). GDG(0) retrieves the most recently added generation, GDG(-1) and so on. In my work, for example, I have one GDG that retains 20 generations. Yesterday a job created absolute generation 2123 and automatically deleted absolute generation 2103 to make room for the new data set; the JCL just specified DSN=GDG(+1). Within one job, the mapping of relative generation to absolute generation is fixed. After the job completes GDG(0) retrieves the GDG(+1) from the previous job. This mapping of relative generations to absolute generations means that no other job that uses relative generations can run in parallel with another job that uses relative generations of the same generation data group.
Now Mr. Jensen mentioned there are some drawbacks to using GDGs. Before the advent of System Managed Storage a programmer had to create a data set with default DCB attributes for the GDG, or go through moderately strange JCL when creating a new member of the GDG. Many shops applied a rather non-standard and unsupported modification to the MVS job scheduler to bypass this requirement. There are other issues I won’t try to discuss here. |
|