As can be seen from the replies, there are different approaches for handling the PTS. In my shop, when a z/OS release is installed, the PTS is placed on a volume where it will have plenty of room. For the life of the install, PTFs are not purged from the PTS - ever. If necessary, spill PTS datasets are defined. We are not a large shop, and this works for us.
For ACCEPT, we generally run the ACCEPT of previous service just before beginning the next maintenance cycle. Regards, Linda ----- Original Message ----- From: "Mark Zelden" <[email protected]> To: [email protected] Sent: Friday, April 29, 2011 7:45:39 AM Subject: Re: SMPPTS run out of Space (another approach) On Fri, 29 Apr 2011 15:25:36 +0200, R.S. <[email protected]> wrote: >W dniu 2011-04-29 15:18, Mark Zelden pisze: >> On Fri, 29 Apr 2011 12:30:59 +0530, saurabh khandelwal >> <[email protected]> wrote: >> >>> Hello, >>> Thanks for reply. I will check in my site about old PTF, >>> which can be removed from PTS library and detail about accepted PTFs. >>> >>> >>> Regards >>> Saurabh >>> >> >>>> Caution: SMP/E option PURGE(YES) is needed for the above. PURGE(NO) >>>> means the PTF is not deleted after ACCEPT. >>>> >>>> In simpler words: if you accept old PTFs then you don't need more PTS >>>> space for new PTFs. >>>> >> >> >> What R.S. didn't tell you was what to do if PURGE(NO) is specified. I have >> to run that way at one of my clients because while I maintain a single >> global zone / SMPPTS, I have multiple target zones for different >> companies within that shop (multiple per company to match >> the sysres set) and a single DLIB zone for each company. I can't clean >> up the SMPPTS until ACCEPT is done in all the DLIB zones (otherwise >> the 2nd and subsequent ACCEPTs get very angry when the sysmod is >> gone from the global zone / SMPPTS!) . >> >> What you have to do is run REJECT in PURGE mode. Simple enough: >> >> SET BOUNDARY (GLOBAL). >> REJECT PURGE (DLIB1,DLIB2,DLIB3,...). >> >> After I do that, I run CLEANUP against the maintenance target zones >> and compress the SMPPTS(es). > >Mark, >I also have multiple DLIB and TARGET zones. My way to clean up PTS is to >switch PURGE OFF, then perform ACCPET on every DLIB *except* last one, >switch PURGE ON (YES) and then perform ACCEPT on the last one. It's >error-prone ;-) Even if not error prone, seems like more work to me than it's worth. Also, for me, the different companies / business units don't always have the same schedules to roll out maintenance. So company A could be at RSU1009 and company B at RSU1012 and since I won't except anything that isn't at least 6 months old, the DLIB zones could be at different accept levels also. > >I have a question to the command above: REJECT PURGE(DLIB1,DLIB2,...) >Is AND or OR between the zones? In other words: PTF accepted on every >DLIB will be purged, what about PTF accepted on single DLIB? > I should tell you to RTFM, but I like you. :-) It means to "consider all the specified zones when doing the REJECT" - so it is an "AND" condition. If only one zone was specified, it would only look at that one zone and could delete a PTF from the global zone that was not yet accepted into the other DLIB zone(s) being maintained. Cheers, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ *** Please note the new URL for Mark's MVS Utilities *** ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
