Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
On Sat, Jul 18, 2009 at 9:50 AM, Mark Zelden mark.zel...@zurichna.comwrote: On Fri, 17 Jul 2009 16:06:29 -0700, Guy Gardoit ggard...@gmail.com 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:mark.zel...@zurichna.com 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
On Fri, 17 Jul 2009 16:06:29 -0700, Guy Gardoit ggard...@gmail.com 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). 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. 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). 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. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
What is the current philosophy on running SMP/E ACCEPT on z/OS?
In today's environment and IBM's ever changing methods of delivering/offering maintenance and upgrades to z/OS - what are your common best practices? Before every APPLY? Never? Ken Klein Sr. Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Klein, Kenneth In today's environment and IBM's ever changing methods of delivering/offering maintenance and upgrades to z/OS - what are your common best practices? Before every APPLY? Never? Our general ROT is to ACCEPT PTFs that have been running in the production environment for 3 months or longer before APPLYing the next round of preventive maintenance. APARs and USERMODs are *NEVER* ACCEPTed. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
snip Subject: What is the current philosophy on running SMP/E ACCEPT on z/OS? In today's environment and IBM's ever changing methods of delivering/offering maintenance and upgrades to z/OS - what are your common best practices? /snip Generally speaking, I perform general maintenance quarterly and roll from sandbox through dev/test environments before going to production. Separate sets of SYSRES's are maintained for the various environments and cloned at the appropriate times. This takes about 6 months from apply to accept. I also apply this philosophy to 3rd-party and middleware products. I concur with the other poster that never accepts usermods or APAR fixes. From the prior base level 1) Receive current set of maintenance/holddata. This ensures an late breaking problems are blocked from being applied/accepted. 2) LIST SYMODS APPLY(TZONE) NOACCEPT(DZONE). List of applied but unaccepted PTF's. 3) Edit this list to just the SYSMODID's. 4) ACCEPT CHECK S(list) GROUPEXTEND. Resolve outstanding system holds,.error holds,... 5) ACCEPT. 6) Proceed with normal apply processing for next round of maint. This ensures that only ptfs that have been blooded in your environment are accepted. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
There's a job run here to download IBM holddata on a weekly basis. By the time someone tries to do an ACCEPT there are so many APPLIED ptf's with pe's it's almost not worth the effort. Alan Schwartz ASC Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Staller, Allan Sent: Friday, July 17, 2009 8:12 AM To: IBM-MAIN@bama.ua.edu Subject: Re: What is the current philosophy on running SMP/E ACCEPT on z/OS? snip Subject: What is the current philosophy on running SMP/E ACCEPT on z/OS? In today's environment and IBM's ever changing methods of delivering/offering maintenance and upgrades to z/OS - what are your common best practices? /snip Generally speaking, I perform general maintenance quarterly and roll from sandbox through dev/test environments before going to production. Separate sets of SYSRES's are maintained for the various environments and cloned at the appropriate times. This takes about 6 months from apply to accept. I also apply this philosophy to 3rd-party and middleware products. I concur with the other poster that never accepts usermods or APAR fixes. From the prior base level 1) Receive current set of maintenance/holddata. This ensures an late breaking problems are blocked from being applied/accepted. 2) LIST SYMODS APPLY(TZONE) NOACCEPT(DZONE). List of applied but unaccepted PTF's. 3) Edit this list to just the SYSMODID's. 4) ACCEPT CHECK S(list) GROUPEXTEND. Resolve outstanding system holds,.error holds,... 5) ACCEPT. 6) Proceed with normal apply processing for next round of maint. This ensures that only ptfs that have been blooded in your environment are accepted. HTH, -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
On Fri, 17 Jul 2009 08:25:09 -0400, Klein, Kenneth kenneth.kl...@kyfb.com wrote: In today's environment and IBM's ever changing methods of delivering/offering maintenance and upgrades to z/OS - what are your common best practices? Before every APPLY? Never? Search the archives. Look for the best practices session from SHARE given by Greg Daynes. Bottom line: You should be accepting maintenance (for any software) on a regular basis that goes along with your apply cycles in order to have a restore point. For z/OS, my best practice is to ACCEPT six months behind the apply level. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Klein, Kenneth In today's environment and IBM's ever changing methods of delivering/offering maintenance and upgrades to z/OS - what are your common best practices? Before every APPLY? Never? Our general ROT is to ACCEPT PTFs that have been running in the production environment for 3 months or longer before APPLYing the next round of preventive maintenance. APARs and USERMODs are *NEVER* ACCEPTed. -jc- unsnip Pretty much the same attitude here. One variation: we don't apply APARs unless the need is severe and immediate; we'd rather wait for the PTF. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
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. On Fri, Jul 17, 2009 at 1:31 PM, Rick Fochtman rfocht...@ync.net wrote: Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Klein, Kenneth In today's environment and IBM's ever changing methods of delivering/offering maintenance and upgrades to z/OS - what are your common best practices? Before every APPLY? Never? Our general ROT is to ACCEPT PTFs that have been running in the production environment for 3 months or longer before APPLYing the next round of preventive maintenance. APARs and USERMODs are *NEVER* ACCEPTed. -jc- unsnip Pretty much the same attitude here. One variation: we don't apply APARs unless the need is severe and immediate; we'd rather wait for the PTF. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
On Fri, 17 Jul 2009 13:48:42 -0700, Guy Gardoit ggard...@gmail.com 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:mark.zel...@zurichna.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
I guess there is no generally accepted philosophy. On Fri, 2009-07-17 at 17:19 -0500, Mark Zelden wrote: 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 can remember sitting in on a JES2 presentation at Share by one of the developers. He asserted that the fixes from his team were so important (and clean) they should be applied directly to all environments when shipped. I almost fell off my chair - and I wasn't the only one. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
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 mark.zel...@zurichna.comwrote: On Fri, 17 Jul 2009 13:48:42 -0700, Guy Gardoit ggard...@gmail.com 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:mark.zel...@zurichna.com 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is the current philosophy on running SMP/E ACCEPT on z/OS?
On Fri, 17 Jul 2009 16:06:29 -0700, Guy Gardoit ggard...@gmail.com wrote: ... 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. IPLing off the old resvols is the obvious quick solution, but you are backing out all maintenance when you do that. That may not be an acceptable (so to speak) long term solution (and clearing up some PE messes has definitely fallen into the long term category). ... 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. ... I see fighting with even the ugliest RESTORE situations preferable to waiting many months for a PE'ed PTF to get a fix. Well, maybe not ugliest. The ugliest RESTORE situation I've seen involved an incorrectly packaged PTF that made doing a RESTORE was impossible (if you wanted a usable load module). But that just meant I reverted to your technique - wait for a fix. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
