RE: New details, Re: Troubleshooting Telnet connections that drop for no apparent reason -- HELP?

-1 returned from read(byte[], int, int) doesn't mean an EOF character was read. It means that the sequence of IP packets is done.

As I recall, when the 5250 controller sends a readMDT, it stops sending and starts waiting for a response. It appears to me that the behavior is as expected.

I think the error lies in trying to read again after the readMDT is received.

If it is as I suspect, the read after receiving readMDT is going to send an ENQ and the 5250 controller will send back NAK as it is itself waiting for data. As a matter of fact, the ENQ may be followed by an ACK, as the receiver is expecting data and says "right, go ahead and send", but your read never sends anything, so the receiver would time out and start sending NAK's which may trigger the -1. Hard to tell as there are so many layers of protocol involved.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H. H. Lampert
Sent: Friday, May 17, 2013 4:14 PM
To: Midrange Systems Technical Discussion
Subject: Re: New details, Re: Troubleshooting Telnet connections that drop for no apparent reason -- HELP?

On 5/17/13 1:02 PM, Dan Kimmel wrote:

Are you replying to the read modified data tags?

Not, so far as we can determine, until after the socket goes EOF. Since there are no fields on the screen, much less any with MDTs set, the response consists of only column, row, and AID bytes, wrapped in a
TN5250 packet. And according to the timestamps, it was sent more than a full second *after* the EOF.

--
JHHL

-----Original Message-----

First, at timestamp 16:28:41.519, we get a block of 1297 bytes. This
block renders a rather unremarkable message display screen using a
subfile, using one Write To Display command that renders the screen, a
second WTD that ends immediately after the control characters, and a
Read MDT Fields command.

Then, at timestamp 16:28:42:222 (less than 3/4 of a second later), we
get a failed read on the socket. Specifically, the Java is.read(byte[]
b, int off, int len) on the socket is itself returning a -1 (which is
supposed to indicate an EOF), and no exception is being thrown.

Then, at timestamp 16:28:43.988 (over 1 3/4 seconds later) we try to
send a 13 byte (15 with the terminating IAC EOR) response.

Since this whole sordid affair has begun, I've been unable to force an
EOF on a Telnet socket with our hardware, not by killing the
connection in WRKTCPSTS, not by varying off the device, and not by
physically unplugging the Ethernet cable.

-- JHHL

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.