>The danger is that if *anything* goes wrong before your first system comes >up, you cannot log on to fix even the most trivial problem.
One way to be able to fix a sysplex problem that occurs for the first system is the following and requires planning in advance: 1. Use the default of NOCATALOG when defining the CDS. Yes, that is *still* the default. Make sure the CDS is NOT SMS-managed. (This enables you to define a new one from another sysplex or system that is up and running. All you need is access to the DASD volume the CDS will reside on.) 2. Have the &sysplex. or any other qualifier that uniquely identifies *this* sysplex in the CDS name. If you don't (or have the CDS names identical on all sysplexes), the ENQ from XCFAS (that is just there to prevent you from shooting yourself in the foot when deleting CDSs) will interfere with the definition of a CDS on a different volume but with the same name. Despite NOCATALOG being the default, apparently it was never tested to define a CDS on a new volume with that ENQ present, so there is no way around it, not even via the STGADMIN RACF definition. XCF just cannot distinguish between the same name on a different volser because the ENQ cannot. Ask me how I know. Once the name is different, XCF has no problem defining the dataset, which in my opinion is adding more complexity than necessary. 3. Make sure that you specify the volser each CDS resides on in couplexx. Also, since you use NOCATLOG, the volser must get specified on every setxcf command. 4. Make sure that SYS1.SYSPLEX.CNTL (or whatever your name is as long as it is not sms-managed) is on a DASD accessible to the system that the DASD for the CDSs is accessible to. We put ours on the volume containing the primary sysplex CDS. I believe that's it. I have implemented this here, and it came in handy when we had to combine two previously independent sysplexes into one and all the two subplexes ever shared were the CDSs. It was also very handy when we had the latest round of problems with a GRS wait state because of an XCF definition, and the GRS wait state didn't even tell us the reason. >BTW 'SYS1.SYSPLEX.CNTL' was our choice of a PDS to hold all couple data >set and policy definitions. I highly >recommend creating a single repository for all sysplex definition job >streams even in a small shop. I completely agree with this advise, *especially* for the LOGR CDS, since updating that policy is done on a logstream-by-logstream basis with i.e. CICS defining new log streams as they please (if you let them). If you ever loose the LOGR CDS, you will need a repository of everything that was defined to speed up restart. And more advise: Keep the joblogs of all your latest definition jobs in sys1.sysplex.joblog, also residing on the same volume as sys1.sysplex.cntl. That helps tremendously when you actually have to check why the upcoming first system of a sysplex insists on wait stating because it cannot find ISGLOCK. We had it happen that we *thought* (checked by six eyes) we had done the right definition, but we had not. In addition, once you change the definitions from another sysplex, the joblogs won't be accessible from the sysplex they were done for. It requires discipline, though, to always save the joblogs. I hope the above didn't completely confuse everybody! 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
