Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Scott Barry]

This can be easily tested -- 1) create a suitable GDG base, 2) allocate an 
explicit dataset as **.GV00, 3) allocate a relative (+1) generation, and 
watch what happens, either using ISPF 3.4 (DSLIST) and/or LISTCAT.

Scott Barry
SBBWorks, Inc.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Longabaugh, Robert E]

Rollover has been around for a while.   I have some "GDG wrap" tests from 2007. 
 At that time, GDGs defined in late 1979 with a new generation created each day 
would have been be reaching G.  

Bob Longabaugh
CA Technologies 
Storage Management

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John Eells
Sent: Friday, May 27, 2016 5:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

Lizette Koehler wrote:
> 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.
>


GDGEs were introduced with z/OS V2.2 and can have up to 999
generations.* I believe both GDGs and GDGEs both "roll over" from
GV00 to GV00 these days without needing to be redefined, but I don't 
recall when we did that (other than it wasn't recently).  The number of 
concurrent generations is something you choose when you define either one.

* We were going for an even thousand until we weighed the value of "one more 
generation" against the cost of updating a bazillion messages to add space for 
another digit and decided 999 was close enough!

--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
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: Proper way to resolve existing GDG GnnnVnnn by relative reference

[John Eells]

Lizette Koehler wrote:

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.




GDGEs were introduced with z/OS V2.2 and can have up to 999 
generations.* I believe both GDGs and GDGEs both "roll over" from 
GV00 to GV00 these days without needing to be redefined, but I 
don't recall when we did that (other than it wasn't recently).  The 
number of concurrent generations is something you choose when you define 
either one.


* We were going for an even thousand until we weighed the value of "one 
more generation" against the cost of updating a bazillion messages to 
add space for another digit and decided 999 was close enough!


--
John Eells
IBM Poughkeepsie
ee...@us.ibm.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Barry Merrill]

I added support in 2014 but have not had a motivation to create 999 and see 
what happens!

  -VMACCTLG and VMAC6156 were updated Nov 27, 2014.
   Support for GDGE, GDG Extended GDGLIMIT=999 in z/OS 2.2.
   New variable GATEXTND='E' flags the extended mode, new
   variables GATLIMTE/GATCNTE are INPUT but also kept in the
   existing GATLIMIT/GATCNT to preserve existing reports.
   Some overlooked flag variables in the 05 Catalog Segment
   are now decoded and kept in datasets TYPE6156 (from SMF
   (type 61, 65, 66) and TYPECTLG (from the IDCAMS EXPORT
   CATALOG flat file).  These are all the 05 fields now:
 GATALLOC='GATALLOC*FIFO OR*LIFO?'
 GATCNT  ='GDG*COUNT'
 GATDELET='DELETE*WHEN*LIMIT*EXCEEDED*0=OLD*1=ALL?'
 GATEXTND='GATEXTND*EXTENDED*OR CLASSIC?'
 GATEXTNO='GATEXTNO'
 GATGEN  ='GATGEN  '
 GATLIMIT='MAXIMUM*GDS*ENTRIES*IN GDG*BASE'
 GATLIMTE='EXTENDED*GAT*GATLIMIT'
 GATPURGE='GATPURGE*YES OR*NO?'
 GATSCRTH='SCRATCH*FORMAT 1*DSCB*0=NO*1=YES?'
 GATVER  ='GATVER  '
 GATWRAP ='GATWRAP '
 GDGATTR ='GDGATTR'
  -BUILD005 protects for TYPETASK='JOBG' in JCTJOBID;

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Thursday, May 26, 2016 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

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:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Barry Merrill
> Sent: Thursday, May 26, 2016 7:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 , 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

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Lizette Koehler]

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:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Barry Merrill
> Sent: Thursday, May 26, 2016 7:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 , 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 Sup

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Barry Merrill]

An old change in MXG Software:


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!

Barry Merrill



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Thursday, May 26, 2016 8:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler <stars...@mindspring.com>
wrote:

> John,
>
> Would this code account for a V01 - V99 ending in the GDG?
> And would it handle the fact that the next GDG might not be 

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Nims,Alva John (Al)]

I do not know if this will help, but at CBTTAPE.ORG FILE 929 has a REXX 
function that could be of use.

gds = REALNAME(the.gdg.name(+1))

Al Nims
Systems Admin/Programmer 3
UFIT
University of Florida
(352) 273-1298

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Thursday, May 26, 2016 9:35 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

catsearch just prints output in the order received from IGGCSI00.

I have confirmed that LOCATE resolves existing relative GDG references 
correctly.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Thu, May 26, 2016 at 8:18 AM, John McKown <john.archie.mck...@gmail.com>
wrote:

