On Sat, Jul 18, 2009 at 9:50 AM, Mark Zelden <[email protected]>wrote:
> On Fri, 17 Jul 2009 16:06:29 -0700, Guy Gardoit <[email protected]> > wrote: > > <snip> > > > > >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?! > > > I agree that IPLing from an old sysres set is an option if needed but > several > points: > > 1) If we aren't having the problem described by the PE, I can just RESTORE > it and the next clone / rolling set of IPLs will not have the PE. We can > do > IPLs once or twice a month (not every LPAR... rolling IPLs). Eh, if you're not having the problem described by the "PE", why bother? I'm positive that most shops are running with PTFs that have gone "PE", it doesn't mean your shop is suddenly going to have problems; it depends on the condition that caused the PTF to go "PE". When a PTF goes "PE" there is no need to RESTORE it unless it is causing a problem in your shop AND there is no 'fixing' APAR or PTF. I also am limited to once-a-month production IPLs restriction. However, if a problem crops up that must be addressed, an emergency schedule of "rolling" IPLs may possibly be approved. > > > 2) Quite often there is a fix included that may be critical that you don't > want to back off along with the bad one by IPLing from an old sysres set. > That maintenance could even a required level of support for hardware that > can't be backed off. For example, you applied z10 required maintenance > along > with the other RSU or HIPER maintenance, upgraded your processors, now > one of those other PTFs went PE. You can't just IPL from an old sysres > set. True but this example is a bit of a stretch and a 'special' circumstance and not one you would run into during a typical maintenance cycle. > > > > > 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. > > You're right, it's pretty drastic and not necessary if you follow what most > people consider a best practice - that is, not to perform ACCEPT until > the next apply cycle or at least until the maintenance has been running > in production for a reasonable amount of time (and no, I don't consider > a week or 2 a reasonable amount of time). > True, "reasonable" is a matter of opinion and a function of your shop dynamics. > > > > >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. > > > > You don't have to rely on RESTORE even if you delay accept. Taking the > opposite point of view, there is no harm at all by delaying ACCEPT. It > gives you more options and an easier backout of a bad PTF. > > There are opinions and more than one way to do things. But there are also > generally accepted (no pun intended) best practices on how to maintain > software with SMP/E. Yes, there are - I'll continue to use my method. Thank you. > > > 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
