×
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.
Does your emulator support TLSV1.2?
In the SSL/TLS handshake, the host makes some suggestions about what versions they might use and the client replies with a list. If there's no match the host just closes the socket.Most SSL hosts these days are demanding TLSv1.2 as all the others have proven to be fairly easy to beat.
-------- Original message --------
From: "James H. H. Lampert" <jamesl@xxxxxxxxxxxxxxxxx>
Date: 11/19/19 1:52 PM (GMT-06:00)
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>, Java 400 List <java400-l@xxxxxxxxxxxxxxxxxx>
Subject: TN5250 data stream issues -- none of this makes any sense!
Cross-posted to the Midrange and Java ListsNone 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-- This is the Java Programming on and around the IBM i (JAVA400-L) mailing listTo post a message email: JAVA400-L@lists.midrange.comTo subscribe, unsubscribe, or change list options,visit:
https://lists.midrange.com/mailman/listinfo/java400-lor email: JAVA400-L-request@lists.midrange.comBefore posting, please take a moment to review the archivesat
https://archive.midrange.com/java400-l.Help support midrange.com by shopping at amazon.com with our affiliatelink:
https://amazon.midrange.com
midrange.com
