Allan, The OP was asking about using Sysplex to join his three monoplexes into a single Sysplex. Availability may have been the original purpose of Sysplex, but it can and has been used for other purposes since it's inception. You have obviously not been following the recent discussion that spawned this thread ;-) Scott
>>> "Staller, Allan" <[email protected]> 8/12/2009 8:54 AM >>> <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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- 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
