On Tuesday, 05/27/2008 at 11:35 EDT, Ivica Brodaric <[EMAIL PROTECTED]> wrote: > Maybe you are not even using port name on z/OS. I don't know much about z/OS, > so I cannot help you find it, but even if you are not using port name in z/OS, > you have to be sure that nothing else comes up before the z/OS guest, connects > to the hipersocket and changes port name from nothing into something.
A mismatched port name on an OSA creates an initialization error. In any case, HiperSockets do not have port names. On z/OS they are addressed solely by chpid (DEVICE IUTIQDxx). My apologies for creating confusion; I was addressing only the incorrect assertions about port names rather than focusing on the problem at hand. It's been a while and I've forgotten the details, but HiperSocket communication requires: 1. Both LPARs reference the same HiperSocket chpid. Note that z/OS does not allow specification of a HiperSocket chpid that is being used for dynamic XCF. Verify: Get a packet trace to see that packets are being place on and received from the HiperSocket. 2. Both IP stacks have correct local routes. That is, the same subnet and subnet mask with no gateway specification. Verify: Look at the routing table. Make sure the "gateway" for the HiperSocket subnet is 0.0.0.0. And make sure you don't have overlapping routes. 3. Both stacks are using the same MTU and that MTU is consistent with the MFS value in the chpid definition. Verify: It shouldn't cause a problem with PING, but will result in lost packets for any frame that exceeds the MTU of the receiver. If you want to do all that, fine, but I'd suggest first bringing up both images as z/VM guests and connect them to a HiperSocket Guest LAN instead of real HiperSockets. Be sure to use the CHPID parameter on the NICDEF for a z/OS guest to ensure that the correct virtual chpid is chosen, matching your real HiperSocket chpid number. Compare the routing tables. They should be the same, virtual or real, as far as the HiperSocket interface is concerned. By the way, I'm not cross-posting to IBM-MAIN. Let's try to consolidate discussion in just one place (here). Alan Altmark z/VM Development IBM Endicott
