FW: Integrated Catalog record layout
Resent, first one with prior email included went to junk. It should be, but it's not: Change 23.219 The ICF Catalog 05 record variable GATGEN should have VMAC6156 been input as , 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 . 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 GVoo's left in the catalog. When the GDG wrapped, and when the create of +1 would have created G1000V00, those old GVoo'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! Herbert W “Barry” Merrill, PHD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 www.mxg.com 214 351 1966 ad...@mxg.com for business questions supp...@mxg.com for technical questions ba...@mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Integrated Catalog record layout
It should be, but it's not: Change 23.219 The ICF Catalog 05 record variable GATGEN should have VMAC6156 been input as , 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 . 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 GVoo's left in the catalog. When the GDG wrapped, and when the create of +1 would have created G1000V00, those old GVoo'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! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joe Monk Sent: Saturday, October 22, 2022 8:17 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Integrated Catalog record layout The mapping macro should be in SYS1.MACLIB. Joe On Sat, Oct 22, 2022 at 7:26 AM Willy Jensen wrote: > I'm ok wth the layout of the SMF record as such, what I am looking for > is the layout of the field SMF61CRC. > > -- > For IB
Re: Integrated Catalog record layout
The mapping macro should be in SYS1.MACLIB. Joe On Sat, Oct 22, 2022 at 7:26 AM Willy Jensen wrote: > I'm ok wth the layout of the SMF record as such, what I am looking for is > the layout of the field SMF61CRC. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Integrated Catalog record layout
I'm ok wth the layout of the SMF record as such, what I am looking for is the layout of the field SMF61CRC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Integrated Catalog record layout
SMF record layouts are in the MVS SMF manual ... https://www.ibm.com/docs/en/zos/2.5.0?topic=mvs-zos-system-management-facilities-smf The record layout is here: https://www.ibm.com/docs/en/zos/2.5.0?topic=rm-headerself-defining-section-51 When SMF61TYP = "A", that is a non-vsam record. The DSN is in SMF61ENM. The Catalog is in SMF61CNM, which you can read to get the volser. Joe On Sat, Oct 22, 2022 at 4:50 AM Willy Jensen wrote: > Hi, anybody knows where to find the mapping of Integrated Catalog records? > I am looking at SMF type 61 and at the end it says 'New catalog record for > defined entry', but doesn't say where to find the mapping. I am primarily > looking for volser information for non-vsam datasets. I have found the > position by printing a few records and eye-balling the result, but I would > like something a bit more official. I did look at the CSI interface > returned info, but it doesn't match up with what I see in the SMF record. > I couldn't find any IBM documentation nor anything in the internet in > general. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Integrated Catalog record layout
Hi, anybody knows where to find the mapping of Integrated Catalog records? I am looking at SMF type 61 and at the end it says 'New catalog record for defined entry', but doesn't say where to find the mapping. I am primarily looking for volser information for non-vsam datasets. I have found the position by printing a few records and eye-balling the result, but I would like something a bit more official. I did look at the CSI interface returned info, but it doesn't match up with what I see in the SMF record. I couldn't find any IBM documentation nor anything in the internet in general. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN