Re: Fastest way to read OLDEST GDG entry

[Longabaugh, Robert E]

The Generation data set is in a deferred roll-in status when it is allocated.  
It becomes part of the rolled in generations during the deallocation phase.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 19, 2015 10:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fastest way to read OLDEST GDG entry

On Thu, 19 Nov 2015 15:59:37 +, J O Skip Robinson wrote:

>I haven't experimented with this, but going with NOSCRATCH is likely to 
>cause big problems with DASD GDGs. A data set residing on an 
>SMS-managed volume must be cataloged.

It has been a long time since I looked at this, but what I remember is that 
GDGs were a special case. For one thing, with SMS, a data set is cataloged at 
allocation time, not at step end like it was before.

One consequence of that is that is that a generation may be scratched as soon 
as the new one is allocated, rather than wait until the step ends successfully.

Consider a new GDG created with NEW,CATLG,DELETE. Before SMS, the old 
generation was scratched at the time the new one is cataloged at the end of the 
step, when the new one is cataloged.

As a result, the idea of a generation being rolled in and rolled out was 
created. The data set is cataloged, but is not cataloged as part of the GDG.

--
Tom Marchant

--
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: AW: Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

On Wed, 18 Nov 2015 09:17:25 -0800, John Mattson wrote:
>...
>   A third possibility which is kludgy would be to create each new DS with
>a unique DATETIME in the DSN and then do the catalog list and search for
>the oldest date.  No roll-off, no problems with new GDGs coming in.
>
Alas, JCL has no facility for creating a new DS with a unique DATETIME
in the DSN.  GDGs provide this in JCL.

-- gil

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

Re: AW: Re: Fastest way to read OLDEST GDG entry

[Lizette Koehler]

Gil,
You can use the symbols for DATE and HOUR and so forth.  I think it is 
documented  z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning 
Reference>Overview>Sharing parmlib definitions>What are system symbols?>Dynamic 
system symbols

https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/dynpsm.htm


New symbol  Old symbol
 

 


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Thursday, November 19, 2015 10:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: AW: Re: Fastest way to read OLDEST GDG entry
> 
> On Wed, 18 Nov 2015 09:17:25 -0800, John Mattson wrote:
> >...
> >   A third possibility which is kludgy would be to create each new DS
> >with a unique DATETIME in the DSN and then do the catalog list and
> >search for the oldest date.  No roll-off, no problems with new GDGs coming 
> >in.
> >
> Alas, JCL has no facility for creating a new DS with a unique DATETIME in the 
> DSN.
> GDGs provide this in JCL.
> 
> -- gil
> 

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

Re: AW: Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

On Thu, 19 Nov 2015 10:58:01 -0700, Lizette Koehler wrote:

>Gil,
>You can use the symbols for DATE and HOUR and so forth.  I think it is 
>documented  z/OS 2.1.0>z/OS MVS>z/OS MVS Initialization and Tuning 
>Reference>Overview>Sharing parmlib definitions>What are system 
>symbols?>Dynamic system symbols
>
>https://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieae200/dynpsm.htm
>
>
>New symbol Old symbol
>
>   
>
>   
> 
Hmmm...  I think that's new in 2.1.  I haven't tried it.

o If two jobs are submitted close in time, is there a possibility of DSN 
conflict?
  I believe GDG would eliminate this.

o IBM contributors have acknowledged here that there's a timing window:
  if  and  are referenced close to midnight (who'd ever
  schedule a job for midnight!?) a 23 hour 59 minute error might result if
  the date changes between the two references.

  Why doesn't IBM fix that?  Rexx does it right.  JCL developers should read
  the Rexx manual to see how.

-- gil

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

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

[J O Skip Robinson]

I can see the relevant fields only on O(utput) screen, not on ST(atus). There 
are actually two significant fields: Dest, which is the target userid, and 
Status, which shows 'USER'. I believe that 'USER' will prevent a JES2 defined 
destid from hijacking the output. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, November 19, 2015 2:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

On 2015-11-17 15:23, J O Skip Robinson wrote:
> An XMITted file sits in the JES output queue in a designated class (usually 
> B) with the recipient's userid as DEST.  ... 
> 
So administrators must be careful not to assign User IDs that might match 
plausible DESTs.

Can anyone tell me how to obtain DEST via the Rexx SDSF API?
AFAICT, DEST (or DESTN) is a field on the JDS panel but not on the ST panel, 
and address SDSF supports "isfact ST" but not "isfact JDS".

Thanks,
gil


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

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

[Paul Gilmartin]

On 2015-11-17 15:23, J O Skip Robinson wrote:
> An XMITted file sits in the JES output queue in a designated class (usually 
> B) with the recipient's userid as DEST.  ... 
> 
So administrators must be careful not to assign User IDs that might
match plausible DESTs.

Can anyone tell me how to obtain DEST via the Rexx SDSF API?
AFAICT, DEST (or DESTN) is a field on the JDS panel but not on the
ST panel, and address SDSF supports "isfact ST" but not "isfact JDS".

Thanks,
gil

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

Re: Fastest way to read OLDEST GDG entry

[Mike Schwab]

It remains cataloged.  It is just no longer part of the gdg.  Good
thing those thousand or two files were just a few tracks.

On Thu, Nov 19, 2015 at 9:59 AM, J O Skip Robinson
<jo.skip.robin...@sce.com> wrote:
> I haven't experimented with this, but going with NOSCRATCH is likely to cause 
> big problems with DASD GDGs. A data set residing on an SMS-managed volume 
> must be cataloged. It cannot just sit there uncataloged. Irresistible force 
> meets unmovable object.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Tom Marchant
> Sent: Thursday, November 19, 2015 4:54 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Fastest way to read OLDEST GDG entry
>
> On Wed, 18 Nov 2015 23:09:44 -0500, Robert A. Rosenberg wrote:
>
>>At 08:32 -0600 on 11/18/2015, Tom Marchant wrote about Re: Fastest way
>>to read OLDEST GDG entry:
>>
>>>you might want to make sure the GDG is defined with NOSCRATCH before
>>>doing this.
>>
>>Note that NOSCRATCH will (I think) not only leave the V00 of a
>>V01->V00 replacement cataloged (as a normally named file with the V01
>>being in the GDG base) but also do the same as GDG generations roll off
>>due to the limit. Normally once it rolls you would want it deleted.
>
> Correct. And if you set the GDG to NOSRCATCH before replacing a data set, 
> then change the GDG back to SCRATCH, and if a new generation that would have 
> caused an old one to roll off is created during the interval, I suspect that 
> old generation would have to be scratched manually.
>
> --
> Tom Marchant
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Fastest way to read OLDEST GDG entry

[Tom Marchant]

On Wed, 18 Nov 2015 23:09:44 -0500, Robert A. Rosenberg wrote:

>At 08:32 -0600 on 11/18/2015, Tom Marchant wrote about Re: Fastest
>way to read OLDEST GDG entry:
>
>>you might want to make sure the GDG is defined with NOSCRATCH
>>before doing this.
>
>Note that NOSCRATCH will (I think) not only leave the V00 of a
>V01->V00 replacement cataloged (as a normally named file with the V01
>being in the GDG base) but also do the same as GDG generations roll
>off due to the limit. Normally once it rolls you would want it
>deleted.

Correct. And if you set the GDG to NOSRCATCH before replacing a data set, 
then change the GDG back to SCRATCH, and if a new generation that would 
have caused an old one to roll off is created during the interval, I suspect 
that old generation would have to be scratched manually.

-- 
Tom Marchant

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

Re: Fastest way to read OLDEST GDG entry

[John McKown]

On Thu, Nov 19, 2015 at 9:59 AM, J O Skip Robinson  wrote:

> I haven't experimented with this, but going with NOSCRATCH is likely to
> cause big problems with DASD GDGs. A data set residing on an SMS-managed
> volume must be cataloged. It cannot just sit there uncataloged.
> Irresistible force meets unmovable object.
>

