Tim, Uglyplex is not going to happen without Data Sharing, and Data Sharing doesn't happen without Parallel Sysplex.
You're trying to tell me you can Stop Batch, bring down a hundred or more CICS regions, as well as Webshere, IMS, DB2, CA-IDMS, and then restart all of this again on an another LPAR to the point of full application availability with just a two minute outage. That's a giggle... Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of > Timothy Sipples > Sent: Monday, September 07, 2009 1:29 AM > To: [email protected] > Subject: Re: [IBM-MAIN] How often IPL a production LPAR (any good practice) > > 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
