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/ ---------------------------------------------------------------------- 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