I just tested the following on z/OS 1.12. With SMS managed disk data sets,
if the GDS "rolls off" the GDG base and NOSCRATCH is in effect, then the
GDS simply becomes a non-GDS entry which "just happens" to look like a
member of a GDG. I.e. it is not concatenated in with DSN=GDG.BASE nor can
it be referenced via DSN=GDG.BASE(-n), but can be via GDG.BASE.GV00.​



> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
>
-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: Fastest way to read OLDEST GDG entry

[J O Skip Robinson]

I haven't experimented with this, but going with NOSCRATCH is likely to cause 
big problems with DASD GDGs. A data set residing on an SMS-managed volume must 
be cataloged. It cannot just sit there uncataloged. Irresistible force meets 
unmovable object. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Marchant
Sent: Thursday, November 19, 2015 4:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry

On Wed, 18 Nov 2015 23:09:44 -0500, Robert A. Rosenberg wrote:

>At 08:32 -0600 on 11/18/2015, Tom Marchant wrote about Re: Fastest way 
>to read OLDEST GDG entry:
>
>>you might want to make sure the GDG is defined with NOSCRATCH before 
>>doing this.
>
>Note that NOSCRATCH will (I think) not only leave the V00 of a
>V01->V00 replacement cataloged (as a normally named file with the V01
>being in the GDG base) but also do the same as GDG generations roll off 
>due to the limit. Normally once it rolls you would want it deleted.

Correct. And if you set the GDG to NOSRCATCH before replacing a data set, then 
change the GDG back to SCRATCH, and if a new generation that would have caused 
an old one to roll off is created during the interval, I suspect that old 
generation would have to be scratched manually.

--
Tom Marchant


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

Re: Fastest way to read OLDEST GDG entry

[Tom Marchant]

On Thu, 19 Nov 2015 15:59:37 +, J O Skip Robinson wrote:

>I haven't experimented with this, but going with NOSCRATCH is likely to 
>cause big problems with DASD GDGs. A data set residing on an SMS-managed 
>volume must be cataloged.

It has been a long time since I looked at this, but what I remember is 
that GDGs were a special case. For one thing, with SMS, a data set is 
cataloged at allocation time, not at step end like it was before.

One consequence of that is that is that a generation may be scratched 
as soon as the new one is allocated, rather than wait until the step 
ends successfully.

Consider a new GDG created with NEW,CATLG,DELETE. Before SMS, the 
old generation was scratched at the time the new one is cataloged at 
the end of the step, when the new one is cataloged.

As a result, the idea of a generation being rolled in and rolled out was 
created. The data set is cataloged, but is not cataloged as part of the 
GDG.

-- 
Tom Marchant

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

AW: Re: Fastest way to read OLDEST GDG entry

[John Mattson]

Let's think outside this box a minute.  GDG's were designed to group
similar records by generation. The fact that they work for other things is
just a bonus.  This case is using GDG's as a "store and forward" type of
process of unique files and GDG's are not designed for this.  Two real
solutions come to mind. 1) use a store-end-forward processor like MQSeries
or 2) Single thread this so that each one is read/processed/deleted as it
comes in, and no more can come in until that one is finished. (I doubt that
a new GDG may be created while you are reading the oldest gdg anyhow).
   A third possibility which is kludgy would be to create each new DS with
a unique DATETIME in the DSN and then do the catalog list and search for
the oldest date.  No roll-off, no problems with new GDGs coming in.

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

Re: Fastest way to read OLDEST GDG entry

[Shmuel Metz (Seymour J.)]

In <564bd206.3080...@tombrennansoftware.com>, on 11/17/2015
   at 05:19 PM, Tom Brennan  said:

>I assumed LISTCAT wasn't calling CSI.

CSI didn't exist in the 1970's; IDCAMS, including LISTC, uses SVC 26.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Fastest way to read OLDEST GDG entry

[J O Skip Robinson]

This happened some years ago, different incident. We had a nightly job that ran 
on four different parallel sysplexes to [list catalog stuff]. Don’t remember 
the details. Essentially the same job ran on three sysplexes in about 2 
minutes. On the fourth it ran over 20 minutes. I looked at the environments to 
see what was different in molasses world. The only difference I could see was 
that the three speedy sysplexes were set up for GRS star. The fourth, because 
it had only one active member, was still GRS ring. (I was stingy in those days 
with CF storage.) So on a lark I converted Mr. Snail to GRS star. From then on 
the job ran in 2 minutes. Sounds like a tall tale, but it really happened.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Brennan
Sent: Tuesday, November 17, 2015 5:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry

Paul Gilmartin wrote:
> Naively, I'd expect that LISTCAT use CSI, or something very similar.

Years ago a Storage Admin mentioned that his "List every dataset" 
nightly job was running more than an hour.  I was playing around with CSI at 
the time (via assembler) and modified some existing code to list every alias, 
and then every dsn under each alias.  I think the result ran in less than 5 
minutes, so at the time I assumed LISTCAT wasn't calling CSI.  Maybe things 
have changed though.


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

Re: Fastest way to read OLDEST GDG entry

[Tom Marchant]

On Tue, 17 Nov 2015 22:05:27 -0600, Joel C. Ewing  wrote:

>After several decades of using MVS I finally ran into a case where I
>thought GDS/GDG versioning might be useful and used it  to create a
>corrected version of a GDS generation using V01 to make it obvious it
>was a corrected version.
>
>I was lucky and didn't shoot myself in the foot.  Somehow I was thinking
>there would be an opportunity to verify things were cool before trashing
>the GV00 version, but the instant the GV01 version is cataloged
>the corresponding Gv00 version scratches!

I haven't done it, so I can't verify what the doc says, but Using Data Sets 
has this to say under the topic Absolute Generation and Version Numbers:


 You can catalog a new version of a specific generation automatically by 
specifying the old generation number along with a new version number. For 
example, if generation A.B.C.G0005V00 is cataloged and you now create 
and catalog A.B.C.G0005V01, the new entry is cataloged in the location 
previously occupied by A.B.C.G0005V00. The old entry is removed from the 
catalog, to make room for the newer version, and may or may not be 
scratched depending on what limit processing options are specified for the 
GDG base.


So you might want to make sure the GDG is defined with NOSCRATCH 
before doing this.

-- 
Tom Marchant

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

Re: Fastest way to read OLDEST GDG entry

[Robert A. Rosenberg]

At 08:32 -0600 on 11/18/2015, Tom Marchant wrote about Re: Fastest 
way to read OLDEST GDG entry:



I haven't done it, so I can't verify what the doc says, but Using Data Sets
has this to say under the topic Absolute Generation and Version Numbers:


 You can catalog a new version of a specific generation automatically by
specifying the old generation number along with a new version number. For
example, if generation A.B.C.G0005V00 is cataloged and you now create
and catalog A.B.C.G0005V01, the new entry is cataloged in the location
previously occupied by A.B.C.G0005V00. The old entry is removed from the
catalog, to make room for the newer version, and may or may not be
scratched depending on what limit processing options are specified for the
GDG base.


So you might want to make sure the GDG is defined with NOSCRATCH
before doing this.


Note that NOSCRATCH will (I think) not only leave the V00 of a 
V01->V00 replacement cataloged (as a normally named file with the V01 
being in the GDG base) but also do the same as GDG generations roll 
off due to the limit. Normally once it rolls you would want it 
deleted.


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

Re: Fastest way to read OLDEST GDG entry

[Walt Farrell]

On Tue, 17 Nov 2015 03:06:10 -0700, Lizette Koehler  
wrote:

>I have a request to read the oldest GDG to process.  But CSI is slow sometimes
>and better other times.

How slow is CSI when it's slow, and have you tried to figure out why? More 
importantly, is it so slow that it impacts your processing unacceptably?

CSI is a better approach than reading the output of LISTC, in my opinion, as 
the LISTC output is not a programming interface.

But whatever you do, you may have a TOCTTOU (time of check to time of use) 
issue. By the time you figure out what the oldest GDG member is, and go to read 
it, it may no longer exist. So don't forget to put in some error checking for 
that case.

-- 
Walt

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

Re: Fastest way to read OLDEST GDG entry

[Greg Shirey]

