sampleThere are currently 48 uniVerse sessions; 19 interactive, 29 phantomPid.... User name. Who. Port name..... Last command processed.......10760 efv 9 Unknown Unavailable 8104 jcd -30 Unavailable 4132 jcd -43 Unavailable 8588 jcd -44 Unavailable 10660 jcd -46 Unavailable
There are currently 48 uniVerse sessions; 19 interactive, 29 phantomPid.... User name. Who. Port name..... Last command processed.......5555 userA 9 Unknown Unavailable <-- phantom executing socket call6666 userB -30 Unavailable <-- uvcs from sb/xa7777 userB -43 Unavailable <-- uvcs from sb/xa8888 userB -44 Unavailable <-- uvcs from sb/xa9999 userC -46 LIST VOC <-- uvsh...
I am sure Steven will come up with the actual technical answer, but I can provide some anecdotal information that might help.We work in a Universe on AIX environment, but we also occasionally get the "unavailable" response to some ports when we run a PORT.STATUS. Our experience has been that PORT.STATUS will return "unavailable" under the following conditions: - The process that is running on that port is VERY busy and does not respond to the PORT.STATUS command - The connection (uvcs or ssh) has been dropped by the user, but the back-end process is still active and has not terminated (stuck on a lock, stuck in a tight loop, etc.) - The process on that port is stuck waiting on some kind of system input (like a response to a disk write) and is ignoring other system requests - The process that was running on that port aborted in such a way that it did not properly clean up the workspace (very rare).Again, though, we're in an AIX environment, so I don't know if any of these scenarios apply to the Windows world or not.