Active TN3270 Clients Might Hang Unexpectedly (253206)


The information in this article applies to:

  • Microsoft SNA Server 3.0 SP1
  • Microsoft SNA Server 3.0 SP2
  • Microsoft SNA Server 3.0 SP3
  • Microsoft SNA Server 3.0 SP4
  • Microsoft SNA Server 4.0
  • Microsoft SNA Server 4.0 SP1
  • Microsoft SNA Server 4.0 SP2
  • Microsoft SNA Server 4.0 SP3
This article was previously published under Q253206

SYMPTOMS

An active TN3270 client might hang unexpectedly when pressing a key to send data to the host. At this point, the client is no longer able to send or receive host data. Microsoft SNA Server Manager continues to show an "In Session" status for the TN3270 session that is in this state.

CAUSE

A small timing window exists that allows a TN3270 client to send a request to a TN3270 server when the TN3270 server is expecting a response for some host data that it just sent to the client. At this point, the TN3270 server queues the new request the client sent because it cannot be sent to the host until a response to the previous data is sent. The problem is that the TN3270 server is unable to read any responses from the client after it has queued the previous request. The TN3270 client hangs at this point because the TN3270 server no longer sends data to or receives data from this client.

RESOLUTION

To resolve this problem, obtain the latest service pack for SNA Server 4.0. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

215838 How to Obtain the Latest SNA Server Version 4.0 Service Pack


STATUS

Microsoft has confirmed that this is a problem in Microsoft SNA Server versions 3.0, 3.0 SP1, 3.0 SP2, 3.0 SP3, 3.0 SP4, 4.0, 4.0 SP1, 4.0 SP2, 4.0 SP3.

This problem was first corrected in SNA Server 4.0 Service Pack 4.

MORE INFORMATION

After applying the update, the TN3270 server no longer sends requests to the host when the host is expecting a response for that particular session. In addition, it no longer queues requests from clients when it is expecting a response from the client.

The issue described here is extremely hard to reproduce because the timing window that allows this to occur is very small. The following is a scenario that can expose this timing window:
  1. Host sends an RU with EB set.
  2. TN3270 Server sends this to the client, which unlocks the keyboard. At this point, the client is able to send data.
  3. Host sends a BID to initiate a new Bracket on the session.
  4. SNA Server sends a BID +RSP.
  5. Host sends an RU that contains data. This RU also has a Begin Bracket (BB) flag set.
  6. The TN3270 server sends this data to the client indicating the a response is required to acknowledge the receipt of the data.
  7. The client presses a key to send data to the host.
The timing has to be such that the last two steps occur at approximately the same time for the problem to occur. Once the TN3270 client receives the data from the host, the keyboard locks until all of the data is received and the client receives direction to send. Therefore, the client has to send the request after the TN3270 server has sent the data to the client, but before the TN3270 emulator processes the data such that the keyboard is locked.
Modification Type:MajorLast Reviewed:6/28/2004
Keywords:kbbug kbfix kbQFE kbSNA400PreSP4fix kbSNA400sp4fix KB253206
©2004 Microsoft Corporation. All rights reserved.