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 < [email protected]> 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... grrrrr.... > > 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 [email protected] with the message: INFO IBM-MAIN > -- Thank you and best regards, *Billy Ashton* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
