Just curious: WHY?
What is the reason to put the things out of MCAT?
Of course I mean those object which IBM said" MCAT YES".
How many objects are covered? Few dozens?
Is the goal worth the complication?
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2014-10-03 o 15:37, John Eells pisze:
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?
--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is
intended solely for business use of the addressee. This e-mail may only be
received by the addressee and may not be disclosed to any third parties. If you
are not the intended addressee of this e-mail or the employee authorized to
forward it to the addressee, be advised that any dissemination, copying,
distribution or any other similar activity is legally prohibited and may be
punishable. If you received this e-mail by mistake please advise the sender
immediately by using the reply facility in your e-mail software and delete
permanently this e-mail including any copies of it either printed or saved to
hard drive.
mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: [email protected]
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 0000025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
