This "Friday post" of an old MXG change documents a unique problem
with GDG wrapping, and the unwillingness of the IBM catalog technician
(a/k/a trench holder) to provide the documentation of their catalog
records back in 2005.
Maybe he was afraid that MicroSoft would offer a competing catalog product???
Barry
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 and +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!
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Rob Schramm
Sent: Friday, October 25, 2013 12:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GDG question
Phil,
AFAIK, the whole GDG assignment only happens once.. during initial creation.
MODing will change the size of the data set.. not the GooooVoo number(s). With
SMS a new GDG entry gets rolled in at step end.
Most everything you need to know is in "Chapter 29. Processing Generation Data
Groups" of the "DFSMS Using Data Sets" book.
The link is
http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.idad400%2Fch14.htm
The only thing I didn't see in there is a detailed explanation of the GDG
roll-over when counting past 99999 generations. There are a couple of old
APARS that go into great detail on how the process works and what to expect.
Rob Schramm
Rob Schramm
Senior Systems Consultant
Imperium Group
On Fri, Oct 25, 2013 at 12:25 AM, Phil Smith <p...@voltage.com> wrote:
> Apologies for the naïve question, but I spent some time Googling and
> reading and didn't find a clear answer to this.
>
> We have a data set that gets fetched from the network and changes
> occasionally. I'd like to untie this update from normal operation-that
> is, on the off-chance that the network is down at the precise instant
> that we check for the data set, I'd like things to continue operating.
> So I'm thinking that if we cache a copy of the data set on disk (the
> contents aren't sensitive), we could try to fetch; if we can't fetch,
> we shrug and continue; if we can, we compare the data read with the
> existing data (there's a timestamp) and only rewrite if it's changed.
>
> But the data is also shared across tasks, so we don't want a window
> where it's half-written and some task tries to read it.
>
> A GDG seems like it would work great for this: the number of
> generations could be defined as low as two, so the update would write
> the "other" copy, and the next time one of the tasks tries to read it,
> it would get the newer one.
>
> So here's my question (aside from the obvious one of "Am I missing
> something above that makes this dumb"):
>
> If a jobstep runs with a DD for a GDG that's got DISP=MOD, and the
> jobstep reads but never tries to write the file, does a new,
> zero-length GDG get created? I'm of course hoping the answer is "No".
>
> Thanks,
> --
> ...phsiii
>
> ----------------------------------------------------------------------
> 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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
