Kees, Sorry hit the key too fast ..old age ... Scott ford www.identityforge.com
On Sep 6, 2012, at 9:59 AM, "Vernooij, CP - SPLXM" <[email protected]> wrote: > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
