Kees, I agree 1 big bang can be problematic. For example putting a lot of maintenance on a system, you have a problem it an be a challenge to determine root cause. I personally prefer a phased approach, but that's me.
Scott ford www.identityforge.com On Sep 6, 2012, at 3:02 AM, "Vernooij, CP - SPLXM" <[email protected]> wrote: > There is absolutely no need to implement changes in 1 big bang IPL on > all your systems. We do it phased as long as I work here (which is very > long). When we had 2 production LPARs we usually did it with 1 week in > between, but during z/OS upgrades, both levels ran together perfectly > for weeks. IBM defines well what levels are supported to run > concurrently in a Sysplex. Other vendor should do so too. > > Now that our number of LPARs is growing, due to VWLC, our phased > approach would indeed take weeks, so we decided to upgrade them in 2 > groups. In one weekend, we IPL the group of LPARs that mostly run > Dev/Acc subsystems, the next weekend the group with the main Prod > subsystems. And during the coming z/OS upgrade, the difference will > exist again for a couple of weeks. > > Kees. > > > "Dennis Schaffer" <[email protected]> wrote in message > news:<[email protected]>... >> Its been four years since my esteemed colleague, Robert, asked this > question about "phased maintenance". He wanted to understand the > experiences of those of you who implement maintenance and new releases > within the same sysplex by performing rolling LPAR IPLs across multiple > days or weeks. >> >> Since then, very little has changed in our maintenance processes, > except we've gotten bigger. Our largest sysplex is approaching a dozen > LPARs and its becoming increasingly difficult to implement major > maintenance changes in a single evening outage window. We've tip-toe'd > into phased maintenance by implementing changes on one or two small > special-purpose low-usage systems a few days in advance of making the > same changes to the major production systems, which run a variety of > transaction and database systems. >> >> But, some at our company are still very nervous about implementing > this phased maintenance approach on our major production systems, > especially when increasingly-restrictive scheduling means this mixed > maintenance environment may need to exist for two or three weeks at a > time. >> >> I understand that IBM provides a multi-release co-existence support > policy for z/OS and other ServerPac products, which very adequately > covers much of our IBM inventory, and that IBM will fix any problems > discovered. But, have you actually encountered any problems caused by > co-execution of multiple maintenance levels or releases of IBM software? > BTW, IBM transaction and database software is out of the scope of this > question for us, because they are maintained separately. >> >> In addition, I want to mention that we implement most of our ISV > software inventory using the same maintenance philosophy and that's also > a concern that may not have been addressed in Robert's original > question. >> >> I'd appreciate any feedback you can provide on your current phased > maintenance implementation experiences, especially when the > mixed-maintenance environment coexists for a week or longer on major > production systems. >> >> Thanks in advance for your feedback. >> >> Dennis Schaffer >> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > ******************************************************** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain confidential > and privileged material intended for the addressee only. If you are not the > addressee, you are notified that no part of the e-mail or any attachment may > be disclosed, copied or distributed, and that any other action related to > this e-mail or attachment is strictly prohibited, and may be unlawful. If you > have received this e-mail by error, please notify the sender immediately by > return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission of > this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > ******************************************************** > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
