ty, David for this fine explanation. It's a nice "trick of the trade".
David Boyes <dbo...@sinenomine.net> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 10/01/2010 04:02 PM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Applying Maintenance - Best Practice ty for this information, but I do not follow how the last cylinder of any pack on the IIS being unused allows you to name the real packs anything you want while still retaining the default names for the 2nd Level system. Could you explain in a little more detail? Think of it this way: by making the IIS systems deliberately short 1 cyl for each pack, you can do the following: On level 1, each disk has a unique label in real cyl 0, always, no excuses. Defining a minidisk from 1 to END on that pack gives you a virtual cyl 0 for your guest that can be the default IBM label set (eg 540RES or the like) without ever interfering with the real system or risking the possibility that the 1st level system will accidentally pick up a duplicate volser and use the wrong one. You can just restore the IIS to the minidisk, and it’ll Just Work. You can have as many second level systems as you want in this configuration, and they can ALL have the default labels. You just can’t directly IPL from them because the boot loader is in cyl 1 instead of 0. I solve that problem by having a process for DDR (or flashcopy) of cyl 1 to real cyl 0 from test to my “boot set” of volumes (I have one set for current, one set for pending IPL that I alternate between, so backout is just IPL from the other set if something goes totally casters up). It’s less confusing for IBM if the standard label set is there, and less confusing if you have to maintain a lot of similar systems. 6.2 is probably going to change a lot of that methodology – lots of new things coming, and we’ll have to see what still works and doesn’t work at that point. -- db
