*Exactly! *This is the correct way of doing RSU**** maintenance upgrades. It also solves some of the objections to the way RESTORE works as well. There are those who say they never ACCEPT maintenance which will cause a lot of problems which is then attributed to poor SMP/E design. SMP/E is the best thing since bacon-and-eggs if used properly.
For the SMPPTS, I generally predefine 4-5 of them which works well for me but each shop is unique. Thanks. On Fri, Apr 29, 2011 at 9:47 PM, Linda Mooney <[email protected]>wrote: > 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 > ---------------------------------------------------------------------- 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
