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 [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tom Marchant Sent: Thursday, November 19, 2015 4:54 AM To: [email protected] 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 [email protected] with the message: INFO IBM-MAIN
