Mark,
Exactly!
Sometimes we have to ask ourselves why we did things in the first place, and
test whether those things still apply.
In 1984 my Senior Sysprog taught me that we have many catalogs to isolate
catalog failure to just one or a few applications. That made sense, but the
catalog convections were something like:
UCAT.APPL.ATOI
UCAT.APPL.JTOR
UCAT.APPL.STOZ
You guessed it! The design did not match the criteria. To make matter worse
we consolidated several states into one data centre, and to avoid duplicate
dataset names they just added HLQ for every state - N2 for NSW, Q4 for
Queensland, etc. Well guess how much application separation there was for
those? Admittedly someone at least set up a catalog for each state, like
UCAT.APPL.N2. Nuff said on war story.
Back to the subject - part of this isolation idea was to place each catalog
on separate volumes, because volumes are big brown spinning things that
fail. This was a very good idea if your catalogs actually limited the scope
of failure to just a few applications.
I think the first idea still has merit, and it's a worth trying to maintain
this. It can reduce the scope of a catalog outage, and improve recovery
time.
I think the second part however, volume level separation, is past its use-by
date. The reason for volume separation no longer exist so why persist with
the practice. To restate Mark's school of thought comment, it is a better
thing to put all of your eggs in one basket, and watch that basket very,
very carefully. I lean towards a focal point for catalogs (a single or few
volumes) that would make them much easier to monitor, manage, slice and
dice, back-up, and ultimately recover.
Finally, if you really want to pursue hardware isolation using separate
volumes, then I suggest you consult with your storage vendor to make sure
the volumes you use are on separate parity groups or mirrored pairs within
the storage.
Ron
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of
> Mark Zelden
> Sent: Tuesday, May 04, 2010 9:36 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: [IBM-MAIN] Catalog re-location
>
> There is a school of thought with this type of thing (it can apply to more
> than just catalogs) that more than 1 or 2 increases your chance of
> having a problem. How many of your application(s) run out of just
> one catalog? IOW, if the data sets for your CICS / DB2 application
> are in a few catalogs and those catalogs are spread over a few
> volumes, it increases the chances for your app to have a problem if
> any one of the few volumes fails (we are not talking about logical
> errors in this discussion).
>
> I'm not saying I subscribe to this philosophy, but it is something to
> think about. I can tell you that I have lots of catalogs sharing
> volumes due to dasd migrations over the years (master catalog
> excluded).
>
> Mark
> --
----------------------------------------------------------------------
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
