Classification: UNCLASSIFIED Caveats: NONE John,
Thank you very much for your detailed and well-considered response. I believe that you have confirmed my belief that UCATs become safely available after the CATALOG address space initializes. I hadn't realized that UCATs can be opened before CATALOG initializes, in which case these UCATs do not belong to CATALOG. I had perused many manuals and the CPP dialog before I posted my question but I discovered many gray areas and, I believe, conflicts. 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. 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. 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. 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. 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). 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. 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. Best regards, Alan -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John Eells Sent: Friday, October 03, 2014 9:38 AM To: [email protected] Subject: Re: z/OS datasets that must be in the MCAT (UNCLASSIFIED) This is rather more complex than it appears on the surface and there are some subtleties. For instance, user catalogs can be opened after a certain point in IPL and before the CATALOG address space (CAS) comes up, but they will not be able to be unallocated later using F CATALOG,UNALLOCATE because CAS won't own the allocation. That might be a problem for you someday, or not. So while you can* catalog things like the RACF DB in a user catalog, it's not recommended (and in the RACF DB case we might simply say it's required in the master catalog just to avoid the problem). I seem to recall, but have not lately tested, that if you are using UADS and BRODCAST you can specify VOL=SER and UNIT in MSTJCL and not catalog the ones you actually use at all. (There might need to be cataloged ones, though, or not.) There is also some risk that, when you step outside the bounds of what we say you need to do, "what works today might not work next year." If we tell you it's required in the master catalog, we will expect you to catalog it there, and if we later make a change that makes the requirement absolute and things stop working the way you have them set up the developer might not have a lot of sympathy. I suspect that we quite purposefully avoid documenting the order in which system services become available during IPL. We have been known to reorder them from time to time for one reason or another. With all that said: In the ServerPac dialog, Modify System Layout includes a selection in the View and Change menu for: "Master Catlg Must be in Master Catalog (Yes, No, or Overridden)" You can select "Yes" to see what we've marked as "must be in master catalog." A more complete description of this option would be something like "(1) absolutely must be in master catalog, or (2) must be in the master catalog if you want the system to find it using a catalog (like the NUCLEUS with its required SYS1 HLQ), or (3) must be in master catalog unless you (3a) really know what you're doing and (3b) are willing to do more work or accept the consequences of putting the data set in a user catalog that we don't tell you about (like the RACF DB example above)" and (3c) are willing to take the risk of us changing how things work in the future. So if you really want the list of data sets in category (1), you can start with the list generated by View and Change and then figure out how to remove the data sets in (2) and (3) from your list if you're so inclined. * This was certainly true at one point. I did not verify whether or not it is currently true. If we later moved RACF initialization to before user catalogs can be processed during IPL, all bets are off! [email protected] (Storr, Lon A CTR USARMY HRC , US) wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Hello List, > > It appears that some of the old restrictions regarding MCAT-cataloging of > installation-allocated datasets that are accessed during system > initialization (usually for OUTPUT) have been relaxed. > > I have verified that page datasets must still be defined in the MCAT but, > other than that, I haven't yet found any absolute restrictions. Even couple > datasets, it seems, may be in a UCAT if a volser is specified in COUPLExx. > > So far, I've checked SMF (MAN) datasets, BRODCAST, "couple", UADS, USS file > systems (including root) and DFSMS ACDS/COMMDS. I find no text explicitly > forbidding UCAT cataloging. > > I'm fairly certain that the CATALOG address space must be active before UCATs > are accessible but I'm rather fuzzy about exactly where in the system > initialization timeline this occurs (i.e. relative to the components that > want to access these datasets). > > What other installation-allocated datasets that z/OS accesses during system > initialization must be MCAT-cataloged? > -- 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
