APAR status
Closed as canceled.
Error description
ALSO SEE: II06463 This APAR is to document GDG processing and the differences between batch and dynamic allocation, including SMS and non-SMS considerations. For additional information, please refer to Appendix B of the JCL User's Guide (SA22-7598 for z/OS). 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 below: "Relative Generation" and "Absolute Generation") GDG = Generation Data Group: An entire collection of individual Generation Data Sets. A GDG is referred to by its group (also called "base") 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) Bias: The difference between any two relative generation numbers (eg, the 0th vs. the +1 generations = Bias +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" (see 4a-4c, below). 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. For GDGALL and relative GDS references (but NOT for absolute GDS references), the GDG group name is enqueued. 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, and the level of the ENQ is based on the "highest" request in the entire job. DISP = NEW, OLD, or MOD requires an EXCL (Exclusive) ENQ. (highest) DISP = SHR requires a SHR (Share, Shared) ENQ. (lowest) 2. The first time a relative 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 bit 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. 4a. For dynamic allocations of both SMS and non-SMS GDS's, the data set is cataloged and rolled-in at dynamic allocation time (IGD107I msgIGD107I). 4b. For batch allocations of non-SMS GDS's the data set is cataloged and rolled-in at step unallocation. 4c. For batch allocations of SMS GDS's the data set is cataloged in Deferred Roll-In status at step allocation time, and rolled-in at step unallocation. (As noted above, Deferred Roll-In status 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.) CAUTION: For NEW or MOD GDSs, if SMS finds the same generation number (G0000V00) already cataloged, but not rolled-in to the GDG index, it does =====> RECLAIM processing. Reclaim processing means that an existing data set in deferred roll-in =====> status will be REUSED. For both DISP=NEW and =====> DISP=MOD datasets, the new data would WRITE OVER the existing data and the existing data would =====> thus be LOST. Note: The time when a GDS is rolled in to the Index has nothing whatsoever to do with when the relative GDG Bias is adjusted. That is, if step1 of a job creates a GDS with DSN=dsn(+1), then within that job that GDS will always be referenced as "+1" until the job terminates. To read it in in (eg) step2 of that same job, code DSN=dsn(+1),DISP=SHR. To create the next generation of that data set in (eg) step3 of that same job, code DSN=dsn(+2),DISP=(NEW,...). This is because Allocation maintains a table (called the GDG Names Table or GDGNT) during the life of a job, and uses that table to determine what absolute generation to assign to a relative generation number. See #2, above. 5. 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. CAUTION: Using a positive number as the relative generation number in a LOCATE / CAMLST macro creates an =====> absolute generation name and REPLACES the relative generation number in the area pointed to by the CAMLST macro. GDGDSN LOCATE FULLGDG FULLGDG CAMLST NAME,C1DSN,,GDGLOC C1DSN DC CL44'dsname(+x)' In the above example, after the LOCATE macro was issued the field C1DSN would contain the actual G0000V00 name of the generation to be created. If that fully qualified name were then used in an ALLOCATE (SVC99), the ENQ would only be done on the fully qualified DSN and NOT on the GDG Base =====> name. This would mean that there was NOT PROPER =====> SERIALIZATION on the GDG base, and someone else could read GDGs while this new GDS was being =====> created, causing havoc (e.g., one generation read twice and the most recent generation not read at all). L2: See SP (z pg). GDGALL processing: 1. A GDGALL request is when a valid GDG group name is specified with no member information provided. It causes all genera- tions 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 since it is ignored for concatenations. When creating a new generation of a GDG, failure to supply DCB info in one of the following ways will result in msgIEF218I for DD stmts; rc048C for Dynamic Allocations (* see NOTE, below *). SMS managed GDGs pick up the DCB attributes from the SMS DATACLAS, so you don't have to specify any DCB attributes in the JCL. NON-SMS managed GDGs have a unique set of rules for assigning DCB attributes. There are only 3 ways to define DCB attributes for non-SMS managed GDGs (* see NOTE, below *): 1. Reference a catalogued dataset name to copy its attributes. a. The referenced DSCB must NOT have the same name as the GDG base. b. The referenced DSCB may reside on any DASD volume. c. The referenced DSCB MUST be cataloged. d. The dataset may be allocated as zero tracks SPACE=(TRK,0). e. The DCB parameter of the GDG dataset being created MUST mention the cataloged dataset by name (i.e., DCB=dscbdsn) and then, if desired, override those attributes, which may differ from the catalogued DSN you're referencing, e.g., DCB=(dscbdsn,LRECL=....). For dynamic allocations this would need to be specified in a DALDCBDS, *NOT* in a DALDCBDD. 2. Use a PATTERN DSCB or model dataset label: a. The pattern DSCB must have the same name as the GDG base. e.g., if the GDG name will be TESTFILE.MYNAME(+1) then the pattern DSCB must be named TESTFILE.MYNAME b. The pattern DSCB must reside on the volume that contains the catalog in which the GDG base/index entry resides. c. The pattern DSCB must NOT be cataloged. d. The dataset may be allocated as zero tracks SPACE=(TRK,0). e. The DCB parameter of the GDG dataset being created must NOT mention the PATTERN DSCB by name. 3. Code the JCL "REFDD=" or "LIKE=" parameters. NOTE: Starting in z/OS 1.6 (HBB7709) non-SMS GDGs do NOT require a model DSCB. If DCB=dsname is not provided, Allocation will look for a model DSCB with the GDG base name. If not found, Allocation will NOT fail the job, but will assume that the DCB information will be provided from other sources at OPEN time. See PDDB item BDC000033660 for the documentation changes to the JCL User's Guide. JES3 Processing: 1. JES3's INternal 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 regard- less of whether JES2 or JES3 is used. From an operator's perspective, 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 req- uest or allocation for a relative generation. The latter is true only if the relative generation resides on a JES3 man- aged 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 or from the Passed Dataset Information Block (PDIB). 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 exec- ution, JES3 must simulate the fact that the new genera- tion 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 that JES3 had a match on a GDG Single request (GDS). If JES3 completes the pass/catalog table scan without find- ing 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 post- scan that it must scan the IJS entries prior to the cur- rent step looking for new generations. When a new genera- tion is found, it will be added to the GDGALL request. Please see II08224 for JES3 GDG dataset integrity issues. Additional Keywords: HOWTO msgIEF218I rc48C CATKEYS: CATINFO CATGDG
Local fix
Problem summary
Problem conclusion
Temporary fix
Comments
VSAMINFO : CAS SVC99 STATIC JCL NONVSAM DEQUEUE ROLLIN 5695DF101 SMS 5695DF103 AMS 5695DF105 CATALOG 5752SC1B4 MVS/ALLOCATION SC264922 USING DATA SETS SC263124 MANAGING DATA GC281653 JCL USER'S GUIDE GC281645 ADG : Authorized Assembler Language Program
APAR Information
APAR number
II08285
Reported component name
V2 LIB INFO ITE
Reported component ID
INFOV2LIB
Reported release
001
Status
CLOSED CAN
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
1994-10-24
Closed date
1994-10-24
Last modified date
2013-01-24
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Applicable component levels
[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Platform":[{"code":"PF054","label":"z\/OS"}],"Version":"001"}]
Document Information
Modified date:
10 January 2021