Hipersocket definitions on z/OS guests

[Brian Nielsen]

The current IOCP has a hipersocket on CHPID F0 with IODEVICE addresses of
0700-070F for the z/OS LPAR. The z/OS TCPIP definitions for a hipersocket
are required to include the CHPID number of the hipersocket.

Such as: DEVICE IUTIQDF0 MPCIPA
where the "F0" is the CHPID number of the hipersocket.

If I move that z/OS image from an LPAR to a guest under z/VM I think the
CHPID would need to be based on the virtual channel address, not on the
real channel address,and not the real CHPID. I believe that because if I
connect the z/OS to a hipersocket VM Guest LAN there is no real CHPID and
no real address.

So, if I use:
DEDICATE 1700 0700
or NICDEF 1700 TYPE HIPER LAN SYSTEM MYLAN

then the value used on the z/OS TCPIP DEVICE statement would be IUTIQD17.

Is that correct?

Brian Nielsen

[Michel Raicher]

NOP..........
1700 VM will use address 1700 but chpid virtual will just the real 1700
device,,,
def nic has a chpid parameter.. for hypersockets.. when you do the defnic
use the chpid parm with the one defined to z/OS

"Brian Nielsen" <***@SCO.STATE.ID.US> wrote in message news:LISTSERV%***@LISTSERV.UARK.EDU...
The current IOCP has a hipersocket on CHPID F0 with IODEVICE addresses of
0700-070F for the z/OS LPAR. The z/OS TCPIP definitions for a hipersocket
are required to include the CHPID number of the hipersocket.

Such as: DEVICE IUTIQDF0 MPCIPA
where the "F0" is the CHPID number of the hipersocket.

If I move that z/OS image from an LPAR to a guest under z/VM I think the
CHPID would need to be based on the virtual channel address, not on the
real channel address,and not the real CHPID. I believe that because if I
connect the z/OS to a hipersocket VM Guest LAN there is no real CHPID and
no real address.

So, if I use:
DEDICATE 1700 0700
or NICDEF 1700 TYPE HIPER LAN SYSTEM MYLAN

then the value used on the z/OS TCPIP DEVICE statement would be IUTIQD17.

Is that correct?

Brian Nielsen

[Brian Nielsen]

On Thu, 23 Feb 2006 10:12:06 -0600, Brian Nielsen

Post by Brian Nielsen
The current IOCP has a hipersocket on CHPID F0 with IODEVICE addresses of
0700-070F for the z/OS LPAR. The z/OS TCPIP definitions for a

hipersocket

Post by Brian Nielsen
are required to include the CHPID number of the hipersocket.
Such as: DEVICE IUTIQDF0 MPCIPA
where the "F0" is the CHPID number of the hipersocket.
If I move that z/OS image from an LPAR to a guest under z/VM I think the
CHPID would need to be based on the virtual channel address, not on the
real channel address,and not the real CHPID. I believe that because if I
connect the z/OS to a hipersocket VM Guest LAN there is no real CHPID and
no real address.
DEDICATE 1700 0700
or NICDEF 1700 TYPE HIPER LAN SYSTEM MYLAN
then the value used on the z/OS TCPIP DEVICE statement would be IUTIQD17.
Is that correct?
Brian Nielsen

For the NICDEF version I've just found the answer: there is a CHPID
parameter on the NICDEF statement.

The question is still open for the DEDICATE version.

Brian Nielsen

[Brian Nielsen]

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
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) or
do they all have to be unique (bad)? I think the answer is they can
share, but want to confirm it.

Brian Nielsen

[Rob van der Heij]

Post by Brian Nielsen
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.

This thing even confused the people who wrote the documentation...
My understanding is that z/OS will make assumptions about topology of
the network based on the CHPID. So if z/OS finds two NICs with the
same CHPID, it will assume they connect to the same OSA.
Now if you were to connect the z/OS guest to both dedicated OSA and
Guest LAN, you would need to make sure they are on different virtual
CHPID, and since you cannot tweak the one of the dedicated OSA, you
pick the CHPID of the virtual NIC different from any real OSA in the
machine, just in case... And apparently there's also options for
confusion in z/OS when the virtual NIC is on the same CHPID as another
device. So this is an upper boundary for the number of different Guest
LANs each z/OS can connect to.

Those CHPIDs restrictions are within a single z/OS guest. I have no
idea whether a virtual parallel sysplex would make two z/OS guests
share confusion about CHPIDs, but otherwise you would be free there.
For simple systems management it might make sense to keep them the
same though...

Rob
--
Rob van der Heij
Velocity Software, Inc

[Michel Raicher]

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
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) or
do they all have to be unique (bad)? I think the answer is they can
share, but want to confirm it.

Brian Nielsen

[Brian Nielsen]

On Thu, 23 Feb 2006 22:44:39 +0100, Rob van der Heij

Post by Rob van der Heij
My understanding is that z/OS will make assumptions about topology of
the network based on the CHPID. So if z/OS finds two NICs with the
same CHPID, it will assume they connect to the same OSA.
Now if you were to connect the z/OS guest to both dedicated OSA and
Guest LAN, you would need to make sure they are on different virtual
CHPID, and since you cannot tweak the one of the dedicated OSA, you
pick the CHPID of the virtual NIC different from any real OSA in the
machine, just in case... And apparently there's also options for
confusion in z/OS when the virtual NIC is on the same CHPID as another
device. So this is an upper boundary for the number of different Guest
LANs each z/OS can connect to.

Which still begs the question: Why does z/OS (and apparently only z/OS)
need to know what the CHPID is ahead of time when other TCPIP stacks (ie
z/VM & LINUX) happily work with whatever CHPID gets dynamically assigned?
And is there any hope/plan for a remedy from either platform (z/OS or
z/VM)?

Brian Nielsen

[Brian Nielsen]

On Friday, 02/24/2006 at 10:52 CST, Brian Nielsen

Post by Brian Nielsen
Which still begs the question: Why does z/OS (and apparently only z/OS)
need to know what the CHPID is ahead of time when other TCPIP stacks (ie
z/VM & LINUX) happily work with whatever CHPID gets dynamically

assigned?

Post by Brian Nielsen
And is there any hope/plan for a remedy from either platform (z/OS or
z/VM)?

z/OS looks at the chpids to find out if it is sharing an OSA and to
confirm parallel connections for Hipersockets. The shared OSA
configuration is important to dynamic VIPA and IP takeover. I can't
remember for sure, but he may check the chpid numbers and compare defined
subnets. A useful thing, really. But it doesn't require specification of
a chpid number since chpid numbers can be extracted from the SCHIB.

All good stuff to be done.

We continue to discuss this with z/OS, but Real z/OS Customers should make
their requirements known to z/OS.

I'll see if our Real z/OS Systems Programmers are willing to pursue this
from the z/OS side.

As a Real z/VM Customer, I think z/VM should be required to handle the
virtualization of the CHPID number a guest sees, which the CHPID parameter
on NICDEF is not currently adequately doing. One of z/VM's benefits is
the isolation of a guest from the real hardware. In this case, it's not
being done.

Brian Nielsen

[Brian Nielsen]

Post by Michel Raicher
Define the NIC before you define another device on the same chpid,,, VM

will

Post by Michel Raicher
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...

That doesn't work.

This user directory entry:

USER CHPIDTEST xxxxxxxx 128M 128M G
NICDEF 0400 TYPE HIPER CHPID 4C
CONSOLE 009 3215 T

when logging on gets this message:

HCPNIC2797E NIC 0400 not created; CHPID 4C is already in use

Brian Nielsen