none
HIS 2010 Remote S3270 Connection Not Releasing RRS feed

  • Question

  • I'm running HIS2010 to connect to a mainframe at another site.  Everything is working fine and I can connect remotely to my HIS server using s3270 from a scripted application on another server.  I've noticed that over time the LU's are not being released and over time eventually fill up and I need to restart the TN3270 service (and only this service) to release the connections.  I watched a wireshark for successful connections and then "hung" connections.  I can see the same finish sequence with a data finishing followed by a fin, ack from the remote server an ack from my HIS server then a fin, ack from the HIS server and an ACK from the remote server.  I go into the remote server and I still see the connection open with no data being sent and subsequent connections use a new LU.  It's almost like its just hung and someone didnt release the connection.  Again in Wireshark a failed and successful close look identical.  Has anyone experienced anything like this?
    Thursday, April 25, 2013 6:56 PM

Answers

  • We normally see this behavior when a TN3270 client abnormally disconnects from an active TN3270 session. When this occurs, the TN3270 service is not aware of the client disconnecting and therefore it keep the session (LU) active until the TN3270 Idle Timeout expires. Due to how the TN3270 Idle Timeout works, the actual timeframe could be from the configured timeout value (120 minutes by default) to twice the timeout value.

    Is the Idle Timeout set to 120 minutes in the TN3270 Server Properties? If so, do you know if the sessions are freed 2 - 4 hours after the client disconnects?

    You indicate successful and hung connections, what is the difference between the two? In other works, is anything done differently from the client side for a "successful" connection?

    Can you reproduce the problem using the 3270 Client (win3270.exe) in TN3270E mode when you connect to a session and then do a proper disconnect within the emulator?

    Thanks...


    Stephen Jackson - MSFT

    Thursday, April 25, 2013 8:45 PM
  • A LU stuck with a "In Session" status is normally caused (when using TN3270) for the reason I explained initially. The session between the "client" and the TN32760 Service was terminated abnormally. The TN3270 Service doesn't know the connection was terminated so it does not attempt to clean up the LU until the TN3270 Idle Timeout expires.

    Thanks...


    Stephen Jackson - MSFT

    • Marked as answer by FredWitt02 Tuesday, June 11, 2013 8:17 PM
    Monday, June 10, 2013 9:20 PM

All replies

  • We normally see this behavior when a TN3270 client abnormally disconnects from an active TN3270 session. When this occurs, the TN3270 service is not aware of the client disconnecting and therefore it keep the session (LU) active until the TN3270 Idle Timeout expires. Due to how the TN3270 Idle Timeout works, the actual timeframe could be from the configured timeout value (120 minutes by default) to twice the timeout value.

    Is the Idle Timeout set to 120 minutes in the TN3270 Server Properties? If so, do you know if the sessions are freed 2 - 4 hours after the client disconnects?

    You indicate successful and hung connections, what is the difference between the two? In other works, is anything done differently from the client side for a "successful" connection?

    Can you reproduce the problem using the 3270 Client (win3270.exe) in TN3270E mode when you connect to a session and then do a proper disconnect within the emulator?

    Thanks...


    Stephen Jackson - MSFT

    Thursday, April 25, 2013 8:45 PM
  • Hi Stephen, thank you for your reply.  Initially when testing the application we were using the 3270 client emulator locally and we never encountered the issue.  I do suspect its more of the remote system, but figured I'd ask the question in the event someone was in the same scenario and had experienced something similar.  You may have however solved this problem.  I honestly didn't realize there was an idle timeout on the 3270 service and actually just scripted a simple bat script to restart the service every 6 hours.  The timeout was set to infinite, I have since adjusted it to 60 minutes.  I have also disabled my script and plan on letting this run through the weekend to see if this resolves the issue.  While the root of the issue still has not been identified (again, suspecting client not HIS server), at least I have a workable solution while I dig into the client.  Thank you very much for your help and suggestions.  I'll be sure to post back results after the weekend.

    THANKS!

    Friday, April 26, 2013 1:26 PM
  • Since modifying the idle value the connections are closing.  I also added registry values for TCP KeepAlive to have the other side of the connection close out the open socket.  

    One quick follow-up to this question.  Is there a method to keep the LU's always up to the remote server?  This way when a client connects to the HIS server there is already an open LU socket and the HIS server isnt building the LU connection on-demand.

    Thanks,

    Fred

    Wednesday, June 5, 2013 8:34 PM
  • Neither the TN3270 Service nor the SNA Server service has a way to keep a session open and connected at all times. This is controlled by the application using the LUs. If the application connects to a session, the LU will be in use by that application until the application (or the mainframe) closes the session.

    The session activation process is normally very quick so there usually isn't a big delay that would warrant trying to keep everything up and active at all times.

    Thanks...


    Stephen Jackson - MSFT

    Friday, June 7, 2013 9:56 PM
  • Thanks Stephen for the reply, this is what we figured but was worth asking the question.  Along those lines we see on occasion certain LU's hang with "IN SESSION" status even though there is not data being transferred.  The idle timeout and some TCP stack tuning are closing the connections on both sides, but for a busy machine with limited LU's this at times causes issues.  Any thoughts on why this may be occurring?

    Thanks!

    Monday, June 10, 2013 1:24 PM
  • A LU stuck with a "In Session" status is normally caused (when using TN3270) for the reason I explained initially. The session between the "client" and the TN32760 Service was terminated abnormally. The TN3270 Service doesn't know the connection was terminated so it does not attempt to clean up the LU until the TN3270 Idle Timeout expires.

    Thanks...


    Stephen Jackson - MSFT

    • Marked as answer by FredWitt02 Tuesday, June 11, 2013 8:17 PM
    Monday, June 10, 2013 9:20 PM
  • Thanks for all your help!
    Tuesday, June 11, 2013 8:17 PM