I also stay a quarter behind the 'current' RSU. So I do a major maintenance run every quarter but for the prior RSU level plus HIPER, PRP. I also monitor with ASAP, run a weekly automatically submitted job to gather all tthe latest PTFs and HOLDDATA, receive all, etc etc so that if a particularily interesting and applicable HIPER or other PTF shows up, I can APPLY and test without having to order anything. It takes about a month or so for the maintenance to cycle through backing up the current staging environment (including the DLIBs), intial RECEIVE and APPLY staging, clone to sandbox, clone to test systems and finally clone to production. I typically ACCEPT the maintenance a week or so after implementing into production.
However, even after such diligence, if there is a production problem after implementing, why would I want to try to RESTORE one or more troublesome PTFs?? At worst, just IPL the production system(s) from the previous resvol (set) until the problem can be determined and fixed. Surely, another resvol (set) (including OMVS etc) without the mantenance has been preserved?! If worse comes to worse, (this has never been necessary but I always prepare for it), restore your staging (or whatever) SMP/E environment until a fix is found then re-do all the maintenance. This is pretty drastic but CYA is pretty important too. Usually, a fix will turn up either by my action or someone else's after which it can then be put through the maintenance 'cycle'. Everyone may have differing opinions, but they are just opinions. I see no inherent 'danger' in ACCEPTing major maintenance as long as you have a back out plan of some sort. I'd prefer not to rely on the RESTORE function from prior ugly experiences. On Fri, Jul 17, 2009 at 3:19 PM, Mark Zelden <[email protected]>wrote: > On Fri, 17 Jul 2009 13:48:42 -0700, Guy Gardoit <[email protected]> > wrote: > > >I've never seen the logic behind delaying the acceptance of a large round > of > >maintenance, say a quarterly RSU application. Since PTF chains are > usually > >very long, the ability to RESTORE a single PTF becomes a daunting, if not > >impossible task. If there is a problem after a large maintenance run, > >you're better off trying to find a fix for your problem than attempting to > >RESTORE the 'bad' PTF. That's assuming of course that you stay a quarter > >or two back-level in your RSU installations. > > > >Hence, for large maintenance runs, I usually do an ACCEPT run a week or so > >after the APPLY. I see no advantage in delaying it. > > > > > > I'll *strongly* disgree with you there. You need to wait on the order of > months > most likely, not weeks. > > There is always away to back out the maintenance. Sometimes it's a pain > because there is no "GROUPEXTEND" for restore, but using the RESTORE report > you can always figure out what to add in addition to what you are trying to > restore (then you have to re-apply what you can). Or sometimes you only > have to accept a PTF or 2 in the chain and then restore the PE. > > What's "scary" to me is the number of PTFs that go PE after they've gone > though all the CST testing and have been distributed on a quarterly RSU. > Or perhaps worse, a HIPER comes out and then it goes PE several weeks > later. I follow ASAP very closely and see this all the time. > > This is why we stay an entire quarter behind the current quarterly RSU > for our normal maintenance cycle (see past posts of mine on this). But > doing that also means some extra work looking at more current maintenance > (from ASAP alerts) and picking and choosing some PTFs that I think could > be a problem for our environment and getting them on "now". > > Mark > -- > Mark Zelden > Sr. Software and Systems Architect - z/OS Team Lead > Zurich North America / Farmers Insurance Group - ZFUS G-ITO > mailto:[email protected] > z/OS Systems Programming expert at > http://expertanswercenter.techtarget.com/ > Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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 > -- Guy Gardoit z/OS Systems Programming ---------------------------------------------------------------------- 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
