Sorry I'm late to the party, but this is becoming a very interesting topi c.
Alan - the ONLY way?? Does that mean the lower level tools of VMSES/E suc h as our long time friends vmfREC, vmfAPPLY and vmfBUILD will no longer be available? We have 16 z/VM systems here that are divided into 'test', 'development' and 'production'. All have local mods (created over a 20+ year span) and some vendor supplied code. We also have a VERY SPECIFIC technique for pushing maintenance out. When we install fixes/updates (our own, IBM or third party vendors) we first roll that maintenance (call it M1) out to one of our test systems. If it works for a period of time (days) we then roll M1 maintenance to the other test systems. If all test systems run error free for a period of time (days/weeks) we then roll M1 out to the development systems where users bang on it a little more thoroughly. If the development systems run error free for a period of time (weeks/months) we roll M1 out to the low impact production systems and then the high impact production systems. You might ask: "How in the world do you keep 16 z/VM systems in-sync at a ll appropriate times?" A big part of the answer is that we have only one 'MAINT' userid for ALL of the systems. Since we support more than one release of z/VM concurrently, we don't really have a 'MAINT' userid anywhere - we currently have userids 'zvmv5r20', 'zvmv5r30' and 'zvmv5r40'. There is only one of each. These 'master' userids run the standard series of VMSES/E commands to install maintenance to appropriate components. The one thing they do NOT do is build nuclei. We have a separate tool for that. The 'build tool' again is entirely VMSES/E based. We indicate what system a CP Nuc (for example) is to be built for, and at what maintenance level (M 1 in the above sequence). The load module is built, load maps archived, a comparison is performed against the previous CP nucleus *for that system* to show what has been added and possibly regressed, along with some miscellaneous things. We then ship that CP Nuc to the appropriate system and load it to the proper PARM disk. You might ask: "How do you keep all those different CPLOAD MODULEs straight?" Hint - they're not called CPLOAD. Each CP Nuc is identified with the syst em it runs on and a sequence number for that system. So a nucleus for system 'ABC' might be called CPABC07. The next Nuc build for system ABC would be CPABC08. This can all be staged at any time, since the new Nuc with the new name won't be the default load until we run SALIPL. Mind you, this system was designed by a VMSES/E Religious Zealot. He 'SES'ified everything - even things that had no reason to use SES - li ke TRACK! And it's been functioning successfully for the past 20+ years. So, *ONLY* SERVICE and PUT2PROD?? What happens if your CPLOAD MODULE is not called CPLOAD? And what happen s if VMSES/E isn't even installed on every system? Can I do a PUT2PROD from my maintenance system in Kansas City to my production system in London? Jerry