Why does the process need to delete the oldest GDG after it reads it?   Won't 
the oldest one be deleted when the next +1 GDG is created? 

Regards,
Greg Shirey
Ben E. Keith Company 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, November 17, 2015 4:06 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Fastest way to read OLDEST GDG entry

I have a request to read the oldest GDG to process.  But CSI is slow sometimes 
and better other times.

So here is the basic request
File lands as a GDG often

The process needs to read the oldest GDG and then delete it.

GDGs must be read in correct order for time/date processing

I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the Base.  But 
using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.

Is there another process that could be used to identify the OLDEST GDG for 
Input and then delete that GDG?  Or is there another way to handle this 
situation?  I was going to see if the LISTC could be faster than CSI.  

The process should be native to z/OS and not a vendor product.  Or 
shareware/freeware is okay.

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

Re: Fastest way to read OLDEST GDG entry

[Elardus Engelbrecht]

Lizette Koehler wrote:

>I have a request to read the oldest GDG to process.  

I believe someone asked at SHARE, but my memory has been rolled out ala GDG... 
gr

Something like these:

MY.GDG(LATEST)  (same as (0) )
MY.GDG(OLDEST)
MY.GDG(LATEST-7)
MY.GDG(LATEST+1)  (for creation of a new version of GDDG?)

I tried this before posting on a GDG of 5 with JCL DD MY.GDG(-6). Only got a 
JCL error as documented...

>But CSI is slow sometimes and better other times.

Limiting the scope of CSI searches could speed things up, unless you want to do 
a big search.

>So here is the basic request File lands as a GDG often
>The process needs to read the oldest GDG and then delete it.
>GDGs must be read in correct order for time/date processing

>Or is there another way to handle this situation?  I was going to see if the 
>LISTC could be faster than CSI.

LISTC could be faster. Just use the First ASSOCIATIONS in GDG BASE output.

But then wraparound of version numbers could be a problem.

Groete / Greetings
Elardus Engelbrecht

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

Re: Fastest way to read OLDEST GDG entry

[Bill Ashton]

I apologize - I missed the "read and..." part of the process...I would opt
for reading the output of a ListCat, then you can programmatically allocate
the oldest GDS, process it and then delete it.

On Tue, Nov 17, 2015 at 7:21 AM, Mike Schwab 
wrote:

> If you delete all GDG members, the next one created will be G0001V00.
>
> TSO Batch
> IF dsn(-255) exist THEN ...
>
> On Tue, Nov 17, 2015 at 4:06 AM, Lizette Koehler
>  wrote:
> > I have a request to read the oldest GDG to process.  But CSI is slow
> sometimes
> > and better other times.
> >
> > So here is the basic request
> > File lands as a GDG often
> >
> > The process needs to read the oldest GDG and then delete it.
> >
> > GDGs must be read in correct order for time/date processing
> >
> > I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the
> Base.  But
> > using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to
> work.
> >
> > Is there another process that could be used to identify the OLDEST GDG
> for Input
> > and then delete that GDG?  Or is there another way to handle this
> situation?  I
> > was going to see if the LISTC could be faster than CSI.
> >
> > The process should be native to z/OS and not a vendor product.  Or
> > shareware/freeware is okay.
> >
> > Thanks
> >
> > Lizette Koehler
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
> --
> Mike A Schwab, Springfield IL USA
> Where do Forest Rangers go to get away from it all?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Thank you and best regards,
*Billy Ashton*

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

Re: Fastest way to read OLDEST GDG entry

[Tom Marchant]

On Tue, 17 Nov 2015 17:12:09 +0100, Peter Hunkeler  wrote:

>
>> Check out the GDGORDER parameter. It became available in z/OS 2.2
>
>This actually became available with z/OS V2.1

Yes. Thanks for the correction.

-- 
Tom Marchant

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

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

> Check out the GDGORDER parameter. It became available in z/OS 2.2 and allows 
> you to process generation data sets in the order they were created.



This actually became available with z/OS V2.1
And it doesn't help with her request to process the latest GDS *only*


--
Peter Hunkeler



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

Re: Fastest way to read OLDEST GDG entry

[Mike Schwab]

Latest GDG is (-000) .  They were wanting the OLDEST GDG with an
uncertain number of entries.

On Tue, Nov 17, 2015 at 10:12 AM, Peter Hunkeler  wrote:
>
>> Check out the GDGORDER parameter. It became available in z/OS 2.2 and allows 
>> you to process generation data sets in the order they were created.
>
>
>
> This actually became available with z/OS V2.1
> And it doesn't help with her request to process the latest GDS *only*
>
>
> --
> Peter Hunkeler
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Fastest way to read OLDEST GDG entry

[Bill Ashton]

If the intention is to just delete the oldest generation, why not run
IEBGENER of a dummy file to create the new +1, and this will make the
oldest generation fall off. Then you could run a job to delete the (0)
generation.

On Tue, Nov 17, 2015 at 6:26 AM, Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> Lizette Koehler wrote:
>
> >I have a request to read the oldest GDG to process.
>
> I believe someone asked at SHARE, but my memory has been rolled out ala
> GDG... gr
>
> Something like these:
>
> MY.GDG(LATEST)  (same as (0) )
> MY.GDG(OLDEST)
> MY.GDG(LATEST-7)
> MY.GDG(LATEST+1)  (for creation of a new version of GDDG?)
>
> I tried this before posting on a GDG of 5 with JCL DD MY.GDG(-6). Only got
> a JCL error as documented...
>
> >But CSI is slow sometimes and better other times.
>
> Limiting the scope of CSI searches could speed things up, unless you want
> to do a big search.
>
> >So here is the basic request File lands as a GDG often
> >The process needs to read the oldest GDG and then delete it.
> >GDGs must be read in correct order for time/date processing
>
> >Or is there another way to handle this situation?  I was going to see if
> the LISTC could be faster than CSI.
>
> LISTC could be faster. Just use the First ASSOCIATIONS in GDG BASE output.
>
> But then wraparound of version numbers could be a problem.
>
> Groete / Greetings
> Elardus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Thank you and best regards,
*Billy Ashton*

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

Re: Fastest way to read OLDEST GDG entry

[Mike Schwab]

If you delete all GDG members, the next one created will be G0001V00.

TSO Batch
IF dsn(-255) exist THEN ...

On Tue, Nov 17, 2015 at 4:06 AM, Lizette Koehler
 wrote:
> I have a request to read the oldest GDG to process.  But CSI is slow sometimes
> and better other times.
>
> So here is the basic request
> File lands as a GDG often
>
> The process needs to read the oldest GDG and then delete it.
>
> GDGs must be read in correct order for time/date processing
>
> I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the Base.  But
> using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
>
> Is there another process that could be used to identify the OLDEST GDG for 
> Input
> and then delete that GDG?  Or is there another way to handle this situation?  
> I
> was going to see if the LISTC could be faster than CSI.
>
> The process should be native to z/OS and not a vendor product.  Or
> shareware/freeware is okay.
>
> Thanks
>
> Lizette Koehler
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

Processing all GDSs using the base entry is kind of like processing a DD 
concatenation.

 I can't tell the details from memory, but in Assembler you can code so that 
you get control when the system reaches the end of one dsn in the 
concatenation, just before it is going to open the next one. I seem to remember 
it an OPEN exit.

If reading all GDSs via base entry behaves similarly, you could just terminate 
processing upon first invocation of that code. Using GDGORDER=FIFO, your 
program would do what you want. The code would need to find the actual dsn of 
the (first) data set right after open, so it can delete it.


I can dig out some code if you like to further follow this vague idea.

--
Peter Hunkeler



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

Re: Fastest way to read OLDEST GDG entry

[Sri h Kolusu]

Lizette,

Check out this smart DFSORT trick "Copy GDG records in first in, first out 
order" here

http://www.ibm.com/support/docview.wss?uid=isg3T794

In step S2 you need to use the following control cards to just limit the 
oldest GDG generation 

//SYSINDD * 
  OPTION COPY,STOPAFT=1 
  INCLUDE COND=(4,7,CH,EQ,C'NONVSAM') 
  INREC BUILD=(C'//SYSUT1 DD DISP=SHR,DSN=',17,44,80:X) 
