I can think of nothing that can be done in a single image that cannot be done in a basic (or parallel) sysplex. Some things are more complicated, some things are easier. IIRC, 3-5% utilization is the ROT for parallel sysplex overhead (maybe for basic, but I am not sure).
Parallel sysplex = stand-alone CF = $$$$$ (is most likely not going to happen for you (based on previous posts) Basic sysplex #1 = CF engine = $$$$ (is most likely not going to happen for you) Basic sysplex #2 = CTC communication With 2 LPARS, not too difficult, - exponential increase in complexity as lpars are added (2**N) Inter-lpar communications/control are the big issue here. GRS/MIM, VTAM/APPN/EE, share *EVERYTHING*, naming conventions. If you are WLM Goal mode, you are (at least) a monoplex. <snip> I know that is vague. What has happened is that somebody with political clout is strongly pushing the idea that having two separate z/OS images on a single CEC (separate LPARs of course) would be "better" than having a single z/OS system. They have not defined "better". We have not decided on how to implement this. I know of three possibilities, in my order of desirability: (1) Parallel Sysplex; (2) basic sysplex; (3) separate monoplexes. Is there anything that documents, in a single place, what CANNOT be done in the various environments? As an example, a JES2 MAS requires at least a basic sysplex. If we go to separate monoplexes, then the JES2s could only communicate via NJE. Is there ANYTHING that I can do in a single image that I cannot do in a parallel sysplex (other than share memory, VTAM LU names, and IP addresses)? </snip> ---------------------------------------------------------------------- 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
