Catalogs are one of the classic risk/exposure tradeoffs'. The risk of an
application and/or user being affected by the outage of a particular catalog.
The argument is fewer/larger catalogs vs. more/smaller catalogs.
In the former, the impact of the outage affects more of your operation, in the
latter less is affected.
The risk of any outage occurring is smaller in the 1st case (fewer components)
and larger (more components) in the 2nd case.
The tradeoff is risk of failure vs. impact of failure.
That being said, MCATS should be relatively isolated and segregated across
channels/control units. Ideally no more than 1 mcat per channel/control unit.**
UCATS - no more than one/volume and preferably the volumes spread over as many
channels/control units as possible. **
I am not sure I can see the need (technically) for more than one TSO ucat,
presuming there is anything resembling a rational retention policy. There might
be political reasons for such, and that will drive the discussion at to how
many, where,
Who gets assigned to which,.....
** Modern dasd pretty much makes this requirement meaningless. i.e. the risk of
a dasd failure taking out any "complete" channel/cu combination near zero.
In the good old days.......
HTH,
<snip>
Our "newby" team had an interesting discussion today regarding catalog "best
practices". I thought it would be enlightening to ask the list for input.
If you could rebuild your z/OS environment from scratch, however you wanted,
how would you organize user catalogs to optimize performance, availability and
recovery?
What volume(s) would you place them on?
How would you deal with the need for multiple TSO UCATs?
</snip>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
