On Monday, 03/08/2010 at 12:34 EST, "Steinback, Gerald" <gerald.steinb...@bankofamerica.com> wrote: > Sorry I'm late to the party, but this is becoming a very interesting topic. > > Alan - the ONLY way?? Does that mean the lower level tools of VMSES/E such > as our long time friends vmfREC, vmfAPPLY and vmfBUILD will no longer be > available?
vmfREC and Friends will still be there. With your CP mods appropriately identified, SERVICE will include them and build a CPLOAD MODULE on the CF2 disk, just as it would with vmfBUILD. If you don't want vmfBUILD writing on CF2, then modify the PPF to tell it where you want the module written. > 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 (M1 > 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. We are looking at the same coin from opposite sides. If you want to know what was serviced, there are logs from SERVICE. If you want to know what changed via the load maps, that's ok, too. > 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 system > 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 - like > 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 happens > 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? You can do whatever you want with CPLOAD MODULE on CF2. Copy it wherever you like with any name you like. It is simply that CPLOAD MODULE on CF2 represents CP at the then-current service level with your mods applied. I see no particular reason to interfere with the content of CF2 since that is part of "IBM space". After it gets created, do as you see fit. PUT2PROD does more than just CP, of course, where things can be a little more complicated. When we look over the horizon at clustered z/VM systems, there are two basic design points: - When you apply service to a particular level of the system, you apply service only once, without regard to the number of systems in the cluster using that level. - All systems who want the serviced level of the system *pull* the "runtime" components onto their local disks at their own convenience. It is a *pull* model since things like NSS builds are local phenomena. One of the objectives of this work is to get everyone on the same page so that we can all talk about the same things using the same terms and frames of reference. I *do* understand that there are tasks that you want to perform on the objects on a newly-serviced system. Continue to do them, but wrap what you need around SERVICE and PUT2PROD instead of vmfWhatever. Where they fall short, then let's talk. Personally, I think both SERVICE and PUT2PROD are ultimately going to require some sort of per-PPF and global exit capability (a la TCPRUN, :Exit, and TCPRUNXT) so that you can do custom things at well-defined points in the process, such as renaming modules to match *your* naming convention. Alan Altmark z/VM Development IBM Endicott
