Alan,
> A mismatched port name on an OSA creates an initialization error. Correct, but with a caveat explained in the other thread (yes for z990 onwards, before z990 one character could mismatch. I know it sounds weird, but that's the way it worked) In any case, HiperSockets do not have port names. Ummm, no. They can be specified for HiperSocket connection in DEVICE statement in VM and in DEFINE LINK statement in VSE. And after peeking into some z/OS manuals, I found that even z/OS is not oblivious to port names. >From "z/OS V1R9.0 Communications Server IP Configuration Guide": <quote> Therefore, there are two types of HiperSockets devices: - DYNAMICXCF HiperSockets device or interface (TRLE "IUTIQDIO" and an MPC group of subchannel devices). The PORTNAME will be IUTIQDxx, where xx = the IQD CHPID that VTAM(R) uses (for example, IUTIQDFD when using IQD CHPID x'FD'). - A user-defined HiperSockets device or interface (TRLE "IUTIQDxx" and an MPC group of subchannel devices). The PORTNAME is not applicable for this TRLE. In both cases, the TRLE is dynamically built by VTAM. <end quote> I presume that we have a user-defined HiperSocket here, but in the response to Q LAN DETAILS command for the virtual LAN that Mark defined to test the connection to the VM stack via virtual HiperSocket there is a following line: Adapter Owner: ZOS19 NIC: 0724 Name: *IUTIQDFF* That "Name:" at the end is port name (not device name). If the portname was not used by z/OS, it should've said "Name: UNASSIGNED". So which one is it? DYNAMICXCF or user-defined? And why did it work anyway? Maybe virtual HiperSocket is more lax towards the port names than real HiperSocket, because Mark says that the connection over the virtual HiperSocket worked. I also do not want to overly emphasize this port name thing, but I still think that it is worth while clearing. I think Mark said that he copied z/OS from the LPAR to a guest on VM, changed the home IP address and attached the real HiperSocket device trio to z/OS guest as the same addresses that z/OS expects. So I don't think that we will get any further by doing that again, except that this new copy of z/OS will be unmodified. Maybe still worth a try... Your point 1 seems to be in contradiction with the quote above, but I'll believe you have your reasons. Your point about MFS and MTU is great. I can't see nothing wrong in NETSTAT HOME and NETSTAT GATE responses provided in the other thread, but I noticed there that packet size is 57344 (56K) for IUTLNK1 link. How does that work? Does z/OS automatically adjust the MTU of the interface when the device is activated? This would indicate that CHPID is defined with "OS=C0" (64K MFS). Mark, when you defined a virtual HiperSocket, you used default MFS of 16K as I see in QUERY LAN response. Try with MFS 64K operand in DEFINE LAN. Just to remove any difference between the real and virtual HiperSocket... Ivica Brodaric
