Shared master Catalog
Coates, Chris
I'm new to this list and hoping I have come to the right place. We are
running OS/390 2.5 in a basic sysplex with 2 lpar's in our production
environment. We are preparing to convert to a shared master catalog between
two of our test lpar's, in preparation to bringing up a parallel sysplex.
Does anyone out there know of a document of manual (like Redbook) regarding
conversion to a Shared Master Catalog?
Thanks in advance
Chris
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
DE MULDER MIGUEL
First quarter of 1999, we merged data from 3 lpars. We did not convert to
Shared MCAT, but we merged UCATs and we are now in // sysplex on these 2
systems (one was later removed). The big job was to handle duplicates D.S.
of our users (D.S. existing on several lpars and having the same dsname): a
bit less than 100.000 files with about 3.000 being duplicates. And we could
ofcourse not disturb our users (developpers) with this project.
I don't know if this case of figure can interest you ...
Miguel
Kees Vernooy
what is your reason for shared mcats?
It is not a requirement for parallel sysplex, as one could detect from your
question.
Kees Vernooy
KLM, Royal Dutch Airlines
Metz, Seymour
especially true if you have shared IPL volumes as well.
Shmuel (Seymour J.) Metz
> -----Original Message-----
> From: Kees Vernooy [SMTP:Kees.V...@KLM.NL]
> Sent: Friday, June 30, 2000 4:52 AM
>
> what is your reason for shared mcats?
> It is not a requirement for parallel sysplex, as one could detect from
> your
> question.
----------------------------------------------------------------------
Mark Steely
Hope this helps.
Thank You
Mark Steely
Southwest Airlines
(214) 792-7139
>>> Kees.V...@KLM.NL 06/30/00 03:51AM >>>
Chris,
what is your reason for shared mcats?
It is not a requirement for parallel sysplex, as one could detect from your
question.
Kees Vernooy
KLM, Royal Dutch Airlines
> > Hi,
> >
> > I'm new to this list and hoping I have come to the right place. We are
> > running OS/390 2.5 in a basic sysplex with 2 lpar's in our production
> > environment. We are preparing to convert to a shared master catalog
> > between
> > two of our test lpar's, in preparation to bringing up a parallel
sysplex.
> >
> > Does anyone out there know of a document of manual (like Redbook)
> > regarding
> > conversion to a Shared Master Catalog?
> >
> > Thanks in advance
> >
> > Chris
>
----------------------------------------------------------------------
Mark Thomen
talks about considerations for sharing catalogs. As for the ins-and-outs of it
being a master catalog, I'm not aware of any Red books available on the topic.
Coates, Chris wrote:
> Hi,
>
> I'm new to this list and hoping I have come to the right place. We are
> running OS/390 2.5 in a basic sysplex with 2 lpar's in our production
> environment. We are preparing to convert to a shared master catalog between
> two of our test lpar's, in preparation to bringing up a parallel sysplex.
>
> Does anyone out there know of a document of manual (like Redbook) regarding
> conversion to a Shared Master Catalog?
>
> Thanks in advance
>
> Chris
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
Skip Robinson
some considerations.
Q1 - Are all usercats currently shared? If so, the task is a lot easier
because duplicate data sets are minimized.
Q2. - If yes to Q1, are the usercats shared in the same way? That is, does
every alias that's defined in both mcats point to the same usercat? If so,
the task is easier still because you're even less likely to have duplicate
data sets.
As for mcat entries, there are four primary areas of concern:
1. Mcat nonvsam.
2. Mcat VSAM.
3. Usercats.
4. Aliases.
(1) is pretty easy to handle. Simply DEF NVSAM everything that's missing
from the 'target mcat'. Any duplicates will have to be resolved, but it's
generally system stuff, so you can decide it yourself. If you have two
SYS1.WHATSIT.COBLIBs, point to one and trash the other. If they have
different contents, settle on which one you want to keep.
(2) VSAM is tricky. For non-duplicate names, your best bet is REPRO
MERGECAT, which should be done on the 'target' system with the 'source'
system down. Any duplicates would have to be resolved one by one.
Recommendation: every system-specific data set in the master catalog--page,
SMF, LOGREC, VSAM or not--should have &SYSCLONE built into the name.
Guaranteed no more duplicates. If you don't already do that now, it's a
good time to start.
(3) Usercats that are not already defined to the target system mcat can
easily be IMPORT CONNECTed. (If you have duplicate usercats, you've got a
long row to hoe.)
(4) Aliases need to reconciled along with imported usercats. The thing to
watch out for (see Q2 above) is an alias that appears in both mcats but
points to different usercats. (Sharpen the hoe for this row.)
Best of all, according to the original post, is that these are 'test'
systems. Best to practice here before you have to do it in production.
If it's any consolation, 'merging' is the hardest thing we're called upon
to do in this business. Splitting off a portion of a system to another
image, data center, or continent is a breeze by comparison.
>
> I'm new to this list and hoping I have come to the right place. We are
> running OS/390 2.5 in a basic sysplex with 2 lpar's in our production
> environment. We are preparing to convert to a shared master catalog
> between
> two of our test lpar's, in preparation to bringing up a parallel sysplex.
>
> Does anyone out there know of a document of manual (like Redbook)
> regarding
> conversion to a Shared Master Catalog?
----------------------------------------------------------------------
Phil Anselm
master catalog datasets; then you can use different res volumes for
different levels of maintenance.
Mark Thomen
> The original poster didn't describe his current configuration, but here are
> some considerations.
>
> Q1 - Are all usercats currently shared? If so, the task is a lot easier
> because duplicate data sets are minimized.
>
> Q2. - If yes to Q1, are the usercats shared in the same way? That is, does
> every alias that's defined in both mcats point to the same usercat? If so,
> the task is easier still because you're even less likely to have duplicate
> data sets.
>
> As for mcat entries, there are four primary areas of concern:
>
> 1. Mcat nonvsam.
> 2. Mcat VSAM.
> 3. Usercats.
> 4. Aliases.
>
> (1) is pretty easy to handle. Simply DEF NVSAM everything that's missing
> from the 'target mcat'. Any duplicates will have to be resolved, but it's
> generally system stuff, so you can decide it yourself. If you have two
> SYS1.WHATSIT.COBLIBs, point to one and trash the other. If they have
> different contents, settle on which one you want to keep.
>
This is precisely why extended symbolic aliases were created. You can define
an alias for the duplicates without having to "trash" anything:
DEF ALIAS (NAME(SYS1.WHATSIT.COBLIB) -
SYMBOLICRELATE('SYS1.&SYSNAME..COBLIB'))
Rename each SYS1.WHATSIT.COBLIB to its appropriate name.
Of course, if the libraries are essentially duplicates of each other you may
still want to clean up your environment by deleting the duplicates. The above
technique is particularly useful when different systems are running different
levels of products (as in test and production systems sharing the dasd).
> (4) Aliases need to reconciled along with imported usercats. The thing to
> watch out for (see Q2 above) is an alias that appears in both mcats but
> points to different usercats. (Sharpen the hoe for this row.)
Same answer applies here.
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
----------------------------------------------------------------------
Skip Robinson
long standing problem with ISPF maintenance. A truly ingenious mechanism.
However, I respectfully suggest that they are NOT appropriate for the use
Mark suggests.
The whole notion of 'parallel sysplex' revolves around the concept of 'many
systems acting as one'. If you create a sysplex in which the contents of
library A.B.C are different depending on which system you run on, you've
not only violated the sysplex principle; you've created confusion for the
user and the possibility of disaster down the road. If you want two
different levels of COBOL, then create two libraries with distinct names
and make them both available by name on every sysplex member. Except for
brief transition periods from one maintenance level to the next, the user
should see the same view from any sysplex member.
Mark Thomen
<tho...@US.IB To: IBM-...@BAMA.UA.EDU
M.COM> cc:
Sent by: IBM Subject: Re: Shared master Catalog
Mainframe
Discussion
List
<IBM-MAIN@BAM
A.UA.EDU>
07/05/2000
08:35 AM
Please
respond to
IBM Mainframe
Discussion
List
<snip>
This is precisely why extended symbolic aliases were created. You can
define
an alias for the duplicates without having to "trash" anything:
DEF ALIAS (NAME(SYS1.WHATSIT.COBLIB) -
SYMBOLICRELATE('SYS1.&SYSNAME..COBLIB'))
Rename each SYS1.WHATSIT.COBLIB to its appropriate name.
<snip>
Mark Thomen
> Symbolic aliases are a marvelous invention. They finally solved for us a
> long standing problem with ISPF maintenance. A truly ingenious mechanism.
> However, I respectfully suggest that they are NOT appropriate for the use
> Mark suggests.
>
> The whole notion of 'parallel sysplex' revolves around the concept of 'many
> systems acting as one'. If you create a sysplex in which the contents of
> library A.B.C are different depending on which system you run on, you've
> not only violated the sysplex principle; you've created confusion for the
> user and the possibility of disaster down the road. If you want two
> different levels of COBOL, then create two libraries with distinct names
> and make them both available by name on every sysplex member. Except for
> brief transition periods from one maintenance level to the next, the user
> should see the same view from any sysplex member.
This certainly is one perspective; however I can tell you that the very reason they
were created was to address what you say should not be done: Different data set
names depending on the system it is referred to by. Specifically people that have
a sysplex containing a "test" machine which might contain a new version of
compilers, utilities, products, etc., and they want to be able to run regression
testing against it without massive changes to JCL. The use of a alias that
resolves to a system-specific name means ALL JCL can say "SYS1.COBLIB". The whole
concept of staged migration of releases of products into members of a sysplex in a
non-disruptive way was a key user requirement.
What you view as a disadvantage, or perversion of the "parallel sysplex" notion is
viewed as a distinct advantage by many, and I know for a fact that they are using
it in the very way I described above.
--
Mark Thomen
DFSMS Development - Catalog, IDCAMS, and VSAM
Try the Catalog and VSAM Knowledge Base at:
http://SSDDOM01.storage.ibm.com/TechSup/swtechsup.nsf/support/dfsmsmain (click
"Technical Database")
or http://knowledge.storage.ibm.com/
----------------------------------------------------------------------