//* 

Further if you have any questions please let me know

There are couple of other GDG related tricks listed in there which might 
be of use


Thanks,
Kolusu
DFSORT Development
IBM Corporation



From:   Lizette Koehler 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   11/17/2015 03:06 AM
Subject:Fastest way to read OLDEST GDG entry
Sent by:IBM Mainframe Discussion List 



I have a request to read the oldest GDG to process.  But CSI is slow 
sometimes
and better other times.

So here is the basic request
File lands as a GDG often

The process needs to read the oldest GDG and then delete it.

GDGs must be read in correct order for time/date processing

I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the Base. 
But
using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to 
work.

Is there another process that could be used to identify the OLDEST GDG for 
Input
and then delete that GDG?  Or is there another way to handle this 
situation?  I
was going to see if the LISTC could be faster than CSI. 

The process should be native to z/OS and not a vendor product.  Or
shareware/freeware is okay.

Thanks

Lizette Koehler

--
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: Fastest way to read OLDEST GDG entry

[Shmuel Metz (Seymour J.)]

In
,
on 11/17/2015
   at 07:58 AM, John McKown  said:

>I don't know why the OP says that IGGCSI00 is "slow".

Or why LISTC would be any faster.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: AW: Re: Fastest way to read OLDEST GDG entry

[Shmuel Metz (Seymour J.)]

In , on 11/17/2015
   at 03:59 PM, Peter Hunkeler  said:

> I can't tell the details from memory, but in Assembler you can code
>so that you get control when the system reaches the end of one dsn in
>the concatenation, just before it is going to open the next one.

That might work if you have the unlike attributes bit set, but since
you are only going to process one data set, why not use RDJFCB to get
the name?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Fastest way to read OLDEST GDG entry

[Tom Marchant]

On Tue, 17 Nov 2015 07:06:33 -0700, Lizette Koehler wrote:

>So GDGs are typically in LIFO order, for this process the first one created
>needs to be process first and then read and processed to the current version.

Check out the GDGORDER parameter. It became available in z/OS 2.2 and allows 
you to process generation data sets in the order they were created.

>I have heard the GDG limit in z/OS V2.2 will be higher, so it may not be much 
>of
>an issue for limit values.

The limit can be 999, but it is not automatically changed.

-- 
Tom Marchant

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

Re: Fastest way to read OLDEST GDG entry

[Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)]

It seems you could do a quick LISTCAT in step one of a job, then in step 2 
parse out the LISTCAT for the GDG via REXX and sort the GDG's in descending 
order and generate the JCL to process the data and submit?  It's a little work, 
but it should be fairly easy to implement.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, November 17, 2015 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fastest way to read OLDEST GDG entry

So for this process, the files need to be read in FIFO order of creation.  The 
use of the GDG rather than a HLQ.XXX.Dx.T naming convention was to make 
it easier to process the files.

So GDGs are typically in LIFO order, for this process the first one created 
needs to be process first and then read and processed to the current version.

I believe date/time read of a seq file has always been a challenge on the 
mainframe as the naming convention does not allow for a more granular read of 
many files into input.

So I have the following conditions

File1 created on date and time
File2 created on date and time+15 mins
File3 created on date and time+60 mins

Then I need to read File1 first, process it, delete it Next file2, process it 
and delete it Next File3, process it and delete it

All the time new files are coming in.

If I delete the GDG base I may delete data that is not processed.

The file cannot be mod'd due to the face it is a TSO XMIT'd file.  I need to 
RECEIVE the GDG (oldest version) process it and then delete what I have just 
processed.

I have heard the GDG limit in z/OS V2.2 will be higher, so it may not be much 
of an issue for limit values.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Greg Shirey
> Sent: Tuesday, November 17, 2015 6:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fastest way to read OLDEST GDG entry
> 
> Why does the process need to delete the oldest GDG after it reads it?   Won't
the
> oldest one be deleted when the next +1 GDG is created?
> 
> Regards,
> Greg Shirey
> Ben E. Keith Company
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Tuesday, November 17, 2015 4:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Fastest way to read OLDEST GDG entry
> 
> I have a request to read the oldest GDG to process.  But CSI is slow 
> sometimes
and
> better other times.
> 
> So here is the basic request
> File lands as a GDG often
> 
> The process needs to read the oldest GDG and then delete it.
> 
> GDGs must be read in correct order for time/date processing
> 
> I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the 
> Base.  But
using
> //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
> 
> Is there another process that could be used to identify the OLDEST GDG 
> for
Input and
> then delete that GDG?  Or is there another way to handle this 
> situation?  I
was going
> to see if the LISTC could be faster than CSI.
> 
> The process should be native to z/OS and not a vendor product.  Or 
> shareware/freeware is okay.

--
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: Fastest way to read OLDEST GDG entry

[John McKown]

On Tue, Nov 17, 2015 at 7:49 AM, Greg Shirey  wrote:

> Why does the process need to delete the oldest GDG after it reads it?
>  Won't the oldest one be deleted when the next +1 GDG is created?
>

​Not necessarily. That only happens if the number of GDGs which are "rolled
in" are at the limit.​

It might be interesting to understand _exactly_ what the OP is trying to
accomplish by reading in the "oldest" GDG and exactly how said generations
are being created. I don't know why the OP says that IGGCSI00 is "slow". I
may, when I feel better, look at writing a C program which uses IGGCSI00 to
do "something or other" like this.

Another thought, from way out in left field, is to create a SUBSYS=, say
called LGDG, which would do exactly what the OP wants. Something like:

//SYSUT1 DD SUBSYS=(LGDG,'gdg.base.name')

which looks up "gdg.base.name" and then allocates the generation (SVC 99)
with the lowest generation number. Of course, this does not allow the
deletion of said GDG. But that could possibly be done with other options.


>
> Regards,
> Greg Shirey
> Ben E. Keith Company
>

-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: Fastest way to read OLDEST GDG entry

[Lizette Koehler]

So the intent is to create lots of GDGs throughout the day.

Then the process needs to read the oldest GDG, process it, delete it, move on 
to the next oldest GDG.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Bill Ashton
> Sent: Tuesday, November 17, 2015 5:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fastest way to read OLDEST GDG entry
> 
> If the intention is to just delete the oldest generation, why not run 
> IEBGENER of a
> dummy file to create the new +1, and this will make the oldest generation 
> fall off.
> Then you could run a job to delete the (0) generation.
> 
> On Tue, Nov 17, 2015 at 6:26 AM, Elardus Engelbrecht <
> elardus.engelbre...@sita.co.za> wrote:
> 
> > Lizette Koehler wrote:
> >
> > >I have a request to read the oldest GDG to process.
> >
> > I believe someone asked at SHARE, but my memory has been rolled out
> > ala GDG... gr
> >
> > Something like these:
> >
> > MY.GDG(LATEST)  (same as (0) )
> > MY.GDG(OLDEST)
> > MY.GDG(LATEST-7)
> > MY.GDG(LATEST+1)  (for creation of a new version of GDDG?)
> >
> > I tried this before posting on a GDG of 5 with JCL DD MY.GDG(-6). Only
> > got a JCL error as documented...
> >
> > >But CSI is slow sometimes and better other times.
> >
> > Limiting the scope of CSI searches could speed things up, unless you
> > want to do a big search.
> >
> > >So here is the basic request File lands as a GDG often The process
> > >needs to read the oldest GDG and then delete it.
> > >GDGs must be read in correct order for time/date processing
> >
> > >Or is there another way to handle this situation?  I was going to see
> > >if
> > the LISTC could be faster than CSI.
> >
> > LISTC could be faster. Just use the First ASSOCIATIONS in GDG BASE output.
> >
> > But then wraparound of version numbers could be a problem.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >

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

Re: Fastest way to read OLDEST GDG entry

[Jousma, David]

Yikes.  What happens if "lots of GDG's" goes beyond the limit for the GDG?  
Lost data?  How much data are we talking about here?   Maybe just a new GDG by 
day, and keep modding onto it?  Can the data be sorted down so that you can 
process oldest first?

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, November 17, 2015 8:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fastest way to read OLDEST GDG entry