> On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler 
> <stars...@mindspring.com>
> wrote:
>
> > John,
> >
> > Would this code account for a V01 - V99 ending in the GDG?
> > And would it handle the fact that the next GDG might not be a 
> > GVxx
> but
> > maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a 
> > little differently.  A -1 might not be what you think it might be.
> >
> > I think, there is some ambiguity regarding the correct chronological
> order
> > in the GVxx numbers over 9000.
> >
> > Lizette
> >
>
> ​Very good points. I don't know how catsearch works internally, so I 
> don't know how the output is ordered. My code assumes that the entries 
> are ordered correctly in that the "newest" is at the bottom (last 
> emitted), the "oldest" is at the top (first emitted), and each 
> generation is "in the proper order". The egrep stage could be changed 
> to accept other than V00 at the end by doing:​
>
> egrep '^HLG\.GDG\.G[0-9]{4}V[0-9]{2}$'
>
> ​I didn't think of that because in 35 years, I have _never_ seen 
> anything other than V00 at the end.​
>
>
> --
> The unfacts, did we have them, are too imprecisely few to warrant our 
> certitude.
>
> Maranatha! <><
> John McKown
>
> --
> 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

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[J R]

"​I didn't think of that because in 35 years, I have _never_ seen anything
other than V00 at the end.​"

I looked into this a while back and, as far as I recall, only a single entry 
per generation can be cataloged within the GDG at any one time.  IE., if you 
catalog G1234V01, then G1234V00 is no longer a part of the GDG.  I becomes 
cataloged as a non-GDG dataset.  



From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
John McKown <john.archie.mck...@gmail.com>
Sent: Thursday, May 26, 2016 9:18 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler <stars...@mindspring.com>
wrote:

> John,
>
> Would this code account for a V01 - V99 ending in the GDG?
> And would it handle the fact that the next GDG might not be a GVxx but
> maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a little
> differently.  A -1 might not be what you think it might be.
>
> I think, there is some ambiguity regarding the correct chronological order
> in the GVxx numbers over 9000.
>
> Lizette
>

​Very good points. I don't know how catsearch works internally, so I don't
know how the output is ordered. My code assumes that the entries are
ordered correctly in that the "newest" is at the bottom (last emitted), the
"oldest" is at the top (first emitted), and each generation is "in the
proper order". The egrep stage could be changed to accept other than V00 at
the end by doing:​

egrep '^HLG\.GDG\.G[0-9]{4}V[0-9]{2}$'

​I didn't think of that because in 35 years, I have _never_ seen anything
other than V00 at the end.​


--
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

Maranatha! <><
John McKown

--
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: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Kirk Wolf]

catsearch just prints output in the order received from IGGCSI00.

I have confirmed that LOCATE resolves existing relative GDG references
correctly.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Thu, May 26, 2016 at 8:18 AM, John McKown 
wrote:

> On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler 
> wrote:
>
> > John,
> >
> > Would this code account for a V01 - V99 ending in the GDG?
> > And would it handle the fact that the next GDG might not be a GVxx
> but
> > maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a little
> > differently.  A -1 might not be what you think it might be.
> >
> > I think, there is some ambiguity regarding the correct chronological
> order
> > in the GVxx numbers over 9000.
> >
> > Lizette
> >
>
> ​Very good points. I don't know how catsearch works internally, so I don't
> know how the output is ordered. My code assumes that the entries are
> ordered correctly in that the "newest" is at the bottom (last emitted), the
> "oldest" is at the top (first emitted), and each generation is "in the
> proper order". The egrep stage could be changed to accept other than V00 at
> the end by doing:​
>
> egrep '^HLG\.GDG\.G[0-9]{4}V[0-9]{2}$'
>
> ​I didn't think of that because in 35 years, I have _never_ seen anything
> other than V00 at the end.​
>
>
> --
> The unfacts, did we have them, are too imprecisely few to warrant our
> certitude.
>
> Maranatha! <><
> John McKown
>
> --
> 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: Proper way to resolve existing GDG GnnnVnnn by relative reference

[John McKown]

On Wed, May 25, 2016 at 6:37 PM, Lizette Koehler 
wrote:

> John,
>
> Would this code account for a V01 - V99 ending in the GDG?
> And would it handle the fact that the next GDG might not be a GVxx but
> maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a little
> differently.  A -1 might not be what you think it might be.
>
> I think, there is some ambiguity regarding the correct chronological order
> in the GVxx numbers over 9000.
>
> Lizette
>

