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
