IBM Support

II08285: GDG GDS INFORMATION

Subscribe

You can track all active APARs for this component.

 

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