Some more new details, Re: Troubleshooting Telnet connections that drop for no apparent reason -- HELP?

Ok. Some of this is in answer to questions that were raised off-List, but the more people see what I just got from the customer, the better.

To recap: We know that this one customer is experiencing an EOF (an actual EOF returned from a readStream operation on the socket's input stream, with no exception thrown) in our TN5250 client. And we know that, in the two good data points we have to date, this EOF is occurring less than a second after receipt of a perfectly good TN5250 host transmission, ending in a Read MDT Fields command. And we know that it's intermittent, and that most of the time, the emulator behaves as expected (and as it does everywhere else), i.e., the input stream on the socket sits in a blocked state until the host sends something else. And we know that a 5250 Read MDT Fields command does *not* expect an immediate response; rather, the host waits for an AID keystroke (actual or generated), or an ATTN or SysRq, or until it has another transmission of its own (e.g., a message notification, or a break message, or a terminal session timeout).

And we know that I've been unable, so far, to even find a way, from the host side, to force an EOF on the socket input stream of an active session: if I kill the connection from WRKTCPSTS, or if TCP itself is shut down, it throws an exception; if I physically disconnect the Ethernet cable, the readStream operation continues to block, and once I reconnect, it waits briefly, then throws a "connection reset" exception.

And while we have a terminal session and an account on their box, we do *not* have sufficient authority to even *look* at the TCP or Telnet settings through CFGTCP.

======= THE *NEWEST* INFORMATION =========

It seems that Client Access's terminal emulator does *not* experience this phenomenon at *any* of the customer's locations. Not sure whether it's going through an actual TN5250 connection: the only Client Access emulator I have at my disposal at present is the LAN Console on our E4A, which doesn't show up as a TN connection in WRKTCPSTS.

It seems that the customer has users located in two States. Those in one State never have the problem, and users in the other State experience it frequently (but still seemingly at random).

The users in the State where the problem is occurring are almost all on what the customer's representative describes as "Virtual Machines," while very few in the other State are on "Virtual Machines." I'm assuming they don't mean JVMs (since the emulator, being part of a Java application, is always running in a JVM), but other than that, it is unclear to me what is meant by "Virtual Machines" in this context (and I've asked); it could mean anything up to and including boxes "in the Cloud."

Does any of this make sense to anybody? Does any of this suggest any lines of further investigation (other than the obvious one of finding out what they mean by "Virtual Machines")?

--
James H. H. Lampert