If you want to stick to dedicating the adapters, you¹ll need to use different real addresses (eg, 7D0,7D1,7D2, 7D3, 7D4, 7D5, etc), but dedicate them to the same virtual address (eg 7D0, 7D1, 7D2) in the CP directory for the zOS guests.
In the directory for z/OS 1: DEDICATE 7D0 7D0 DEDICATE 7D1 7D1 DEDICATE 7D2 7D2 (the easy case). In the directory for z/OS 2: DEDICATE 7D3 7D0 DEDICATE 7D4 7D1 DEDICATE 7D5 7D2 (z/OS 2 still sees addresses 7D0-7D2, but the real hardware uses a different OSA triplet so everyone plays nice). Do the same with z/OS 3. If you¹re willing to experiment and get a MUCH niftier way of doing it (dedicating devices is SO old-skool z/OS... Sniff), use a VSWITCH. Define the VSWITCH with real device 7D0 as the real device in DEFINE VSWITCH. Grant ZOS1, ZOS2, and ZOS3 access to the VSWITCH. Then in the CP directory use NIC statements for 7D0 connected to the VSWITCH. Slick, easy to manage, and MUCH more flexible in how you use the hardware. > At current time, I have each z/OS guest with his own triplet of unique OSA > addresses. Each one will work fine UNTIL they are all up and running, at which > time, we start seeing ³console hangs² and what appears to be machine lockups. > Some times they will eventually clear themselves, sometimes not. And it > rotates as to which z/OS guest system hangs. This sounds more like resource exhaustion than a network-related issue. Look at the recommendations for system resource management sessions that are in the Linux guides and in the "running guest OS" manual. A lot of the problems are similar (but zOS is even more ill-behaved in some ways).