So the intent is to create lots of GDGs throughout the day.

Then the process needs to read the oldest GDG, process it, delete it, move on 
to the next oldest GDG.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Bill Ashton
> Sent: Tuesday, November 17, 2015 5:21 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fastest way to read OLDEST GDG entry
> 
> If the intention is to just delete the oldest generation, why not run 
> IEBGENER of a dummy file to create the new +1, and this will make the oldest 
> generation fall off.
> Then you could run a job to delete the (0) generation.
> 
> On Tue, Nov 17, 2015 at 6:26 AM, Elardus Engelbrecht < 
> elardus.engelbre...@sita.co.za> wrote:
> 
> > Lizette Koehler wrote:
> >
> > >I have a request to read the oldest GDG to process.
> >
> > I believe someone asked at SHARE, but my memory has been rolled out 
> > ala GDG... gr
> >
> > Something like these:
> >
> > MY.GDG(LATEST)  (same as (0) )
> > MY.GDG(OLDEST)
> > MY.GDG(LATEST-7)
> > MY.GDG(LATEST+1)  (for creation of a new version of GDDG?)
> >
> > I tried this before posting on a GDG of 5 with JCL DD MY.GDG(-6). 
> > Only got a JCL error as documented...
> >
> > >But CSI is slow sometimes and better other times.
> >
> > Limiting the scope of CSI searches could speed things up, unless you 
> > want to do a big search.
> >
> > >So here is the basic request File lands as a GDG often The process 
> > >needs to read the oldest GDG and then delete it.
> > >GDGs must be read in correct order for time/date processing
> >
> > >Or is there another way to handle this situation?  I was going to 
> > >see if
> > the LISTC could be faster than CSI.
> >
> > LISTC could be faster. Just use the First ASSOCIATIONS in GDG BASE output.
> >
> > But then wraparound of version numbers could be a problem.
> >
> > Groete / Greetings
> > Elardus Engelbrecht
> >

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

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: Fastest way to read OLDEST GDG entry

[Lizette Koehler]

So for this process, the files need to be read in FIFO order of creation.  The
use of the GDG rather than a HLQ.XXX.Dx.T naming convention was to make
it easier to process the files.

So GDGs are typically in LIFO order, for this process the first one created
needs to be process first and then read and processed to the current version.

I believe date/time read of a seq file has always been a challenge on the
mainframe as the naming convention does not allow for a more granular read of
many files into input.

So I have the following conditions

File1 created on date and time
File2 created on date and time+15 mins
File3 created on date and time+60 mins

Then I need to read File1 first, process it, delete it
Next file2, process it and delete it
Next File3, process it and delete it

All the time new files are coming in.

If I delete the GDG base I may delete data that is not processed.

The file cannot be mod'd due to the face it is a TSO XMIT'd file.  I need to
RECEIVE the GDG (oldest version) process it and then delete what I have just
processed.

I have heard the GDG limit in z/OS V2.2 will be higher, so it may not be much of
an issue for limit values.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Greg Shirey
> Sent: Tuesday, November 17, 2015 6:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fastest way to read OLDEST GDG entry
> 
> Why does the process need to delete the oldest GDG after it reads it?   Won't
the
> oldest one be deleted when the next +1 GDG is created?
> 
> Regards,
> Greg Shirey
> Ben E. Keith Company
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Tuesday, November 17, 2015 4:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Fastest way to read OLDEST GDG entry
> 
> I have a request to read the oldest GDG to process.  But CSI is slow sometimes
and
> better other times.
> 
> So here is the basic request
> File lands as a GDG often
> 
> The process needs to read the oldest GDG and then delete it.
> 
> GDGs must be read in correct order for time/date processing
> 
> I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the Base.  But
using
> //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
> 
> Is there another process that could be used to identify the OLDEST GDG for
Input and
> then delete that GDG?  Or is there another way to handle this situation?  I
was going
> to see if the LISTC could be faster than CSI.
> 
> The process should be native to z/OS and not a vendor product.  Or
> shareware/freeware is okay.

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

Re: Fastest way to read OLDEST GDG entry

[Richard Pinion]

If you have the FDR reporting tools, you could select, sort, and 
then generate the JCL to accomplish this.



--- z...@cdc.gov wrote:

From: "Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)" <z...@cdc.gov>
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fastest way to read OLDEST GDG entry
Date: Tue, 17 Nov 2015 14:17:04 +

It seems you could do a quick LISTCAT in step one of a job, then in step 2 
parse out the LISTCAT for the GDG via REXX and sort the GDG's in descending 
order and generate the JCL to process the data and submit?  It's a little work, 
but it should be fairly easy to implement.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Tuesday, November 17, 2015 9:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fastest way to read OLDEST GDG entry

So for this process, the files need to be read in FIFO order of creation.  The 
use of the GDG rather than a HLQ.XXX.Dx.T naming convention was to make 
it easier to process the files.

So GDGs are typically in LIFO order, for this process the first one created 
needs to be process first and then read and processed to the current version.

I believe date/time read of a seq file has always been a challenge on the 
mainframe as the naming convention does not allow for a more granular read of 
many files into input.

So I have the following conditions

File1 created on date and time
File2 created on date and time+15 mins
File3 created on date and time+60 mins

Then I need to read File1 first, process it, delete it Next file2, process it 
and delete it Next File3, process it and delete it

All the time new files are coming in.

If I delete the GDG base I may delete data that is not processed.

The file cannot be mod'd due to the face it is a TSO XMIT'd file.  I need to 
RECEIVE the GDG (oldest version) process it and then delete what I have just 
processed.

I have heard the GDG limit in z/OS V2.2 will be higher, so it may not be much 
of an issue for limit values.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Greg Shirey
> Sent: Tuesday, November 17, 2015 6:50 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Fastest way to read OLDEST GDG entry
> 
> Why does the process need to delete the oldest GDG after it reads it?   Won't
the
> oldest one be deleted when the next +1 GDG is created?
> 
> Regards,
> Greg Shirey
> Ben E. Keith Company
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Tuesday, November 17, 2015 4:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Fastest way to read OLDEST GDG entry
> 
> I have a request to read the oldest GDG to process.  But CSI is slow 
> sometimes
and
> better other times.
> 
> So here is the basic request
> File lands as a GDG often
> 
> The process needs to read the oldest GDG and then delete it.
> 
> GDGs must be read in correct order for time/date processing
> 
> I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the 
> Base.  But
using
> //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
> 
> Is there another process that could be used to identify the OLDEST GDG 
> for
Input and
> then delete that GDG?  Or is there another way to handle this 
> situation?  I
was going
> to see if the LISTC could be faster than CSI.
> 
> The process should be native to z/OS and not a vendor product.  Or 
> shareware/freeware is okay.

--
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




_
Netscape.  Just the Net You Need.

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

Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

On Tue, 17 Nov 2015 10:17:41 -0600, Mike Schwab wrote:

>Latest GDG is (-000) .  They were wanting the OLDEST GDG with an
>uncertain number of entries.
>
And no one has asked why.  Nor what problem the OP needs to solve.

Binary search starting with an a priori known maximal relative generation?

But how many specific catalog searches break even with a single generic search?

-- gil

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

Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

On Tue, 17 Nov 2015 18:41:38 +0100, Lucas Rosalen wrote:

>8th email on the thread describes why and the "problem" to solve
> 
That seems to be: 
https://listserv.ua.edu/cgi-bin/wa?A2=ind1511=ibm-main=344282
Thanks.

Keep an external index?

z/OS UNIX directory search is fast; I don't know how it compares to Classic 
catalog
search.  Shadow your G00*V00 names with empty files in a UNIX directory and
use that as an index.  Bizarre?  Well, before VSAM programmers used empty PDS
members as similar placeholders.

Directory search in z/OS may be faster than in competing UNIXen because z/OS
indexes its directories.  Don't know about the others.

And readdir() will return the smallest (oldest?) G00*V00 first, so you could
bail out there.

