Skip, Funny you mention all this. Personally, I have never gone the FSR route, it's always been SU. I am not a fan of the full replacement nor the use of these SSA's. Frankly, they scare me, mostly because I so rarely use them and am worried I would update something other than what I expect to update.
At my shop I have two sets of alternating base volumes for z/os install that are never IPL'd from. One volume is all the targets(including ZFS), and the other contains all the DLIB's plus other install related supporting datasets. None of the target or DLIB datasets(with the exception of ZFS) are cataloged. The other set is for the next release of z/OS. With Serverpac SU, I just allocate/load the entire package onto the unused base set of volumes, apply my site specific usermods, and am pretty much ready to IPL. I modify the DDDDEF job from serverpack to also include the volser in each DDDEF statement. Knowing that none of my base target/dlib datasets are never cataloged, and also never allocated or in use gives me a lot of flexibility. SYS1.LIBRARY is SYS1.LIBRARY, everywhere. We use a cloning process to migrate from the base to TECH->DEV->PROD. Target datasets for use in TECH/DEV/PROD are indirectly cataloged, Base environment is Never cataloged. Not sure if this answers your questions or not, but I find FSR way overkill for us. Only you can decide if it is worth it to change a process that already works for you. HTH, Dave -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Skip Robinson Sent: Tuesday, May 27, 2014 6:15 PM To: [email protected] Subject: ServerPac: Upgrade or Full Replace? We've done a whole lot of ServerPacs over the years. In every case up to now, we've done full replace (FSR) even though we have a perfectly usable set of 'operational data sets' in every sysplex that we end up using anyway as we migrate across the Enterprise. One reason for FSR is that it's kind of comforting to know that any previous sins (commission or omission) will get washed away in a fresh ground-up install. That comfort level comes at the price of creating a number of throw-away data sets like SPOOL, RACF, PAGE, etc. that we never intend to use. We minimize those data sets and selectively skip jobs that prepare them as SOP. I've come back from SHARE more than once with the ambition to try software upgrade (SU). I'm all ready to shift gears for 2.1 except for one sticking point. We depend heavily on a brand new level-specific catalog not just during ServerPac install but throughout the life of the z/OS release. That is, a data set created on sysres looks like this: SYS1.library SMP/E finds SYS1.library via the name OSRnn.SYS1.library, where OSRnn is a master catalog alias that points to MVSRnn.ICF.MASTER (our name), a user catalog created during FSR of release nn. Only the driving system needs this user catalog for maintenance and migration purposes because in production, sysres data sets are cataloged directly in master as SYS1.library . So here's the question. Having never gone the SU route, I don't know whether it will yield the expected MVSRnn.ICF.MASTER . If so, I'm off to the races. (Too late to enter Triple Crown.) Otherwise having to rework a number of tried-and-true processes would surely be more work than tweaking FSR yet again, a task we have practiced many times. So the 64 dollar question: does SU create an OS-level specific user catalog that we can continue to use for the life of the release? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
