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.
lon.a.storr....@mail.mil (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
ee...@us.ibm.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
