Define the NIC before you define another device on the same chpid,,, VM will
virtualize the CHPID for the other device..... You put defnic before any
LINK or dedicated dasd stuff,,, so chpid is not in use.... when you do
defnic... same for attach...
You have two different examples. For the DEDICATE case, the virtual chpid
number is the same as the physical chpid number. For a simulated NIC, the
virtual chpid will be chosen using a complex algorithm. To override the
NICDEF 1700 CHPID 17 TYPE HIPER LAN SYSTEM MYLAN
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) or
do they all have to be unique (bad)? I think the answer is they can
share, but want to confirm it.