On Wed, 12 Aug 2009 01:02:32 -0500, Barbara Nitz <[email protected]> wrote:
>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. And HFS - this was a big pain for us, particularly since we are multi-site. 1.10 and 1.11 will make this easier, but for now we are relegated to sysplex-wide IPLs for D/R events. And not just sysplex root - AUTOMOVE/NOAUTOMOVE/UNMOUNT require attention, and settings will depend on your level of DASD sharing. We have seen some nastygrams with DAE, but looking into DAE on each system, we've seen nothing to indicate the suppression functions are not working properly. Can you elaborate on this at all (offline, if you'd prefer)? Maybe we need to re-address our configuration sooner rather than later. >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. We do not share SMS-managed DASD in our XCFPlex, but we do within two of our subplexes (based on prior JES3plex configurations). We currently share only CDS volumes, plus a common PARMLIB (for COUPLExx, GRSRNLxx, and a couple of others). We had problems with OPERLOG, using a structure, so now we only enable it on one subplex that shares DASD. We have the odd problem with EJES users on other systems trying to connect to the logstream from images outside the duplex. Perhaps we should try moving to DASD-only to resolve it. We have had no issues with RRS or CICS logstreams - they are DASD-only and system-specific. I suspect if we had SMF or LOGREC enabled, we might run into the same problems as with OPERLOG. >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. RACF is a sticky wicket. In addition to profile and protection differences, sysplex communication requires either a shared database, or unique dataset names. Because we chose not to rename our existing subplex DSNames (too many ICHRDSNT's to manage), and not to merge our databases (not trivial), we suffered the loss of command propagation. Our admins did get over it, in time... >[..] 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. We are configured to use same TSO IDs on multiple systems - separate RACF databases, uniquely names ISPF profiles, individual TSO/E mail (LOGNAME) datasets (not uniquely named, but we don't share catalogs, and we have an RNL entry to demote the ENQ). We don't have the notification problem. We cannot logon concurrently within our JES3 subplexes, but this has always been the case. Our JES2 systems are single-member MAS. >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. It took us 8 months to merge two sysplexes (two systems each) and three monoplexes into one sysplex. This spring we added another monoplex, and in October we add another, bringing our count to 9. Sharing is limited to what is absolutely necessary to make this rickety-pricing-plex work, but we will start down a path to "Goldplex" (if we ever get through these consolidations). Regards, Art Gutowski Ford Motor Company ---------------------------------------------------------------------- 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