VSAM index?  PDSE with empty members used as index?  Deleting the lowest
named PDS member is the worst performance case; don't know about PDSE.

How many is "lots"?

What makes "V00" ever Vnn, where N<>0?

-- gil

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

Re: Fastest way to read OLDEST GDG entry

[Lucas Rosalen]

8th email on the thread describes why and the "problem" to solve

Lucas
On Nov 17, 2015 18:28, "Paul Gilmartin" <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Tue, 17 Nov 2015 10:17:41 -0600, Mike Schwab wrote:
>
> >Latest GDG is (-000) .  They were wanting the OLDEST GDG with an
> >uncertain number of entries.
> >
> And no one has asked why.  Nor what problem the OP needs to solve.
>
> Binary search starting with an a priori known maximal relative generation?
>
> But how many specific catalog searches break even with a single generic
> search?
>
> -- gil
>
> --
> 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: Fastest way to read OLDEST GDG entry

[John McKown]

Some example REXX which might be of some help:

/* REXX */
X=OUTTRAP("OUT.","*");
"LISTC ENT('gdg.base.name') ALL"
X=OUTTRAP("OFF")
DSN='?'
DO I=1 TO OUT.0
   IF 'NONVSAM-' <> LEFT(STRIP(OUT.I,'L'),8) THEN ITERATE
   DSN=WORD(TRANSLATE(OUT.I,' ','-'),2)
   LEAVE
END
IF DSN='?' THEN EXIT(12) /* NO DSN FOUND */
"RECEIVE INDATASET('"DSN"')"

​I recall that doing a RECEIVE in REXX is "iffy". Perhaps another person
remembers how to do this?​


-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: Fastest way to read OLDEST GDG entry

[Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR)]

Another fairly slick way to do this would be to list the GDG base and then 
parse out the LIMIT.  You could then go directly to the file 
..(-00"LIMIT-1") which should be the oldest file.   This is all 
assuming that you have created enough files to reach the limit.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, November 17, 2015 1:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Fastest way to read OLDEST GDG entry

Some example REXX which might be of some help:

/* REXX */
X=OUTTRAP("OUT.","*");
"LISTC ENT('gdg.base.name') ALL"
X=OUTTRAP("OFF")
DSN='?'
DO I=1 TO OUT.0
   IF 'NONVSAM-' <> LEFT(STRIP(OUT.I,'L'),8) THEN ITERATE
   DSN=WORD(TRANSLATE(OUT.I,' ','-'),2)
   LEAVE
END
IF DSN='?' THEN EXIT(12) /* NO DSN FOUND */ "RECEIVE INDATASET('"DSN"')"

​I recall that doing a RECEIVE in REXX is "iffy". Perhaps another person 
remembers how to do this?​


-- 

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: Fastest way to read OLDEST GDG entry

[J O Skip Robinson]

Unlike CLIST, REXX is tricky for handling subcommands and prompt responses, 
which need to be QUEUEd (or PUSHed) onto the stack before the main command is 
issued. This can be problematic when the response cannot be known in advance of 
issuing the command. For example, the data set name to use for RECEIVE may 
depend on the data set XMITted. One solution might be to issue RECEIVE, trap 
the output that contains the data set name, and END without actually receiving 
the data set. Then construct a prompt response based the known data set name, 
QUEUE the appropriate response, and issue RECEIVE again. Might be undoable if 
more than one data set is waiting for RECEIVE.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, November 17, 2015 10:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry

Some example REXX which might be of some help:

/* REXX */
X=OUTTRAP("OUT.","*");
"LISTC ENT('gdg.base.name') ALL"
X=OUTTRAP("OFF")
DSN='?'
DO I=1 TO OUT.0
   IF 'NONVSAM-' <> LEFT(STRIP(OUT.I,'L'),8) THEN ITERATE
   DSN=WORD(TRANSLATE(OUT.I,' ','-'),2)
   LEAVE
END
IF DSN='?' THEN EXIT(12) /* NO DSN FOUND */ "RECEIVE INDATASET('"DSN"')"

​I recall that doing a RECEIVE in REXX is "iffy". Perhaps another person 
remembers how to do this?​


-- 

Schrodinger's backup: The condition of any backup is unknown until a restore is 
attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

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: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

On Tue, 17 Nov 2015 03:06:10 -0700, Lizette Koehler wrote:

>I have a request to read the oldest GDG to process.  But CSI is slow sometimes
>and better other times.
>
>So here is the basic request
>File lands as a GDG often
>
>The process needs to read the oldest GDG and then delete it.
>
>GDGs must be read in correct order for time/date processing
>
>I tried GDGORDER on the JCL for z/OS V2.1 and it works great on the Base.  But
>using //DDSTMT DD DISP=SHR,DSN=GDDG(0),GDGORDER=FIFO does not seem to work.
>
>Is there another process that could be used to identify the OLDEST GDG for 
>Input
>and then delete that GDG?  Or is there another way to handle this situation?  I
>was going to see if the LISTC could be faster than CSI.
>
>The process should be native to z/OS and not a vendor product.  Or
>shareware/freeware is okay.
>
For CSI, I find a SHARE presentation about a year old:
https://share.confex.com/share/122/webprogram/Session14633.html

Which mentions SYS1.SAMPLIB(IGGCSIRX).  Trying that, it returns GDG bases
but not members.  Or I don't know enough about catalogs to supply the
correct filters.

It returns 58 entries in 0.4 seconds elapsed.

-- gil

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

Re: Fastest way to read OLDEST GDG entry

[Paul Gilmartin]

On Tue, 17 Nov 2015 17:57:46 -0600, Paul Gilmartin wrote:

>On Tue, 17 Nov 2015 03:06:10 -0700, Lizette Koehler wrote:
>>
>>Is there another process that could be used to identify the OLDEST GDG for 
>>Input
>>and then delete that GDG?  Or is there another way to handle this situation?  
>>I
>>was going to see if the LISTC could be faster than CSI.
>> 
Naively, I'd expect that LISTCAT use CSI, or something very similar.

>For CSI, I find a SHARE presentation about a year old:
>https://share.confex.com/share/122/webprogram/Session14633.html
>
>Which mentions SYS1.SAMPLIB(IGGCSIRX).  Trying that, it returns GDG bases
>but not members.  Or I don't know enough about catalogs to supply the
>correct filters.
>
Looking further at:
z/OS 2.1.0>z/OS DFSMS>z/OS DFSMS Managing Catalogs>Catalog Search Interface 
User's Guide>Selection Criteria Fields
z/OS DFSMS Managing Catalogs
SC23-6853-00 
... the field descriptions seem to be garbled.  I see:

132(84) Character   1   CSIDTYPSEntry types to be 
returned. All types = blanks

... one character.  But in the detail below, I see:
CSIDTYPS, Entry Types
...
The valid types can be mixed and in any order. Blanks cannot separate the 
types. For instance,
“ABH” might be specified to get only the non-VSAM, generation data group 
and generation
data set entries.

... multiple characters.

-- gil

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

Re: Fastest way to read OLDEST GDG entry

[Mike Schwab]

On Tue, Nov 17, 2015 at 12:23 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> What makes "V00" ever Vnn, where N<>0?
>
> -- gil

Possibly an IEBGENER from data.set.name(-000) to data.set.name(-000)
DISP=(NEW,CATLG).
I did do an IEBGENER data.set.name.G0123V00 to data.set.name.G0123V01
DISP=(NEW,CATLG).
I had to fix some bad records with IEBGENER control cards.

-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Fastest way to read OLDEST GDG entry

[Shane Ginnane]

On Tue, 17 Nov 2015 18:20:34 -0600, Paul Gilmartin wrote:

>On Tue, 17 Nov 2015 17:57:46 -0600, Paul Gilmartin wrote:
>
>>On Tue, 17 Nov 2015 03:06:10 -0700, Lizette Koehler wrote:
>>>
>>>Is there another process that could be used to identify the OLDEST GDG for 
>>>Input
>>>and then delete that GDG?  Or is there another way to handle this situation? 
>>> I
>>>was going to see if the LISTC could be faster than CSI.
>>> 
>Naively, I'd expect that LISTCAT use CSI, or something very similar.

