On Thu, 23 Feb 2006 11:59:06 -0500, Alan Altmark <[EMAIL PROTECTED] > wrote:
>You have two different examples. For the DEDICATE case, the virtual chp id >number is the same as the physical chpid number. For a simulated NIC, t he >virtual chpid will be chosen using a complex algorithm. To override the >chpid number: > NICDEF 1700 CHPID 17 TYPE HIPER LAN SYSTEM MYLAN > > >Alan Altmark >z/VM Development >IBM Endicott >======================== ========================= ======================== Thanks. For the NICDEF case, I saw the CHPID parameter shortly after posting. I just came from a Disaster Recovery Planning conference call in which I' m told, and the manual confirms, that the CHPID used on the NICDEF must not currently be in use. If it is, the virtual NIC will not be defined. I just did a test, and "in use" does not seem to include CHPIDs defined for hipersockets. I did a DEFINE NIC using CHPID F0, which has real hipersockets on it, and it created the device, but using CHPID 4C, which has DASD on it, failed. For some TCPIP stacks (such as z/VM TCPIP or LINUX TCPIP) the specific CHPID doesn't appear to be of any concern, but it is for a z/OS guest stack. Is there any hope of correcting that situation through virtualization by z/VM or a new version of z/OS? Otherwise it appears to represent a "hole" in a the virtualization model. While this may be controllable within my own site it becomes an issue going to a DR site where I have no control and which CHPIDs are in use may change depending on which physical box I get put on. If I have multiple z/OS guests connected to independent Guest LANs under z/VM, can they all safely use the same CHPID value on the NICDEF (good) o r do they all have to be unique (bad)? I think the answer is they can share, but want to confirm it. Brian Nielsen
