Barry, I have heard that the number of GDGs may be allowed to go beyond 255 generations. Do you have any insight on this? I am wondering how this enhancement may impact the GDG Wrap condition.
I have seen in the z/OS V2.2 manuals: Extended format for generation data groups (GDGs): z/OS V2R2 introduces a new extended format for generation data groups (GDGs). Extended format GDGs can contain up to 999 generation data sets (GDSes). The previous GDS limit was 255 GDSes per GDG. New GDGs can be defined with this new extended format. For existing GDGs, the previous GDS limit still applies. To support this enhancement, the IDCAMS DEFINE GDG command includes a new optional parameter (EXTENDED) that you can specify to enable a new GDG to contain up to 999 GDSes. If you do not specify that parameter, the default value (NOEXTENDED) takes effect, setting a limit of 255 GDSes for the GDG. A new GDGEXTENDED parmlib variable lets you specify whether to allow the EXTENDED value to be used on DEFINE of a GDG. If GDGEXTENDED(NO) (the default) is specified, then the DEFINE of a GDG with the EXTENDED parameter is not allowed. If GDGEXTENDED(YES) is specified, then the DEFINE of a GDG with the EXTENDED parameter is allowed. For more information, see the description of IGGCATxx in z/OS MVS Initialization and Tuning Reference. The LIMIT parameter on the IDCAMS DEFINE GDG command is changed to accept a maximum value of 999 for extended GDGs. The previous maximum LIMIT value of 255 still applies to GDGs which are not defined as EXTENDED. For extended GDGs, the IDCAMS ALTER LIMIT command is also enhanced to let you set a new GDS limit of up to 999 for the GDG. The z/OS Generic Tracking Facility has also been used to help determine if any calls to Catalog Management are only requesting the classic GDG limit, and not the extended GDG limit. For more details about these enhancements, see the descriptions of the ALTER command and the DEFINE GENERATIONDATAGROUP command in z/OS DFSMS Access Method Services Commands. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Barry Merrill > Sent: Thursday, May 26, 2016 7:44 AM > To: [email protected] > Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference > > An old change in MXG Software: > > > Change 23.219 The ICF Catalog 05 record variable GATGEN should have > VMAC6156 been input as &PIB.2., instead of one byte, and variable > VMACCTLG GATWRAP='Y' is now set if the first bit of GATGEN is on, > Aug 29, 2005 to mark that this GDG member has "wrapped"; i.e., its > generation number has exceeded 9999. If GATWRAP is on, > GATGEN=GATGEN-32768 to contain the correct Gen number. > This discovery was precipitated by IGD07001I ABENDs in > production, which occurred when a GDG that had GATWRAP > on for some members, and GATWRAP off for others, when > that GDG generation number goes from 999 to 1000. > Normally, when all members of a GDG have wrapped, the > next catalog action turns off the wrap bit in all of > the catalog records. For a "normal" GDG, that should > happen when the +256th gen is created after wrap, as > only 255 members can exist in the catalog. But this > site had had a very old application that originally > created +1 thru +5 each day, and then deleted +1 thru > +4, leaving only +5 in the catalog. However, back when > Clinton was President, an application change was made > that created only +1 thru +3 and deleted only +1 & +2, > so there were 2 old GooooVoo's left in the catalog. > When the GDG wrapped, and when the create of +1 would > have created G1000V00, those old GooooVoo's still had > their wrap bit off, and the production job failed: > IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122 > Return Code 140: > Inconsistent or conflicting arguments were provided. > Reason Code 122: > Catalog G1000Vxx will cause the GDG to exceed the > limit of 10,999. > Programmer Response: > Clean up the GDG in error then catalog G1000Vxx. > The site found Information APAR II07276, which explained > how wrap works, but it says to 'see the "Z" page for > internal details of the wrap bit interface'. > > So the site asked IBM Support: "We need to identify other > GDGs that have the same exposure to causing ABENDs. Can > I look at the 'Z' page? Does the 'wrap bit' appear in > SMF 61, 65, 66 ICF Catalog records?" > > IBM Level 2 Catalog Support refused to answer the quite > valid question, with this answer: > "Unfortunately, the 'Z' page in our info APARs refer to > information meant for IBM eyes only, for helping us get > to problem determination quicker. We are not at > liberty to discuss any control block internals that are > not provided in our published manuals. As for > information in SMF records relating to this, this info > would be included in the updated record portion > of the SMF record, however we cannot discuss offsets > for those either. I am sorry I cannot be more helpful. > Please let me know if there are any other questions > that I can answer for you." > > Even escalation to my IBM Poughkeepsie z/OS support did > not convince IBM Level 2 Catalog Support to identify > which bit is the "GATWRAP" bit. The ICF Support and > Developers hid behind "OCO", Object Code Only, as the > reason they could not provide catalog record > documentation (but DSECTS are NOT CODE!). > > So I suggested the site could create a GDG and force it > to wrap, and by examining SMF records, we concluded that > first bit of GATGEN was the GATWRAP bit. > > Then, I remembered I still had lots of archaic printed > manuals, and located the very old "MVS/XA Catalog > Diagnosis Reference for DFP Release 1.2", which confirmed > that the GATWRAP bit was indeed the first bit of the > GATGEN field in the 05 Catalog Record! > > Barry Merrill > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
