Yes, Scott? Kees.
"Scott Ford" <[email protected]> wrote in message news:<[email protected]>... > Kees > > 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 > ******************************************************** 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
