GDG processing information

Answer

Problem

GDG processing and the differences between batch and dynamic allocation, including
SMS and non-SMS considerations. This information is taken from Informational
APAR II08285. For additional information see APAR II06463.


Resolution

Terminology:
GDS = Generation Data Set: An individual data set
within a GDG. GDSs can be referred to by their
relative or absolute generation numbers (see
"Relative Generation" and "Absolute Generation",
below.)
GDG = Generation Data Group: An entire collection of
individual Generation Data Sets. A GDG is
referred to by its group name:
e.g., PROD.ACCOUNT.NAME
(See GDGALL processing, below.)
Absolute Generation: A GDS can be referred to by the
GDG group name suffixed with the absolute
generation number:
e.g., PROD.ACCOUNT.NAME.G0058V00
Relative Generation: A GDS can be referred to by the
GDG group name suffixed with a relative generation
number:
e.g., PROD.ACCOUNT.NAME(+1)
Cataloged: When a GDS is fully cataloged, the GDS name
is in the catalog, PLUS the GDG index entry is
updated to show that that GDS is a member of the
GDG.
Deferred Roll-In status: Under SMS, a GDS is first
cataloged only by placing its name in the
catalog, but the GDG index entry is NOT updated to
show that this GDS is a member of the GDG. This
is referred to as "deferred roll-in status".
Later, the GDS is "rolled-in" to the GDG index
entry. A GDS in deferred roll-in status is treated as
a normal (i.e., non-GDG / non-VSAM) data set.
.
In order for MVS Allocation to recognize a data set as a
GDS, a member name must be specified with + - or 0 as the
first character of the member name. For dynamic allocation,
the member name text unit (DALMEMBR) must be provided. If a
fully qualified GDS name (G0000V00) is specified, MVS treats
the data set as a normal (i.e., non-GDG / non-VSAM) data set,
for both batch and dynamic allocations.
.
Allocation Processing:
1. The GDG group name is enqueued, regardless of whether it is
referenced as a GDGALL or a relative GDS. The enqueue is
held until the last step that references the data set in the
JCL ends. In batch processing, this ENQ is performed by the
initiator, at the beginning of the job.

2. The first time a GDS is referenced by a job, a LOCATE is
performed to find the current absolute generation number
(i.e., the absolute generation number corresponding to
relative generation 0). That absolute generation number
(G000V00) is then added to a table (GDG names table) for
future allocations within that job to reference.

Note: Dynamic allocations can turn on S99GDGNT to bypass
using the table and thus always locate the current entry
(generation 0) at the time of the allocation. This allows
them always to know the current generation, even when this
job (or another job), running on the same system (or a
different system, as long as the catalog is shared between
systems) has added generations since this job began.

3. Next, a LOCATE is performed passing the current absolute
generation number and relative displacement (e.g., +1, -1,
0) to Catalog Management to calculate the desired fully
qualified GDS name. This name is then enqueued for the
life of the job, since there is no way of knowing if the
data set will be used later in the job.

4. For SMS GDS's the data set is cataloged in a Deferred
Roll-In status at allocation time. As noted above, this
means that the fully qualified GDS name (i.e., with the
absolute (G0000V00) generation number) is placed in the
catalog, but the GDG index entry is not updated with that
information.

Note: SMS does RECLAIM processing for NEW or MOD GDSs when
it finds the same generation already created, but not
rolled-in to the index. Reclaim processing means that an
existing data set in deferred roll-in status will be
REUSED. For DISP=MOD data sets, the new data would be
added at the end of the existing data. For DISP=NEW data
sets, the existing data would be WRITTEN OVER.

5. For dynamic allocations, the data set is cataloged and (for
SMS) rolled-in, at allocation time.

6. For batch allocations the GDS is not cataloged or (for SMS)
rolled-in, until step unallocation.

7. Many products handle Dynamically Allocating GDG's by
themselves. They issue a LOCATE, calculate the correct
absolute generation number, then issue an SVC99 to allocate
the fully qualified GDS name. In this case there will be a
difference between SMS and non-SMS data sets. Non-SMS GDS's
allocated this way will be cataloged into the GDG index
entry at allocation time. This is not intentionally done by
Allocation, but is actually done by Catalog Management when
it attempts to catalog the data set and a GDG with the same
group name is found. SMS GDG's allocated this way will be
cataloged, but will not be rolled-in until they are
unallocated, due to the fact that allocation does not know
that they are Generation Data Sets.

