In case it is relevant, this VSWITCH is connected to a lab and is used exclusively for TPF guests. Each TPF machine has its own IP stack. The NETSTAT ARP command is useless as it always returns (I did try it), "DTCNET338E nn.nnn.nnn.i MAC address is not in the ARP table," for any i in the range (1,255). In addition, they do not show up in the response to NETSTAT CONN. Currently, there are 122 users connected to the VSWITCH in question. It appears that QUERY/SET NIC and QUERY/SET VSWITCH are the only commands available that I can use to see or affect the switch or NIC, or their users (barring SEND CP userid cmd, LOGOFF comes to mind as a good substitution value).
The VM TCPIP stack is connected to an entirely different network via a different VSWITCH. NETSTAT works great for it. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Thursday, January 10, 2008 1:14 PM > To: [email protected] > Subject: Re: VSWITCH > > On Thursday, 01/10/2008 at 04:06 EST, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > There is supposed to be nothing else connected to the network that > > shares the IP addresses. The OSA is not shared with another > LPAR. All > > guests that connect to the network do so via the switch. > E005 is the > > code, as seen in the message. > > "NETSTAT ARP" should show you the ARP cache of the OSA. Find > out what MAC address it is. Use OSA/SF or the OSA Advanced > Facilties on the HMC to see what he thinks about things. > > > What happens if USERA connects and registers an IP and > sometime later, > > after USERA has logged off, USERB, connects to the same > VSWITCH, tries > > to register that same address? Will this cause the 2833E > with the E0005? > > No. When USERA logs off, CP will unregister the IP (if he > registered it in the first place). USERB will then be able > to register the IP. If CP did not register the IP, then > message 2833E would be expected ad infinitum regardless of > which guest tries to register it. > > If you have all available VSWITCH service applied, and you're > seeing a different result, please get a dump and open a PMR. > > Alan Altmark > z/VM Development > IBM Endicott >
