On 01/11/2011 08:53 AM, Mark Zelden wrote:
On Tue, 11 Jan 2011 00:22:27 -0600, Brian Westerman
<[email protected]> wrote:
If that's what works for you then by all means you should stick with it.
I have performed literally hundreds of upgrades and I have never kept the
old master catalog as the master for the new system. Mostly it has to do
with "properly" setting up the master catalog in the first place. The only
datasets in the master catalog should be those that get shipped with the new
OS, the rest should be in usercats.
Wow! That is a surprise coming from someone who has done that many.
I guess this is a religious issue. I too have performed hundreds of
upgrades and I never bother creating a new master catalog just to
add a couple of new data sets that are needed. What are you gaining?
If it's cleanup, then there is a problem to begin with because there
shouldn't be "junk" in the master catalog.
There are often more than a few, but often those data sets are for
products / features that won't be used anyway, so who cares that they
sit on the sysres uncatalogged (I never catalog MSYS for example).
The last 2 times I created new master cats were for MVS/ESA 5.2 , since
sharing was allowed after that. Then I went to new master catalogs for
some systems after IBM told us that IMBED / REPLICATE would not be
allowed in the future (which we all know now that IBM reversed that
SOD, so I went through all that trouble for nothing).
I can see where you would be able to keep things going for quite a while
with system symbols for most of the important datasets, but eventually you
are going to have a bunch of useless entries in your master catalog or
things will move and you'll end up taking the chance that you will miss it.
There seems to be a lot of chance for things to go wrong, and with all of
the other issues involved in a migration, making it more complex, for me, is
not a "good thing".
I don't understand this. What symbols are required for important data
sets? I use symbols to refer to system specific data sets in PARMLIB
members for example, but I am not really using SYMBOLICRELATE.
What can go wrong when you aren't changing anything (except cataloging
a new required data set for LNKLST / LPA for example)? Yes, if you are
"sloppy" and never uncatalog data sets that go away with a new OS version,
then you will have some dead entries. In the grand scheme of things, even
a "large amount" (FSVO large) doesn't hurt anything. BTW, every migration
manual tells you the list of dsns that are no longer part of the OS. But
even without that, a simple VTOC compare will tell you the ones you can
uncatalog after all your MCAT sharing systems have been migrated. I
always keep a "$CLEANUP" member in my install PDS with activities that
need to be done after migration. Even if I used a new master catalog there
would be plenty of other post migration activities. Uncataloging a few data
sets that are no longer shipped is minor.
As I said though, if what you are currently doing works for you, then almost
by definition it's correct, for you. Just because I feel it adds
complexity, doesn't make me right, in the end, whatever works correctly is
what is right.
Agree 100% there. Not saying I'm correct either, just debating. But I
admit I have a really hard time seeing there other side's point of view
in this one. :-)
On the other hand, if you are not using symbols and you are really reusing
the same physical page datasets etc. then that's playing with fire.
I don't understand this either. Are you saying there is some potential harm
in IPLing a new version of the OS using previously formatted page data sets?
Cheers,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:[email protected]
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
...
When I first starting doing MVS installs and migration, at that point
the recommended method was to create a new master catalog, so we got
used to doing it that way and when that recommendation was relaxed we
didn't see any reason to change a procedure that was working.
I suspect the preferred approach may have something to do with how many
MVS images you run; and if you have multiple images in a sysplex sharing
a master catalog and install with rolling IPL, then changing the master
catalog would make things much more complicated. We only have a single
production image, so a new MVS version can't really be tested under load
without going live and putting all production on it at once. That is
always done on a weekend, and although it is rare, there have been a few
instances over the last 25 years where we were forced to back out an
upgrade. Call us paranoid, but we don't want any of the minimal system
pieces that must be present and functional to IPL the production system
on the old release of MVS, like the old master catalog, to be exposed to
damage by the new system. This attitude is also influenced by the fact
that we actually lost two different ICF catalogs at different times
during the 1990's due to MVS bugs. If you are in an environment where
you have other full-function MVS production systems to fall back on,
this might be no concern.
The only thing we allow to be cataloged in the master catalog are
datasets on "system volumes" which are associated with a particular
release of MVS. For a new release, we toggle between two sets of volser
names (e.g., MVS1RS/MVS2RS, MVS1CT/MVS2CT, etc.) and have a HLQ
associated with each master catalog to allow ds creation using an alias
from the other master catalog. We have methods in place to be sure that
any master catalog differences not related to target/dlib library
differences are understood and resolved and that aliases are synced on
the day of change over. We like the fact that this also gives us an
opportunity to review whether various installation datasets on these
volumes are still valid to retain. Activities that might alter alias
definitions, like adding/deleting system users, do not occur on
weekends, so that is not an issue.
--
Joel C. Ewing, Fort Smith, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
