>If we did do Sysplex, would we still be able to maintain that separation >between the environments? How? Does anybody have a "cookbook" on how >to go from where we are to where we should be? And how does the change >affect the way we do things? i.e. what do we need to warn our customers >about? It depends. There are components that you cannot separate/configure for a subset. One of them is DAE, for instance. (Has caused us *a lot* of grief.) Another is console. A third is GRS. And WLM. And RMF. And PDSE.
On each of your existing monoplexes, do a d xcf,grp. That will tell you who communicates using XCF services. (Yes, even in a monoplex.) One of our monoplexes has these groups: ARCPLEX0(1) ATRRRS(1) JES2nodename(1) EZBTCPCS(3) INGPX$$$(2) INGXSG(3) ISTCFS01(1) SYSATB01(2) SYSDAE(2) SYSIEFTS(1) SYSIGW00(2) SYSIGW01(1) SYSIKJBC(1) SYSIOS01(1) SYSJES(1) SYSJ2$XD(1) SYSMCS(1) SYSRMF(1) SYSTTRC(1) SYSWLM(1) SYSXCF(1) Check which have the same name on all your monoplexes. Then check if the component allows specification of the group name (or if this is hardcoded somewhere - then you're out of luck). You will need to specify different names if you can. For those you cannot, you need to determine if you can live with them communicating. If you share DASD (and have them in the same SMS configuration) between your lpars, DAE and HSM and RRS/LOGR will not be a problem. HSM can be configured to be separate. System Automation (the ING groups) tells you they can be configured, but you will not be able to separate the INGPX$$$ group. (And don't ask IBM how to do it, they're useless in answering that. Ask me how I know.) The following applies to parallel sysplex. Not sure how that would work on DASD-only log streams that you would have to use if you don't have a CF. If you use RRS/IXGLOGR, despite what IBM tells you, you MUST HAVE shared DASD in the same SMS environment. Otherwise you're in for unexpected RRS cold starts on different lpars, as LOGR offload does not necessarily occur on the system you expect it to. Every connector to the log stream can do offload, and despite using different log stream names (in a parallel sysplex mapped to different structures), a system that is not supposed to connect to that log stream can fairly easily connect to it. Given that DASD-only logstreams can only get connected to from one system (I think), that might not be a problem. But then, you might run into problems I cannot imagine as we don't have that setup. And the list above is only mentioning *a few* sysplex communicators. RACF may be another problem area. IBM warns against NOT sharing RACF in a sysplex, but this may apply to special functions. One thing you may run into (using different RACF databases with the same TSO userids on all those monoplexes and OPERCMDS active) is system commands being allowed where they should not. >Also, most of the stuff out there talks about parallel sysplex. What >are the differences for a Basic Sysplex? Which parts do I do differently? Basic difference: Parallel sysplex needs a coupling facility. Basic sysplex does not. In a basic sysplex the systems communicate via CTC, and every system must be connected to every other system. You also need the common time source, which is not a problem as long as you stay on the same box. So you can forget the things that have to do with structures (no GRS star, you will have to use GRS ring; no shared logger structures - this affects RRS and possibly CICS). The exercise I pointed out above is still the same - there are enough components that communicate via XCF signalling without needing a structure that you will have to separate or live with them not being separated. You will need to define GRS RNLs. You will need to combine your separate WLM policies. If you use the same userid on all systems, your users are going to complain as there can be only one userid with the same name in the sysplex, Mark Zeldens instructions in how-to-overcome that not withstanding. Our TSO users did not like it because notifications inevitably ended up on the wrong system where that userid was also logged on, but not currently working. >And what about the non-IBM components? We run ADABAS/Natural from >Software Ag. No clue about that. If they have an XCF group with the same name on all your monoplexes, you will need to check with each product if they can be separated. The above should be enough food for thought to get you started. Otherwise you'll need to ask more pointed questions. It took us two months to combine two completely separate parallel sysplexes into a common parallel sysplex. To satisfy IBM licencing costs, absolutely no technical reason. Both subplexes had a fully developed SMS environment to begin with, and both systems had RNLs already defined. All these subplexes share are the couple data sets. Which is why I strongly vetoed RRS on one of those subplexes. And why we ran into problems with DAE. Regards, Barbara Nitz ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
