none
SessionConnectionDisplay Dispose issue RRS feed

  • Question

  • Hello,

    I've a question related to the SessionConnectionDisplay object. I'm using the Dispose method of the connection object when I need to close a connection with a mainframe. When the session is connected and there is a connection established with the SIServer process, the Dispose method is working as intended.

    But I have detected an issue when I invoke the Dispose method of a SessionConnectionDisplay object that is not really connected to the mainframe, because the SIServer connection was terminated unexpectedly.In this situation, the Dispose method hangs when is invoked and the process never ends.

    Is there a way to check if the SessionConnectionDisplay is really connected to the mainframe? Using the IsConnected property is not working because it's always true even if the SIServer connection does not exists. If it's not possible, can I set a timeout or something else to avoid the Dispose method to hang?

    When this method hangs, I've to terminate the process. Because I'm using it inside an orchestration, it keeps active until I terminate it.

    Thank you very much.

    Regards.

    Thursday, March 28, 2013 1:54 PM

Answers

  • Ok, sounds like it might be a similar effect as when you get tossed out of TSO after a time out. I will try to see if I can get a repro working on that front.

    You definitely should not be trying to use the SessionDisplay after you have Disposed the connection - even if only to do a Disconnect. Essentially Disconnect-ing the SessionDisplay removes a "View" of the screen from the connection....you can then create a new SessionDisplay (on another thread if needed) and using SessionDisplay.Connect(SessionConnectionDisplay), "attach a new view" to the connection (sorry for using quotation marks and view, but it is a little difficult to explain in words). In reality the internal classes and state associated with a SessionConnection are the state of the emulated screen, and one uses SessionDisplay to connect to the state and screen contents...thus when the SessionDisplay is Disconnected from the SessionConnectionDisplay the Host Session is not removed, and the state of the Host Session is kept around so that you can connect a new Display to it. It is only when the Dispose is called on the SessionConnectionDisplay that the host session (is meant to) goes away.

    Depending upon how the host kills the session (could be just that the session goes from being in LU-LU session to being in SSCP-LU, OR, it could be that the TN Server closes the socket), we might be able to spot a change in the OIA.

    Do you have any netmon traces of the TCP connection around the time that things go belly up?

    Rob

    Sunday, March 31, 2013 5:25 AM
    Moderator

All replies

  • So, just a few questions:

    • Is this SNA or TN?
    • When you say that the SIServer connection was terminated...do you mean the connection from SIServer to Mainframe, or the connection from the client app to the SIServer?
    • The OIA could give you information about whether the session is connected, would have to get to my source code to see which bits are set :-)
    • Were you trying to Dispose while a WaitForContent (or WaitForSession) is outstanding on another thread?
    • Did you do a Disconnect on the SessionDisplay first?

    Rob

    Friday, March 29, 2013 12:19 AM
    Moderator
  • Hello Rob,
    I'll try to respond all the questions.

    • SNA or TN? We are using TN to connect with the mainframe.
    • The connection that is terminated is the one from SIServer to Mainframe. This behavior happens because the mainframe does some batch jobs that disconnect the clients. We believe that when this batch is done, the connection between SIServer and the mainframe is lost, so we have to do it again before using a connection.
    • About the OIA, I have no idea on haw can I use this object to check if a connection is really established with the mainframe or not. If you have some code on how to use the OIA it'd be very helpful.
    • It's possible that some times the Dispose method can be called after a WaitForContent on the same thread. Before disposing a connection, we are trying to check if this connection can be used or not. To do this, we are trying to send a specific text to the screen.If the bahavior is not the expected, we are trying to dispose the connection. When the connection is not established, the WaitForContent methos fails with the specified timeout and we are trying to Dispose the connection.
    • We are doing first the Connection.Dispose. After this, the SessionDisplay Disconnect method is invoked.

    Thank you very much for your help.

    Friday, March 29, 2013 10:59 AM
  • Ok, sounds like it might be a similar effect as when you get tossed out of TSO after a time out. I will try to see if I can get a repro working on that front.

    You definitely should not be trying to use the SessionDisplay after you have Disposed the connection - even if only to do a Disconnect. Essentially Disconnect-ing the SessionDisplay removes a "View" of the screen from the connection....you can then create a new SessionDisplay (on another thread if needed) and using SessionDisplay.Connect(SessionConnectionDisplay), "attach a new view" to the connection (sorry for using quotation marks and view, but it is a little difficult to explain in words). In reality the internal classes and state associated with a SessionConnection are the state of the emulated screen, and one uses SessionDisplay to connect to the state and screen contents...thus when the SessionDisplay is Disconnected from the SessionConnectionDisplay the Host Session is not removed, and the state of the Host Session is kept around so that you can connect a new Display to it. It is only when the Dispose is called on the SessionConnectionDisplay that the host session (is meant to) goes away.

    Depending upon how the host kills the session (could be just that the session goes from being in LU-LU session to being in SSCP-LU, OR, it could be that the TN Server closes the socket), we might be able to spot a change in the OIA.

    Do you have any netmon traces of the TCP connection around the time that things go belly up?

    Rob

    Sunday, March 31, 2013 5:25 AM
    Moderator
  • Hello Rob,
    It seems that the mainframe is doing a batch job at night that is disconnecting every client that is currently connected. When it happens, we can not know if a specific session is really connected or not to the mainframe because the SIServer process is not reported about the disconnection. The only way I have found to check if the session is really connected is sending a command to the screen that should work if the session is connected; if it fails, I'm disposing the connection object and creating it again. I'm wondering if there is another way to check if the connection exist.
    It's impossible for us reproduce this behavior in the development environment because the batch job is only running in the Production one. I believe that the behavior at client side is similar than if We kill a SIServer connection and try to work with it but I'm not completely sure.
    I'll speak with the client to try to run the same job in the development environment. If it's possible, I'll get some traces.
    Thank you very much,
    Osman

    Sunday, March 31, 2013 6:22 PM
  • Any new updates on this issue?

    The last update I heard following your support case was that the solution was to check the OIA to see if it provides some details about the session state.

    Thanks...


    Stephen Jackson - MSFT

    Monday, May 6, 2013 2:42 PM