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.
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
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
@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
age-
> 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
l
-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, L
@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
6 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
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,
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
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 th
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
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
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
14 matches
Mail list logo