Tim, I think you need to get into the real world here. First up, Uglyplex is simply a MAS, or a base Sysplex. It's not a toggleplex, Uglyplex, Switchplex, Exchangeplex, or other nameplex you want to dream up. It's a Base Sysplex and that's it. People have been moving workload from one system to another as you describe for decades. The Bank I worked for over 16 years ago was doing this every two weeks to reduce IPL downtime for CONNEX when PLEX was not even an MVS suffix.
Secondly, I think you have to come to terms with how most shops run application a, b, c... z. Sure there may be a CICS Region and a Batch job here and there dedicated to each application, Country, State or timezone, but I'll bet my arse that in 99% of shops there's just one DB2, IMS, or whatever flavor of DBMS that is common across all those little a's and b's. I want you to tell me how am I going to move CICS and Batch for application x, y and z without moving the DB2 they share with application a, b, and c? I'm not arguing with your suggestion. It's a good one, as evidenced by the fact that sites have already being doing it for over 20 years. I am taking issue with the way you trivialize the down time that goes with it, and that you try to create an impression of "whizz-bang new idea" by calling a Base Sysplex a PFCSK name like Toggleplex. Call it a Base Sysplex, talk about moving workloads between LPAR members, be realistic about downtime, and stop using expressions like "rolling toggle." For me it sounds like a cheap used car commercial rather than a description of an existing good practice. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of > Timothy Sipples > Sent: Monday, September 07, 2009 11:12 PM > To: [email protected] > Subject: Re: [IBM-MAIN] How often IPL a production LPAR (any good practice) > > Again, a TogglePlex can (unambiguously, I think) *reduce* service > interruptions. The 2 minute figure was merely an example, just like the > Sunday and 2:00 a.m. examples that appeared right next to it. Obviously how > much reduction is achievable is highly application architecture dependent. > > Also, from an operations point of view you should always protect the most > critical (least interruptable) applications and users first, as determined > through recent business-side consensus. Can you toggle X, Y, and Z (where X > +Y+Z is some big number of "things") within 2 minutes (or even 5 or 10 > minutes)? Maybe not. But maybe you don't have to. Maybe you can toggle a > subset first (and more quickly), then move on to the remainder. (This is > also basic disaster recovery strategy: get the "heart, lungs, and brain" > back in operation first, then move on to things like the stomach and > pituitary. So it's probably good practice anyway.) You might call this a > "phased toggle" (or "rolling toggles"?) I suppose, with the interruption > for each *particular* user (or user class) shortened even while there might > be a series of interruptions across the entire user population. Again, this > is all highly application architecture dependent. > > You're arguing that Parallel Sysplex is better. I totally agree (and say so > again). Heck, beyond that, GDPS is even more better. But if (for whatever > reason -- perhaps even a bad reason) the choice is only between a single > production LPAR and a TogglePlex, a TogglePlex is a positive step forward. > > - - - - - > 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