Been a while, but the samples I looked at were just that - and did need some 
cleaning up. Mark Z will have a bunch of good examples for sure.
LISTCAT using generics was awful - I seem to remember some fixes for that a 
while back - but CSI when properly constructed was awesome. Done in assembler 
more so, as expected.
It looks like it finds *everything* - including the connector records for cats 
that have been disconnected. I found myself running through mastercats I 
shouldn't have been even able to see. Like I said, if you are careful, CSI is 
awesome.

Shane ...

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

Re: Fastest way to read OLDEST GDG entry

[Clark Morris]

On 17 Nov 2015 10:23:30 -0800, in bit.listserv.ibm-main you wrote:

>On Tue, 17 Nov 2015 18:41:38 +0100, Lucas Rosalen wrote:
>
>>8th email on the thread describes why and the "problem" to solve
>> 
>That seems to be: 
>https://listserv.ua.edu/cgi-bin/wa?A2=ind1511=ibm-main=344282
>Thanks.
>
>Keep an external index?
>
>z/OS UNIX directory search is fast; I don't know how it compares to Classic 
>catalog
>search.  Shadow your G00*V00 names with empty files in a UNIX directory and
>use that as an index.  Bizarre?  Well, before VSAM programmers used empty PDS
>members as similar placeholders.
>
>Directory search in z/OS may be faster than in competing UNIXen because z/OS
>indexes its directories.  Don't know about the others.
>
>And readdir() will return the smallest (oldest?) G00*V00 first, so you could
>bail out there.
>
>VSAM index?  PDSE with empty members used as index?  Deleting the lowest
>named PDS member is the worst performance case; don't know about PDSE.
>
>How many is "lots"?
>
>What makes "V00" ever Vnn, where N<>0?

Running a program that copies the file doing updating desired to a new
file such that it retains its relative position.  Actual generation
and version numbers are used.

//G00V00RP EXEC PGM=MYREPLAC
//INDD DD DSN=HLQ.MYGDG.G0001V00,DISP=OLD
//OUTDD DD DSN=HLQ.MYGDG.G0001V01,DISP=(NEW,CATLG)

Clark Morris
>
>-- gil
>
>--
>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: Fastest way to read OLDEST GDG entry

[Tom Brennan]

Paul Gilmartin wrote:

Naively, I'd expect that LISTCAT use CSI, or something very similar.


Years ago a Storage Admin mentioned that his "List every dataset" 
nightly job was running more than an hour.  I was playing around with 
CSI at the time (via assembler) and modified some existing code to list 
every alias, and then every dsn under each alias.  I think the result 
ran in less than 5 minutes, so at the time I assumed LISTCAT wasn't 
calling CSI.  Maybe things have changed though.


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

Re: Fastest way to read OLDEST GDG entry

[Steve Horein]

On Tue, Nov 17, 2015 at 3:23 PM, Peter Hunkeler  wrote:

> > What makes "V00" ever Vnn, where N<>0?
>
>
> IIRC, the system does not really care for the version number. When a new
> GDS is allocated using relative numbering, the version is always V00. If
> you want to replace a GDS with a specific generation number while keeping
> the place in the GDG, you cataloge the new data set using the fully
> qualified DSN but replace the V00 with whatever version you like. The new
> data set will become a GDS in place and at the place of the V00 GDS. This
> new GDS will be treated as any other GDS, i.e. aged and eventually rolled
> off.
>
>
> I don't see practical use for this.
>
>
> --
> Peter Hunkeler
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

Vnn came in very handy when transferring data to a new location when a
business unit was spun off to another company. Copies of catalogs were sent
to the other data center. Historic generational data was FTPed to the
remote site to fully qualified "V01" versions, saving shipping and copying
of tapes. The business applications could refer to relative GDG and find
the data cataloged to their own tape volsers. This was several years and
two employers ago, so the specific details have gotten a bit fuzzy. I just
know both parties involved were quite satisfied, and it was a unique
learning experience crafting that solution.

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

Re: Fastest way to read OLDEST GDG entry

[Ted MacNEIL]

Versioning


-
-teD
-
  Original Message  
From: Peter Hunkeler
Sent: Tuesday, November 17, 2015 16:42
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: AW: Re: Fastest way to read OLDEST GDG entry

> What makes "V00" ever Vnn, where N<>0? 


IIRC, the system does not really care for the version number. When a new GDS is 
allocated using relative numbering, the version is always V00. If you want to 
replace a GDS with a specific generation number while keeping the place in the 
GDG, you cataloge the new data set using the fully qualified DSN but replace 
the V00 with whatever version you like. The new data set will become a GDS in 
place and at the place of the V00 GDS. This new GDS will be treated as any 
other GDS, i.e. aged and eventually rolled off.


I don't see practical use for this.


--
Peter Hunkeler 

--
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: Fastest way to read OLDEST GDG entry

[Joel C. Ewing]

After several decades of using MVS I finally ran into a case where I
thought GDS/GDG versioning might be useful and used it  to create a
corrected version of a GDS generation using V01 to make it obvious it
was a corrected version. 

I was lucky and didn't shoot myself in the foot.  Somehow I was thinking
there would be an opportunity to verify things were cool before trashing
the GV00 version, but the instant the GV01 version is cataloged
the corresponding Gv00 version scratches!  The only safe way to use
this feature if the original V00 is needed to generate V01 is to first
generate a new version of the GDS under an intermediate name, verify
correctness, then copy it back with the intended GV01 GDS name,
which means at that point you could instead just as easily copy it back
under the original GV00 name. 

The only possible advantage to using Vnn > V00 to replace a V00 version
is that there is probably no time during which there is not some version
of that generation of the GDG in existence, as opposed to having that
generation disappear for the time it takes to delete the old GV00,
build the new data set, and catalog the new GV00 version.  I concede
there might be some contexts in which that slight difference in behavior
might be important. I just never encountered one in practice.
Joel C. Ewing

On 11/17/2015 08:04 PM, Ted MacNEIL wrote:
> Versioning
>
>
> -
> -teD
> -
>   Original Message  
> From: Peter Hunkeler
> Sent: Tuesday, November 17, 2015 16:42
> To: IBM-MAIN@LISTSERV.UA.EDU
> Reply To: IBM Mainframe Discussion List
> Subject: AW: Re: Fastest way to read OLDEST GDG entry
>
>> What makes "V00" ever Vnn, where N<>0? 
>
> IIRC, the system does not really care for the version number. When a new GDS 
> is allocated using relative numbering, the version is always V00. If you want 
> to replace a GDS with a specific generation number while keeping the place in 
> the GDG, you cataloge the new data set using the fully qualified DSN but 
> replace the V00 with whatever version you like. The new data set will become 
> a GDS in place and at the place of the V00 GDS. This new GDS will be treated 
> as any other GDS, i.e. aged and eventually rolled off.
>
>
> I don't see practical use for this.
>
>
> --
> Peter Hunkeler 
>
>


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Fastest way to read OLDEST GDG entry

[Robert A. Rosenberg]

At 12:23 -0600 on 11/17/2015, Paul Gilmartin wrote about Re: Fastest 
way to read OLDEST GDG entry:



What makes "V00" ever Vnn, where N<>0?


If you have a DSN called DSN.G0055V00 and create a file called 
DSN.G0055V01 it will replace the V00 version in the list.


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

Re: Fastest way to read OLDEST GDG entry

[Robert A. Rosenberg]

At 07:06 -0700 on 11/17/2015, Lizette Koehler wrote about Re: Fastest 
way to read OLDEST GDG entry:


I have heard the GDG limit in z/OS V2.2 will be higher, so it may 
not be much of an issue for limit values.



Lizette



At the current time the limit is 255. Unless you are creating the 
GDGs faster than you process them, you should be reading them fast 
enough to keep the number under 255.


