Classification: UNCLASSIFIED Caveats: NONE Thanks again John for taking quite a bit of your time to answer so thoroughly.
One of my clients wishes to adhere, as much as possible, to their naming and system-design standards: 1) SYS1 is SMP/E target 2) SYS2 contains read-only configuration items (allocated by the enterprise) 3) SYS3 contains write-mostly operational data (allocated by the enterprise) 4) SYS2 and SYS3 are ALIASes to a UCAT. I was intrigued and started looking into the feasibility of these requirements. My research revealed that they can probably be accommodated with very few exceptions. Hence my post. I was interested in the experience of others; thanks Elardus for your confirmation regarding SMS. As far as I was able to ascertain, none of the datasets in category 2 and 3 (above) are required to have names that begin with HLQ=SYS1. Only IPLPARM must have a HLQ of the form SYSn; HLQ=SYS2 is permissible. Requirement 4 (above), that SYS2 and SYS3 not be in the MCAT, complicates things. Page datasets may have any HLQ but they MUST be catalogued in the MCAT. I haven't found any system-initialization dataset type other than "page" which MUST be MCAT-catalogued. * SYS2.IPLPARM will be found by NIP iff it's on the IODF volume (catalog search is not utilized) * SYS2.IODFnn will be found by NIP iff it's on the IODF volume (catalog search is not utilized) * The LOADnn member of SYS2.IPLPARM facilitates specification of a volser for all PARMLIBs * SYS2.PARMLIB et al will be found by NIP via the PARMLIB statements in LOADnn (catalog search is not utilized) ! The above datasets would be catalogued in the SYS2.** UCAT to accommodate references after master scheduler initialization. Other datasets accessed during system-initialization may be prefixed by HLQ=SYS2 and HLQ=SYS3 as long as CAS is active. The above text represents *my beliefs* at this time, based upon the manuals, CPP MCAT=Y and forum feedback. I intend to build a test z/OS image to test my beliefs. If system-initialization functions as per my current beliefs, I don't see any reason why this site can't move forward. They would need to understand that certain tasks performed by CPP might be incomplete or erroneous but this is easily documented. John and Elardus, your inputs were extremely helpful and I thank you both. Cheers, Alan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John Eells Sent: Monday, October 06, 2014 10:02 AM To: [email protected] Subject: Re: z/OS datasets that must be in the MCAT (UNCLASSIFIED) Basically, if I recall correctly*, the ServerPac dialog MCAT=Y flag means one of more of: - The data set absolutely must be in the master catalog or something won't work. What "something" might be is left as an excercise to the Alert Sysprog, but it ranges from "the system won't IPL" to things like "I can't unallocate that catalog" (from my earlier example). - The data set has SYS1 as its default HLQ (perhaps true of additional qualifiers as well). - Development says it must be in the master catalog there even though (at present) the system will happen to work if it is cataloged elsewhere. - Development recommends that it be in the master catalog and/or has asked ServerPac Development to place it there. - The setup required to catalog it in a catalog other than the master catalog won't be done when the jobs are generated. * It has been over 10 years since I worked in ServerPac! So don't assume this is all 100% correct and complete. But thinking along these lines can inform your poking around to find out what sorts of rules might be in effect today. I think the last might explain many of the ones you are questioning. My 3C just means that when you step outside the boundaries of what Development says we will support, the risk of dealing with the fallout from any changes we might happen to make is one you assume. For example, if we reorder IPL processing so that some component that is today initialized after usercats can be opened (but before CAS starts) so that it is initialized before that time, things might not work any more, or work the way they used to work. I have snipped and interspersed some additional comments below. [email protected] (Storr, Lon A CTR USARMY HRC , US) wrote: > CPP includes LOGR.CDSnn, WLM.CDSnn and XCF.CDSnn as MCAT=YES but the manuals > indicate that this is true only if no volser is specified in COUPLEnn. I suspect the dialog will not generate jobs to add volumes to COUPLExx. > CPP includes BRODCAST as MCAT=YES but the manuals indicate that DD=SYSLBC may > be safely omitted from MSTJCLnn (and included in IKJTSOnn), which also > eliminates the MCAT requirement. Same reason, different place. > CPP includes UADS as MCAT=YES but I am 95% positive that I have, in the past, > specified a volser on DD=SYSUADS and it has functioned. Same reason, different place. > CPP includes SYS1.DFSMS.* as MCAT=YES. I am almost positive that the SCDS is > not referenced during system initialization and, therefore, need not be > MCAT-cataloged (if it's not called SYS1.**). Additionally, the Storage > Administration manual shows examples using DSNs prefixed by HLQ=SMS and do > not mention cataloging requirements. I am fairly certain that the SMS > subsystem initializes after CATALOG, so he should be happy with > UCAT-cataloging. No idea why, and I won't research it (sorry), but you could ask why if you have Q&A support. > CPP includes hlq.IODFnn and SYSn.IPLPARM as MCAT=YES but I believe that NIP > will find both if they are on the IODF device specified to IPL (i.e. they > don't need to be found via a catalog at system initialization and they may be > catalogued in a UCAT). This is a case of "if you want them found via the catalog." I think (but do not know for certain) that you'll find that both have "SYS1" as their default HLQ. > CPP indicates that the SMF datasets (MANn) do not require > MCAT-cataloging; this corresponds to the information in the manuals. I > found this strange because I would have thought that SMF begins > recording before CATALOG is initialized I don't know when SMF recording starts, or when the SYS1.MAN* data sets might be opened (they could be done in either order). I also don't know whether the data sets are "allocated" in a normal sense or not. As SYS1.MAN* recording has been around for a some while now, I'd certainly trust the books! > > Your categorization is appealing. Most of the aforementioned datasets (except > BROADCAST, SYS1.DFSMS.* and SMF MANn) would fall into category 2. > > I was particularly intrigued by your caveat 3c. For the sake of clarity, are > you saying that the MCAT indications in CPP are to be interpreted as IBM's > statement of "how things work"? In other words, not adhering to the > configuration generated by CPP is not adhering to "how things work"? I ask > because: > > a. MCAT requirements in CPP do not necessarily match information in the > manuals. > b. Not all customers utilize CPP. > Not quite. (a) is certainly true, sometimes to keep ServerPac support costs under control and sometimes because (gasp!) someone has marked something in error during product integration. Errors here are fairly rare, though, as the "must be in MCAT" list is pretty stable and I'd expect them to have been flushed out by now! -- John Eells z/OS Technical Marketing IBM Poughkeepsie [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN Classification: UNCLASSIFIED Caveats: NONE ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