GDGALL processing:
1. A GDGALL request is when a valid GDG group name is specified
with no member information provided. It causes all
generations of the GDG to be concatenated together under
the same DDname. The various GDS members of the GDG are
processed in sequence from most recently created (generation
0) to least recently created.

2. The only way for Allocation to know about a GDGALL request
is through Locate processing. In a non-SMS system, a
volser cannot be specified, as this causes Locate
processing to be bypassed.

3. Also, since GDGALL requests are just a concatenation of all
GDS members of the GDG, FREE=CLOSE processing will be
bypassed.

JES3 Processing:
1. JES3's internals processing of GDGs is different from MVS
Allocation's processing of them, because JES3 deals with the
job before it goes into execution. However, the Externals
are identical, since a job must run the same on MVS
regardless of whether JES2 or JES3 is used.
From an operator's perspective, after the application of
OY65964 (HJS4421), jobs might wait in JES3 SETUP for a GDG
base because SETUP will allocate the GDG base (which creates
a SETDSN for the GDG base) when JES3 encounters a GDGALL
request or allocation for a relative generation. The latter
is true only if the relative generation resides on a JES3
managed device or if it is SMS managed and JES3 is managing
SMS datasets.
a. Before a job goes into execution ALL references to
positive generation numbers refer to new data sets,
since the steps that catalog the GDSs have not yet run.
b. After a job goes into execution, the FIRST reference to
a positive generation number refers to a new data set.
After the step that creates the data set runs, all
SUBSEQUENT references to the same positive generation
number will get the information from the catalog. For
example:
//STEP1 EXEC ...
//DD11 DD DSN=GDG(+1),DISP=(MOD,CATLG)...
//DD12 DD DSN=GDG(+2),DISP=MOD
//STEP2 EXEC ...
//DD21 DD DSN=GDG(+1),DISP=(MOD),...
c. From JES3's point of view, all references to a positive
generation number refer to a new data set since the job
has not run. From allocation's point of view, the data
set is new in step one and existing in step two.
.
JES3 GDGALL processing:
2. A GDGALL request is used to retrieve all of the generations
in the GDG. To get a GDGALL request, specify the GDG group
name without the data set qualifier (e.g. "GDG" as opposed
to "GDG(+1)"). A potential GDGALL means that the data set
name specified by the current DD matches the data set name
of a GDG single data set (GDS) that was passed or cataloged
in a prior step.
a. When a catalog search is done for the GDGALL request, it
will return with what is currently in the catalog. The
catalog will not include the data set that is passed or
cataloged in the prior step since JES3 locate processing
runs before the job executes. However, when the job
actually executes and gets to the step containing the
GDGALL request, the new generation will have already
been passed or cataloged, and will be included as part
of the GDGALL request.
b. Since JES3 C/I (Converter/Interpreter) runs before
execution, JES3 must simulate the fact that the new
generation was cataloged in the prior step. For
example, assume that at the time JES3 does locate
processing, there are two generations in the GDG:
GDG(0) and GDG(-1). Also assume that the following JCL
was specified:
//STEP1 EXEC ...
//DD1 DD DSN=GDG(+1),DISP=(,CATLG)
//STEP2 EXEC ...
//DD2 DD DSN=GDG,DISP=SHR
.
c. When JES3 does the catalog locate for step2, Catalog
returns TWO generations: GDG(0) and GDG(-1). However,
during execution, when Allocation does the locate, it
will get THREE generations since the new generation
created by DD1 will have been cataloged. Therefore,
JES3 must somehow simulate this process during catalog
locate processing. This is accomplished by remembering
the fact that JES3 had a match on a GDG Single request
(GDS). If JES3 completes the pass/catalog table scan
without finding a non-GDG data set match, it sets a bit
in the IJS (Intermediate Job Summary Table) to indicate
that this is a potential GDGALL request. This bit tells
JES3 postscan that it must scan the IJS entries prior
to the current step looking for new generations.
When a new generation is found, it will be added to the
GDGALL request.

MVS JCL User's Guide

Appendix B. Generation Data Sets

DFSMS/MVS USING DATA SETS