What you need to do is have your program find the oldest generation 
(you can have it look for gdg(-254) and bump to -253/etc until you 
get a FQDSN (DSN.G.V00) or use some other method to get all the 
generation names). So long as the limit is 255 and you have (lets 
say) under 200 versions, a simple manual LISTC will tell you the 
G of the earliest generation. Now submit your job passing the 
 and you are ready to go.


Now use SVC99 to allocate via the FQDSN not the relative GDG. When 
processed delete it, bump the G by 1 and  process that file. 
Eventually if you process faster than the create rate, you will get 
to and process the then current GDG(0) and get a Does Not Exist when 
you have bumped the G to GDG(+1)'s name. You can then exit. The 
only issue is when you get to G. GDG will handle this by creating 
a new G (or it may be G0001) but lising it as newer than G.


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

Re: Fastest way to read OLDEST GDG entry

[Robert A. Rosenberg]

At 22:05 -0600 on 11/17/2015, Joel C. Ewing wrote about Re: Fastest 
way to read OLDEST GDG entry:



After several decades of using MVS I finally ran into a case where I
thought GDS/GDG versioning might be useful and used it  to create a
corrected version of a GDS generation using V01 to make it obvious it
was a corrected version.


It is also useful when you want/need to move the file to another 
device type. I had a case, years ago, when we wanted to move from 
tape reel media to cartridges and the files needed to be kept for a 
significant period of time (past when we wanted to retire the tape 
reel device. By copying the Tape Reel V00 to a Cartridge as V01 we 
had the file remain as a GDG in its proper relative number.


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

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

[Paul Gilmartin]

On 2015-11-17 12:00, J O Skip Robinson wrote:
> Unlike CLIST, REXX is tricky for handling subcommands and prompt responses, 
> which need to be QUEUEd (or PUSHed) onto the stack before the main command is 
> issued. This can be problematic when the response cannot be known in advance 
> of issuing the command. For example, the data set name to use for RECEIVE may 
> depend on the data set XMITted. One solution might be to issue RECEIVE, trap 
> the output that contains the data set name, and END without actually 
> receiving the data set. Then construct a prompt response based the known data 
> set name, QUEUE the appropriate response, and issue RECEIVE again. Might be 
> undoable if more than one data set is waiting for RECEIVE.
> 
Terrible design, indeed.  Perhaps it was motivated by a desire to match
and surpass the worst features of the TSO OUTPUT command.

RECEIVE ought to have options:
o JOBID(JOBn)
o REPLY('string')
o QUERY (your RECEIVE; trap; END)  (like CMS NETDATA QUERY)

And it should be a prefix command in SDSF

How does RECEIVE select which spool entries to process?

But this seems to work for me:


user@OS/390.24.00: rexx "address TSO 'listcat level(...)'" |
sed -n 's/NONVSAM -.\{24\}//p' | sort
G0628V00
G0629V00
G0630V00
G0631V00
G0632V00
G0633V00
G0634V00
G0635V00
G0636V00
G0637V00
G0638V00
G0639V00
G0640V00
G0641V00
G0642V00

"sort" may be superfluous; LISTCAT seems to alphabetize its output.

On Tue, 17 Nov 2015 07:50:44 -0600, Walt Farrell wrote:
>
>CSI is a better approach than reading the output of LISTC, in my opinion, as 
>the LISTC output is not a programming interface.
>
Grrr...  IOW, you believe the output format of LISTCAT is subject to change.

Lizette seems determined to optimize a gnat with a sledgehammer.
-- gil

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

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

>Latest GDG is (-000) .  They were wanting the OLDEST GDG with an
>uncertain number of entries.
>
>> This actually became available with z/OS V2.1
>> And it doesn't help with her request to process the latest GDS *only*




Kind of a typo, isn't it? You're absolutely right. I'm sorry for the confusion 
this may have caused.


--
Peter Hunkeler

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

Re: Fastest way to read OLDEST GDG entry

[J R]

I experimented with this a while back and I believe the results bore out what 
you stated.  

As I remember, the displaced GDS ended up cataloged though not as a GDS.  



From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of 
Peter Hunkeler <p...@gmx.ch>
Sent: Tuesday, November 17, 2015 4:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: Fastest way to read OLDEST GDG entry

> What makes "V00" ever Vnn, where N<>0?


IIRC, the system does not really care for the version number. When a new GDS is 
allocated using relative numbering, the version is always V00. If you want to 
replace a GDS with a specific generation number while keeping the place in the 
GDG, you cataloge the new data set using the fully qualified DSN but replace 
the V00 with whatever version you like. The new data set will become a GDS in 
place and at the place of the V00 GDS. This new GDS will be treated as any 
other GDS, i.e. aged and eventually rolled off.


I don't see practical use for this.


--
Peter Hunkeler

--
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

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

> What makes "V00" ever Vnn, where N<>0?


IIRC, the system does not really care for the version number. When a new GDS is 
allocated using relative numbering, the version is always V00. If you want to 
replace a GDS with a specific generation number while keeping the place in the 
GDG, you cataloge the new data set using the fully qualified DSN but replace 
the V00 with whatever version you like. The new data set will become a GDS in 
place and at the place of the V00 GDS. This new GDS will be treated as any 
other GDS, i.e. aged and eventually rolled off.


I don't see practical use for this.


--
Peter Hunkeler

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

Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

[J O Skip Robinson]

An XMITted file sits in the JES output queue in a designated class (usually B) 
with the recipient's userid as DEST. When that user issues RECEIVE, all pending 
XMIT files are presented one by one. For each file, the user can store it, 
delete it, or issue END. END terminates the RECEIVE command without processing 
the current file. You could issue RECEIVE again and get the same files (I'm 
pretty sure) in the same sequence. So on each pass, you could store the next 
file with attributes gleaned from the previous pass and then END. Repeat until 
no more files are presented. 

Pretty kludgy, but it would probably work. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, November 17, 2015 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Fastest way to read OLDEST GDG entry (also RECEIVE)

On 2015-11-17 12:00, J O Skip Robinson wrote:
> Unlike CLIST, REXX is tricky for handling subcommands and prompt responses, 
> which need to be QUEUEd (or PUSHed) onto the stack before the main command is 
> issued. This can be problematic when the response cannot be known in advance 
> of issuing the command. For example, the data set name to use for RECEIVE may 
> depend on the data set XMITted. One solution might be to issue RECEIVE, trap 
> the output that contains the data set name, and END without actually 
> receiving the data set. Then construct a prompt response based the known data 
> set name, QUEUE the appropriate response, and issue RECEIVE again. Might be 
> undoable if more than one data set is waiting for RECEIVE.
> 
Terrible design, indeed.  Perhaps it was motivated by a desire to match and 
surpass the worst features of the TSO OUTPUT command.

RECEIVE ought to have options:
o JOBID(JOBn)
o REPLY('string')
o QUERY (your RECEIVE; trap; END)  (like CMS NETDATA QUERY)

And it should be a prefix command in SDSF

How does RECEIVE select which spool entries to process?

But this seems to work for me:


user@OS/390.24.00: rexx "address TSO 'listcat level(...)'" |
sed -n 's/NONVSAM -.\{24\}//p' | sort
G0628V00
G0629V00
G0630V00
G0631V00
G0632V00
G0633V00
G0634V00
G0635V00
G0636V00
G0637V00
G0638V00
G0639V00
G0640V00
G0641V00
G0642V00

"sort" may be superfluous; LISTCAT seems to alphabetize its output.

On Tue, 17 Nov 2015 07:50:44 -0600, Walt Farrell wrote:
>
>CSI is a better approach than reading the output of LISTC, in my opinion, as 
>the LISTC output is not a programming interface.
>
Grrr...  IOW, you believe the output format of LISTCAT is subject to change.

Lizette seems determined to optimize a gnat with a sledgehammer.
-- gil


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

AW: Re: Fastest way to read OLDEST GDG entry

[Peter Hunkeler]

>Which mentions SYS1.SAMPLIB(IGGCSIRX).



A while back I had the need to use this interface in an ISPF/REXX application. 
I seem to remember that the sample had some flaws. This was in the z/OS 
V1.11/12 timeframe. Might have been corrected in the meantime.


--
Peter Hunkeler



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