> We have 10 zVM LPARS all of which simply run linux guests. We have no > CMS/other applications running on any of these systems. We also don't > care about spool files as they are primarily spooled console logs. Our > maintenance methodology is a "rolling RES pack" paradigm, and we keep > all of our third party products, linux guests, config files, etc. > separate from the OS. We install the VM updates to a 2nd-level system > and once we verify that all is well, we simply copy that RES vol around > to the rest of our zVM LPARS. If any maintenance touches CMS, I also > have to roll the spool volume around. By moving the NSS/DCSS segments > to the RES vol, I am simply trying to avoid having to copy a spool > volume around should any DCSS/NSS changes occur as everything will live > on the one RES volume.
One site I deal with added a short snippet of code to AUTOLOG1's PROFILE EXEC that checked for the presence of a virtual punch at a particular address, and if it wasn't present, defined it and AUTOLOGged a virtual machine that defined the "standard" set of NSSes (including CMS) and recreated all the NSSes on IPL. AUTOLOG1 then just did a polling wait loop until the designated virtual machine logged off and then continued normal startup. Something like that would still let you have your rolling RES approach, but keep spool off the RES, and since you don't have any CMS users, you're only worried about the set that IBM provides by default. You can probably cause VM/SES to resave them using the standard maintenance tools w/o writing anything fancy. > I am primarily concerned about any performance issues related to having > everything on the RES vol. Well, if you ever run out of page space, you'll spill over into that space, and things will start to get ugly really quickly. You're already on a large, relatively slow device, and (modulo PAV) you can't start more than one I/O at a time to a device, so the pain can get very high very quickly. > And yes, it would be nice if it was possible to redirect SPXTAPE output > :-). OK, now we need one more person. Then we'd be a movement.... -- db
