On Tuesday, 09/01/2009 at 07:45 EDT, "O'Brien, Dennis L" 
<dennis.l.o'br...@bankofamerica.com> wrote:
> We're starting to test hipersockets between Linux guests on z/VM and 
z/OS 
> systems in separate LPAR's.  z/OS is having intermittent trouble pinging 
one of 
> the four Linux guests, but is fine with the other three.  All four Linux 
guests 
> have no trouble pinging z/OS.  Someone suggested that the device 
addresses used 
> have to be unique among all the LPAR's.  E.g. if z/OS in LPAR 1 
allocates 
> FC00-FC02, then I shouldn't allocate real FC00-FC02 on z/VM in LPAR 2 to 
a 
> Linux guest, but should start with FC03 or FC04.  I've never heard of 
such a 
> restriction, and the source of the advice is suspect.  Is there such a 
> restriction? 

No, there is no such restriction.  There is a limit of 12K subchannels 
across all 16 IQD chpids.  If you share at the chpid level, then all 
devices are shared.  Each shared device, whether used or not, counts 
against the 12K total.  So in the typical case, using FC00-FC02 in LPAR 1 
and FC03-FC05 in LPAR 2 simply wastes 3 subchannels.

> If the device addresses aren't the problem, what else should I look at? 
The 
> TCP/IP configurations on the Linux guests are identical, except of 
course for 
> the IP address.  The intermittently-working guest has an IP address that 
ends 
> in ".1".  I know that ".1" addresses are customarily used for routers, 
but 
> there are no routers in this configuration.

.1 doesn't mean anything special.  I'm guessing that there is a routing 
(subnet) problem in the z/OS system or that one Linux guest.  If Linux 
speaks first, then z/OS is updating his routing tables with information 
gleaned from the arriving packet.  If the entry times out, z/OS no longer 
knows how to find the Linux system until it speaks again.  Or it's a 
mutual error wherein both must try to speak before either can successfully 
communicate.

Eyeball the routing tables carefully to make sure that VIPAs and dynamic 
routing updates aren't interfering.

Alan Altmark
z/VM Development
IBM Endicott

Reply via email to