Yes, and it's specified in examples in some documentation (Redbook Paper "Linux on IBM eserver zSeries and S/390: VSWITCH and VLAN Features of z/VM 4.4"). Yeah, it's old! :)
Frank M. Ramaekers Jr. -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Alan Altmark Sent: Friday, August 27, 2010 1:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Duplicate VOLID's On Thursday, 08/26/2010 at 09:58 EDT, Tom Huegel <tehue...@gmail.com> wrote: > So I guess there is no way to absolutly protect z/VM from using the wrong pack > at IPL.. Maybe a requirement? In SYSTEM CONFIG allow optional rdev on the SLOT > deffinations. comments? Rich Corak has explained on previous occasions how volser recognition works. If CP detects a duplicate volser for a device to be attached to SYSTEM at IPL, you will get HCP954I DASD rdev1 VOLID volid IS A DUPLICATE OF DASD rdev2 and you are responsible to ensure that rdev2 is the one you intended to be attached to the system. Out of all the volumes on the system with that volid, the lowest *device number* (address) will win, without regard to who responds first. As has been suggested, this is no guarantee since you can find yourself in trouble if you have a dasd problem or someone dinks with the I/O config and makes a mistake. Being able to place the RDEV on the CP_owned and user_volume_xxxx statements is one way to help mitigate the problem. There is another way to identify devices: by their architected node element descriptor (NED). Or in the lingua franca, universally unique identifiers (UUIDs). When Single System Image hits the streets, you will find UUIDs very much in evidence, though not in the context of IPL or SYSTEM CONFIG. But I could imagine something like this in SYSTEM CONFIG: CP_Owned Slot 1 6X0RES ID 2105.000.IBM.13.3737504EE.0D0A CP_owned Slot 2 6X0TD1 ID 2107.900.IBM.13.29839621A.0D0A CP_owned Slot 3 6X0PG1 ID 2107.900.IBM.13.4924295DC.0D0A, (yes, there are two IDs for slot 3) 2107.900.IBM.13.0358113AA.0D0A (..choose in the order given) so that you wouldn't have to worry about the RDEV. However, there is a Heisenberg-esque trade-off to be made between flexibility and security. Good news - the above syntax ensures you won't have any bogus volumes. Bad news - it won't tolerate any copies or change in DASD, so it's generally hostile to a dynamic DR environment, and you can't get the NED until you IPL. Hmmm....or....when IPL has finished, CP could write the found UUIDs to the warm start area and use those in preference to any other on a subsequent IPL. For PPRC pairs, write both UUIDs and allow either. If a volume with the needed UUID is not available, then (based on configuration) ask which RDEV to use a la z/OS, or just take the lowest-numbered one available. In either case, update the UUID in the warm start area. hmmmm..... Alan Altmark z/VM Development IBM Endicott _____________________________________________________ This message contains information which is privileged and confidential and is solely for the use of the intended recipient. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution, or use of the contents of this message is strictly prohibited. If you have received this in error, please destroy it immediately and notify us at privacy...@ailife.com.
