There is a non-zero risk with an IPL (reboot), at least outside Parallel Sysplex. Basically, "will the system come back up?" I'm not a big fan of scheduled IPLs. They're usually operational remnants of long ago (maybe decades old) repaired memory leaks, back when U.S. gasoline stations closed at 6 or 7 p.m. and all day Sunday. :-) User expectations in 2008 are much different than they were in 1968.
This is one big reason why it's a good idea to bump up to the next quality tier of service delivery if you can. That is: 1. If you currently operate only a single production LPAR, and your users suffer service interruptions that last at least as long as the LPAR IPL, then implement a "poor man's Parallel Sysplex." That is, establish a second production LPAR "in reserve" and shift users over to that LPAR (using automation as much as possible) just before the interruption if you can. Now, it may not be completely transparent or elegant to the users, but it's excellent practice to prevent a more serious calamity (see top of message), and it's certainly a nice, positive step forward. I've run into many customers running single production LPARs -- including a decent sized bank for their core online banking, believe it or not -- and the "pmPS" is a major step forward and near enough "free" so that they can implement it without any real financial burden. 2. If you have "pmPS" and want more, but you can only have one physical machine for whatever reason, then you can implement a single machine internal Parallel Sysplex with an ICF (Internal Coupling Facility). Such a setup offers very good service and can allow you to eliminate outages for things like DB2 version upgrades (with DB2 data sharing) and z/OS release upgrades, although obviously there will be a service interruption if somebody cuts power to your one machine or you otherwise lose the machine in some way. (The length of the service interruption and amount of data loss will depend on how good your disaster recovery is.) Such a configuration also means you can "graduate" very easily to a 2-machine Parallel Sysplex if you want, when you want. For example, when you take delivery of a new machine, you can stand it alongside the existing single machine Parallel Sysplex, add it into the Sysplex, and (if you follow the rules) your users should experience no service interruption. If you're already set up with Parallel Sysplex then the frame upgrade is "no big deal." Then you have two machines, and you can perform an in-place upgrade of the first machine to the new model when it makes sense, usually rather soon. 3. If you have the two machine Parallel Sysplex, but you aren't using it to avoid certain (any?) service interruptions (e.g. a "Shamplex"), then try to remediate that, starting with the "most important" users. For example, if upgrading DB2 versions takes certain databases offline that really shouldn't be, try to move those particular databases into data sharing. 4. Extend the above into Geographically Dispersed Parallel Sysplex (GDPS) if you can, so that loss of an entire site reduces or eliminates service interruptions and data loss. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM 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
