Like everything else in this world, it depends. One of my customers has a multi LPAR z9/BC system and one LPAR is reserved for testing new RSU’s and any other added upgrades and functions.
After all of the above is installed, upgraded or whatever, it means nothing unless you can do come production work on the upgraded system, but all of you already know that. So the regular production is left running and volumes with special databases and other data is brought online to the upgraded LPAR and selected production is run there for 2-7 days so a complete cycle of work can be tested. If problems are encountered those problems are resolved and re testing takes place until all appears to be normal. At that point we shut down the current production LPAR, attached all the other volumes to the newly upgraded system and normal operation proceeds. No renaming of volumes etc…no hassles, seem to work just fine weather or not this is a z/VM system with z/OS running under it or anything else. Seems to be our best practices. It’s also no big deal to keep RACF and any other such data up to date across the test system and production system. Howard, VuQuest Internet Services and Consulting, LLC. --- On Mon, 9/7/09, Timothy Sipples <[email protected]> wrote: > From: Timothy Sipples <[email protected]> > Subject: Re: How often IPL a production LPAR (any good practice) > To: [email protected] > Date: Monday, September 7, 2009, 4:29 AM > Ron Hawkins writes: > >2:00 am for which timezone, and middle eastern > countries do not > >find Sunday outages acceptable. 24x7 really means 24x7. > Give me > >the version without an outage.. > > Right, that version is called Parallel Sysplex. However, > *reducing* the > duration (and risk) of planned service outages is still a > useful > improvement in many situations, even if for some reason you > cannot get > Parallel Sysplex (which can *eliminate* service outages) > implemented right > away. Hence the TogglePlex suggestion. (No, that's not an > official name. > Maybe it ought to be? :-)) > > >And it's not a new idea. The Sysprog I worked with in > Singapore > >was doing this over 10 years ago on two frame Parallel > Sysplex. > >Swing over to one LPAR country by country on Friday > night, IPL. > >the empty LPAR to the new Maint level, and then swing > back country > >by country on Sunday night. > > I was thinking about a TogglePlex sans Parallel Sysplex. > I'm sure it's not > a new idea. But I see many customers that do not yet use a > TogglePlex > approach (or something like it), so I thought it might be > worth mentioning > (and giving an unofficial name; perhaps someone has a > better name).. > > About the only cost-related issue I can think of with a > TogglePlex is > reserving some memory to facilitate the toggle. But that's > not much cost at > all -- and it might even be zero additional cost in the > real world. For > example, the memory could be temporarily borrowed from > another LPAR that > could tolerate being shut down for a relatively brief > interval just before > the toggle, such as a development LPAR. Also, in many cases > the memory > allocated to the uplevel LPAR could initially be less than > what was > allocated to the downlevel LPAR. If the toggle is scheduled > at a relatively > "quiet" time (in memory usage terms), you can start off > with a smaller > memory allocation and verify that the uplevel LPAR operates > correctly. Once > verified, you can shut down the downlevel LPAR (or, better > yet, another > LPAR) and (nowadays) dynamically add memory to the uplevel > LPAR. (All that > is easy enough, but if you happen to have z/VM it's even > easier.) > > It is possible to maintain a group LPAR capacity softcap > lid throughout the > whole toggle operation (and beyond), so there should be no > cost-related > issues there. > > I'm not saying that a TogglePlex offers the same level of > service as > Parallel Sysplex. It clearly doesn't: there's still a > (shorter) service > interruption, and the operator has some more work to do. > But a TogglePlex > is a decent step forward along the higher availability > continuum, in > between a single production LPAR and a Parallel Sysplex. > > - - - - - > Timothy Sipples > IBM Consulting Enterprise Software Architect > Based in Tokyo, Serving IBM Japan / Asia-Pacific > E-Mail: [email protected] > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- 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