​Very good points. I don't know how catsearch works internally, so I don't
know how the output is ordered. My code assumes that the entries are
ordered correctly in that the "newest" is at the bottom (last emitted), the
"oldest" is at the top (first emitted), and each generation is "in the
proper order". The egrep stage could be changed to accept other than V00 at
the end by doing:​

egrep '^HLG\.GDG\.G[0-9]{4}V[0-9]{2}$'

​I didn't think of that because in 35 years, I have _never_ seen anything
other than V00 at the end.​


-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Lizette Koehler]

John,

Would this code account for a V01 - V99 ending in the GDG?
And would it handle the fact that the next GDG might not be a GVxx but 
maybe a G0001Vxx?  Remember GDG numbers at the back can wrap a little 
differently.  A -1 might not be what you think it might be.

I think, there is some ambiguity regarding the correct chronological order in 
the GVxx numbers over 9000.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of John McKown
> Sent: Wednesday, May 25, 2016 1:34 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Proper way to resolve existing GDG GnnnVnnn by relative reference
> 
> On Wed, May 25, 2016 at 2:58 PM, Kirk Wolf <k...@dovetail.com> wrote:
> 
> > I want to resolve an existing GnnnVnn for a GDG using a (0) or (-n)
> > reference, but in this case I don't want to allocate the data set.
> >
> > Is there a better way than to list the HLQ.GDG.* catalog entries with
> > IGGCSI00 and then pick off the minus nth entry?   (is this even correct in
> > all cases?)
> >
> >
> > BTW - I always want the "latest" table (for BPXWDYN, this is "GDGNT" )
> >
> > Thanks,
> >
> > Kirk Wolf
> > Dovetailed Technologies
> > http://dovetail.com
> >
> >
> ​Kirk, perhaps you've heard of this wonderful product called Co:Z?  grin>
> 
> Using COZPROC
> 
> catse​arch -m 2 'HLG.GDG.**' |\
> egrep '^HLG\.GDG\.G[0-9]{4}V00$' |\
> awk '$1 == "HLQ.GDG.GV00" {gen=NR;} END {print "(" gen-NR ")";}'
> # replace  above with the absolute generation number.
> 
> The above does make the assumption that you don't use the NOSCRATCH option so
> that all the matching named data sets are in "rolled in" status.
> 
> 
> --
> The unfacts, did we have them, are too imprecisely few to warrant our
> certitude.
> 
> Maranatha! <><
> John McKown
> 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[John McKown]

On Wed, May 25, 2016 at 2:58 PM, Kirk Wolf  wrote:

> I want to resolve an existing GnnnVnn for a GDG using a (0) or (-n)
> reference, but in this case I don't want to allocate the data set.
>
> Is there a better way than to list the HLQ.GDG.* catalog entries with
> IGGCSI00 and then pick off the minus nth entry?   (is this even correct in
> all cases?)
>
>
> BTW - I always want the "latest" table (for BPXWDYN, this is "GDGNT" )
>
> Thanks,
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
>
​Kirk, perhaps you've heard of this wonderful product called Co:Z? 

Using COZPROC

catse​arch -m 2 'HLG.GDG.**' |\
egrep '^HLG\.GDG\.G[0-9]{4}V00$' |\
awk '$1 == "HLQ.GDG.GV00" {gen=NR;} END {print "(" gen-NR ")";}'
# replace  above with the absolute generation number.

The above does make the assumption that you don't use the NOSCRATCH option
so that all the matching named data sets are in "rolled in" status.


-- 
The unfacts, did we have them, are too imprecisely few to warrant our
certitude.

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Proper way to resolve existing GDG GnnnVnnn by relative reference

[Kirk Wolf]

Just figure out that LOCATE seems to handle it.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Wed, May 25, 2016 at 2:58 PM, Kirk Wolf  wrote:

> I want to resolve an existing GnnnVnn for a GDG using a (0) or (-n)
> reference, but in this case I don't want to allocate the data set.
>
> Is there a better way than to list the HLQ.GDG.* catalog entries with
> IGGCSI00 and then pick off the minus nth entry?   (is this even correct in
> all cases?)
>
>
> BTW - I always want the "latest" table (for BPXWDYN, this is "GDGNT" )
>
> Thanks,
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Proper way to resolve existing GDG GnnnVnnn by relative reference

[Kirk Wolf]

I want to resolve an existing GnnnVnn for a GDG using a (0) or (-n)
reference, but in this case I don't want to allocate the data set.

Is there a better way than to list the HLQ.GDG.* catalog entries with
IGGCSI00 and then pick off the minus nth entry?   (is this even correct in
all cases?)


BTW - I always want the "latest" table (for BPXWDYN, this is "GDGNT" )

Thanks,

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN