II07276: JCL FAILURE ON CREATE OF GDG DATA SET GENERATION LEVEL G1001V00 WITH RELATIVE(+1) PROCESSING. GDGNAME(+1). (VSAMINFO GDG)

APAR status

• Closed as canceled.

Error description

• ***************************************************************
  See II08285 for definitions and processing flow; also see
      OY47531.
  See OW30563, closed SUG, for additional information.
  ***************************************************************
  Updated in September, 1999 by Carole L. Coleman
  As of 9/99, the current processing for GDGs turns the Wrap Bit
  on to allow generations from 10,001 to 10,999 to be created.
  The wrap bit is then turned off to allow generations 1000 and
  above to be created.  This is true for all currently supported
  releases of DFSMS.  This process, however, is NOT GUARANTEED
  to always work as expected for absolute generation numbering,
  when generation numbers are skipped or for Restart/Recall
  processing.
  
  See the "Z" page for internal details of the wrap bit interface.
  
  The Wrap Bit is set when an allocation for a new GDG data
  set (+1) is done and the current entry is G9999Vxx.  Each entry
  subsequent to G9999Vxx will have the Wrap Bit set to preserve
  the logical catalog order so that relative generation (+1)
  processing will work correctly. In NORMAL SEQUENTIAL operations
  new entries will have the Wrap Bit turned on until the first
  transaction after G9999Vxx is rolled off occurs.
  
  When the Wrap Bit is set to ON for all cataloged GDSs AND the
  highest generation number is 0999 (10,999), the next GDS to be
  cataloged causes the Wrap Bit to be turned off for all entries
  in the Generation Aging Table (GAT).  This allows the GDG to go
  beyond the 10,000 point without having to redefine the GDG
  and recatalog all of the GDSs.
  
  This process works when the generations are created using
  relative (+1) numbers because of catalog's limit of 255.
  However, the results are uncertain when a customer uses
  absolute generation numbers,skips generation numbers,
  or interferes with the normal sequence for some
  reason, such as the use of HSM RECALL processing of
  old GDG data sets.  The most common errors are a duplicate
  name or an out of sequence condition.  The duplicate
  data set name checking is done early in the processing and
  is done on the G000V00 name without taking the Wrap Bit
  into consideration.
  
  When there is a mixture of generations with the wrap bits on and
  off and a +1 generation is attempted, the following messages are
  received and the new generation is retained but not rolled in.
  
  IGD07001I GDG ROLL IN ERROR - RETURN CODE 140   (msgIGD07001I
       REASON CODE 122 MODULE IGG0CLEL             rc140 rsn122)
  IGD104I GREG.GDS.TEST.G1000V00 RETAINED,  DDNAME=GDG1DD1
  
  RETURN CODE 140 means:  Inconsistent or conflicting arguments
                          were provided.
  REASON CODE 122 means:  Catalog G1000Vxx will cause the
                          GDG to exceed the limit of 10,999.
  Programmer Response:  Clean up the GDG in error then catalog
                        G1000Vxx.
  
  Other messages received by customers include
  IEF287I - NOT CATLGD 9 (msgIEF287I notcatlgd9 not cataloged9)
  IEF337I - NOT CATLGD 9 (msgIEF377I notcat9 notcataloged9)
  If these messages are received, try to process the +1 generation
  again.
                                                                 .
  CAUSES:
                                                                 .
  Some examples follow.
                                                                 .
  o    PMR 46270,370 (4/99):
  
  Customer had G9997, G9998, G9999 followed by G0723,
  10999).   When G1000 was created, it was not cataloged
  because it went over the 10,000 mark.  The customer
  needed to keep some of the old data sets (G9997, G9998,
  G9999).  They also created many generations, sometimes
  more than one per day, so they manually deleted                .
  unnecessary copies which created the gaps (G0723,
  G0843, ..., G0998).  However, the real reason the G1000
  was not cataloged correctly is because the G9997, G9998,
  G9999 did not have the Wrap Bit turned on.
                                                                 .
  The customer kept getting the error after the G9997, G9998,
  and G9999 were deleted/uncataloged until they UNCATALOGED
  and RECATALOGED G0999 which turned the wrap bit off.
  
  o     PMR 85628,442 (4/99):                                    .
  
  The customer could not create a +1 generation because
  it was a duplicate and found that there were several
  generations out of order and they had gone past G9999.
                                                                 .
  This was recreated with a new GDG base of five entries,
  three +1 generations, an absolute G9998, and another
  +1 generation, giving G0001, G0002, G0003, G9998, and
  G9999.  When they tried to add the next +1 generation,
  it was considered a duplicate data set.  They also got the
  Duplicate data set message when they tried to create an
  absolute G0001, G0002, or G0003.  Only the absolute
  generation for G0004 was cataloged and it had the Wrap Bit
  turned ON.
  
  o     Unknown PMR (Jan, 1998):
  
  Customer started using the Julian day as an absolute
  generation number during 1997 and started over with Julian
  day 001 on January 1, 1998, also using absolute generation
  numbers.  Because the previous set of generation numbers had
  never reached G9999, the Wrap Bit was never turned on and
  the new G0001 was positioned first in the Generation Data
  Group, resulting in an out of sequence condition.
  
  o     PMR 54308,111 (June, 1999)
  
  Customer had some generations below G9999, with the Wrap Bit
  OFF, and some generations at G0001 and above, with the Wrap
  Bit ON, when G9997 was migrated and then recalled.  When it
  was recataloged, the Wrap Bit was set ON, making it higher
  than the G0001 and resulting in an out of sequence condition.
  In this case, the Wrap Bit processing is working as
  intended, even though it is not working like this customer
  would like.  We know that the Wrap Bit processing is not
  predictable when normal relative generations are not used.
  
  ADDITIONAL SYMPTOMS:
   KEYWORDS: GAT GATGEN GDG WRAP BIT
  
  CATKEYS: CATINFO CATGDG CATNEW
  

Local fix

• The correct order of the GDS entries can be re-established using
  IDCAMS LISTCAT and uncataloging/recataloging the out of order
  entries.
                                                                 .
  For uncataloging, use the 'U' function of TSO option 3.4, or use
  IDCAMS DELETE NONVSAM NOSCRATCH function.  You may wish to note
  the VOLUME name for the data set.
                                                                 .
  For recataloging, use the 'C' function of TSO option 3.4, or use
  IDCAMS DEFINE NONVSAM VOL(volser) RECATALOG function.  If the
  GDS is a TAPE or multi-volume data set, be sure to specify the
  correct order of the volsers and follow the requirements for the
  RECATALOG parameter listed in the AMS Reference Guide.
                                                                 .
  STEP 1.  Use the LISTCAT GDG ENT(GDGname) ALL CAT(catalogname)
           to get the ASSOCIATIONS list of GDS entries.
                                                                 .
  STEP 2.  If G9999Vxx exists, uncatalog the entry.
                                                                 .
  STEP 3.  Uncatalog all of the out-of-order GDS entries.  For
           example, if the LISTCAT output shows
           'CHRISC.NONSMS.GDG.G1000V00' prior to
           'CHRISC.NONSMS.GDG.G0994V00' in the LISTCAT
           ASSOCIATIONS list.  Uncatalog the G1000V00 entry.
                                                                 .
  STEP 4.  Now uncatalog the LAST GDS entry listed in the GDG
           ASSOCIATIONS list (this will be the G0999V00 entry).
                                                                 .
  STEP 5.  Recatalog the NONVSAM entries in the correct order by
           the generation name, except for the G9999V00 entry.  Do
           not recatalog this entry.
                                                                 .
  STEP 6.  Use the LISTCAT GDG ENT(GDGname) ALL CAT(catalogname)
           to verify the ASSOCIATIONS list of GDS entries as being
           in alphanumeric sequence.
                                                                 .
  PREVENTION -
                                                                 .
  In order to allow flexibility of the use of GDG data sets,
  CATALOG is unable to determine the intent of the user when HSM
  RECALL, explicit GDG data set naming, or DEFINE RECATALOG is
  used to catalog a GDG data set.  Use of the recovery technique
  listed above will restore the GDG for normal sequential relative
  (+1) processing without a loss of data to the user.
                                                                 .
  If G9999Vxx must be recataloged for access, and G9999Vxx is not
  the desired current GDG to be used for subsequent new
  allocations, try to restrict creation of new GDG data sets while
  G9999Vxx is being reused, and remove G9999Vxx when application
  processing is complete to restore the original current GDG.
  .
  If you cannot determine which generations are in error, run
  an IDCAMS print of the BCS entry for the GDG Base using
  FROMKEY(DSN) COUNT(2) and contact IBM to determine the status
  of the wrap bits.
  

Problem summary

Problem conclusion

Temporary fix

Comments

• catalog recovery procedure. (CATRECOVERY)
  

APAR Information

• 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