<snip> We have 3 LPARs configured as monoplex. One for our Production environment, one for our Test/QA environment, and one for our Application Development environment.
>From this discussion, it sounds like everybody is saying even we would benefit from Sysplex. </snip> The purpose of a sysplex is z/OS availability. I commonly go 3 months between outages (production IPL's) and I am in the middle of creating 2 base sysplex's. 1 for test/dev/QA, and 1 for production. After this project is complete, I expect to be able to go to 1 production outage annually (mainly to harden any dynamic changes to the IODF and/or processor microcode) and perhaps longer. A parallel sysplex would be wasted money unless you have 2 or more CECs. The technical difference between a base and a parallel sysplex is the Coupling Facility (whether it be internal or stand-alone) and a sysplex time reference (external) and all of the functions that depend on a CF (GDPS, VTAM generic resources, hot failover, multi-node persistent sessions, log streams, JES Checkpoint, ...). The design difference is in the degree of availability. In a properly designed parallel sysplex, one could expect 99.9999% availability of *ALL* applications and z/OS itself (about 31 sec of down time annually). The best I expect with a base sysplex is somewhere between 99.99% and 99.999% (5 min and 52 min respectively). Many of the things I would *like* to do are only available in a parallel sysplex, so I have to do without those functions. I can do everything I *have* to do in a base sysplex. With deference to Barbara, RACF is not a problem. It runs just fine without the CF, but can exploit one if available. One last note, without a CF, many sysplex functions do not scale well to more than a few images. GRS is a notorious example, as would the JES checkpoint. With only 2 systems in each plex (PROD & DEV/TEST/QA) you should not have any significant issues. The Merging Systems into a Sysplex Redbook (SG24-6818) is a great reference, but does omit some functions that have become available since it was published in 2002. HTH, ---------------------------------------------------------------------- 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
