×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
Cross-posted to the Midrange and Java Lists
None of this is making any sense. There's got to be something I'm not
seeing:
We have a situation, on several customer boxes, in which the official
IBM emulator, whatever they're calling it this week, is working fine,
but our TN5250 client is constantly crapping out, sometimes without
staying up long enough to sign on.
In our emulator, we have a thread that monitors, reads, and buffers the
incoming data stream from the socket. There is a line of code that
adjusts the socket timeout, depending on whether or not a data stream
has been successfully processed on it at least once.
The socket is an SSL socket, at least in the cases I'm immediately
looking at.
And for no apparent reason, it loses the socket: the aforementioned read
gets an EOF, any write to the socket gets a broken pipe, and the line of
code that adjusts the timeout gets this Java stacktrace:
19 Nov 2019 11:02:17:java.net.SocketException: Socket Closed
at java.net.AbstractPlainSocketImpl.setOption(AbstractPlainSocketImpl.java:212)
at java.net.Socket.setSoTimeout(Socket.java:1141)
at sun.security.ssl.BaseSSLSocketImpl.setSoTimeout(BaseSSLSocketImpl.java:631)
at sun.security.ssl.SSLSocketImpl.setSoTimeout(SSLSocketImpl.java:2526)
. . .
Or if I comment out the line that adjusts the timeout, then the
stacktrace I get is:
19 Nov 2019 11:44:03:javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Broken pipe (Write failed)
at sun.security.ssl.SSLSocketImpl.checkEOF(SSLSocketImpl.java:1541)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:95)
. . .
The most frustrating part about this is that under what appear to be the
same conditions, the official IBM emulator (which I understand to now be
every bit as Java-based as ours) keeps on going as if nothing had ever
gone wrong!
Could this have anything to do with any of the issues raised in the
"5250 sessions killing the system" thread? Specifically, all that talk
of the IBM emulator automatically reconnecting?
--
JHHL
As an Amazon Associate we earn from qualifying purchases.