On Thu, 18 Feb 2010 09:20:00 -0600, Darth Keller 
<darth.kel...@assurant.com> wrote:

>> 3. It rather does not depend on number of aliases. BTW: The number is
>> limited (by the filed in MCAT), but the limit is quite big (several
>> hundreds AFAIR).
>>
>
>-- Several thousands in fact.
>-- The sum of the lengths of all aliases cannot exceed 32300.
>
>Haven't seen where anyone's mentioned that catalogs are standard KSDS's &
>are there for limited to 4GB's.  Is that not still true?

A SHARE requirement was submitted to relieve the 4GB limit for catalogs.  
(Yes ... the process does work!)  This appears to be addressed in z/OS 1.12.  
Check the announcement preview.

>You also want to consider recoverability issues -  if all your production
>aliases are in one catalog and there's a catalog error (and they do still
>happen), this could result in ALL of your production applications being
>down.  One might argue increasing the # of catalogs increases the risk of
>catalog errors, but it also limits your exposure and can shorten the
>amount of time being spent in recovery.

Recovery is the major reason NOT to place all of your entries in a single 
catalog.  When that one catalog breaks (it's not if, but when), think about 
how you will manage to perform recovery.  Can you do this without relying on 
some cataloged dataset somewhere?  (There are ways; but, you need to plan 
for this event.)

Another consideration may be what happens when that catalog fills, for 
whatever reason.  (Lots of dead CAs, say.)  You may not be able to catalog 
anything new, until you re-organize the catalog.  Can you afford that outage 
to your entire shop?

>I once worked in a major shop where every production ds started P.** - I
>honestly believe that shop was one of the reasons multi-level aliases were
>designed.
>dd keller

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to