RUI Application Receives Duplicate MSG10 Screen

ID: Q234843


The information in this article applies to:
  • Microsoft SNA Server, versions 3.0, 3.0SP1, 3.0SP2, 3.0SP3, 3.0SP4, 4.0, 4.0SP1, 4.0SP2

IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.

SYMPTOMS

If an RUI application is configured to open several instances of pooled LUA sessions, SNA Server may receive a duplicate USSMSG10 (that is, VTAM Signon or "banner") or USSMSG7 (VTAM error) screen on the SSCP-LU session under certain timing conditions. This duplicate screen is then passed to the RUI application during normal session cleanup. Receiving the additional SSCP-LU message may cause problems for the application because it was not expecting to receive this information twice. The actual symptoms experienced are application-specific because it depends on how the application is designed.

NOTE: This problem is not limited to RUI applications and may occur with any application that uses LUA or 3270 LU Pools.


CAUSE

While rapidly deactivating and activating a dependent session, the SNA Server may receive the host's USSMSG10 or USSMSG7 screen (intended for the previous user) after SNA Server has sent a NOTIFY(SLU Enabled) message to activate the session for the new user, along with another USSMSG10 screen for the new session activation. Because SNA Server actually receives two SSCP-LU messages from the host, the 3270 or LUA application receives both messages.

At this time, there has only been one reported instance of this problem because under normal circumstances, a host does not send a USSMSG10 or USSMSG7 screen after receiving a NOTIFY(SLU Disabled) during session cleanup.


RESOLUTION

To resolve this problem, obtain the latest service pack for SNA Server version 4.0. For additional information, please see the following article in the Microsoft Knowledge Base:

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


STATUS

Microsoft has confirmed this to be a problem in Microsoft SNA Server versions 3.0, 3.0 SP1, 3.0 SP3, 3.0 SP4, 4.0, 4.0 SP1, 4.0 SP2. This problem was first corrected in SNA Server version 4.0 Service Pack 3.


MORE INFORMATION

SNA Server returns an LU to its pool for subsequent session requests after it receives a NOTIFY(SLU Disabled) +RSP from the host in response to the NOTIFY(SLU Disabled) that it sent to inform the host that the session has been terminated by the application.

To prevent the duplicate MSG10 signon screen problem from occurring, a new feature has been added to SNA Server to allow for a configurable delay before returning an LU to its pool for use after a NOTIFY(SLU Disabled) +RSP has been received.

In addition to applying the updated binaries, the following registry entry has to be added to configure the amount of delay desired.

WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys and Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT, you should also update your Emergency Repair Disk (ERD).

  1. Start Registry Editor (Regedt32.exe).


  2. Locate the following key in the registry:


  3. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\SnaServr\Parameters
  4. On the Edit menu, click Add Value, and then add the following registry value:


  5. Value Name: SSCPDelay
    Data Type: REG_DWORD
    Value: Delay in Seconds
  6. Quit Registry Editor.


The value entered is the time interval in seconds before an LU is released for reuse in the pool. This is a global parameter that affects all 3270 and LUA pools. If a five-second delay is specified, an LU will not be released for use until five seconds after SNA Server receives the NOTIFY(SLU Disabled) +RSP for this LU.

The following scenario was observed in the one reported instance of this problem when using a multi-threaded RUI application:
  1. An application thread issues an RUI_TERM to terminate a host session. The following shows the message flow between SNA Server and the host.


  2. 
           SNA Server                        Host
    
           TRMSLF                ->
                                 <-          TRMSLF +RSP
                                 <-          UNBIND(Normal)
           UNBIND +RSP           ->
           NOTIFY(SLU Disabled)  ->
                                 <-          NOTIFY +RSP 
  3. The RUI_TERM for this thread finishes.


  4. Another thread issues an RUI_INIT against the same LU Pool at approximately the same time the first thread is issuing the RUI_TERM.


  5. 
           NOTIFY(SLU Enabled)   ->
                                 <-          MSG10 Screen
                                 <-          NOTIFY +RSP
           +RSP                  ->
                                 <-          MSG10 Screen
           +RSP                  -> 
For additional information about a similar problem using RUI applications receiving duplicate signon screens, please see the following article in the Microsoft Knowledge Base:
Q107384 RUI Interface Enhancement to Avoid Duplicate Signon Screens
NOTE: The INITDELAY parameter described in this article doesn't solve the problem when using LUA pools because another application or thread in the same application may still get in and observe this problem

Additional query words:

Keywords : sna4sp3fix sna3 sna3sp1 sna3sp2 sna3sp3 sna3sp4 sna4 sna4sp1 sna4sp2
Version : WINDOWS:3.0,3.0SP1,3.0SP2,3.0SP3,3.0SP4,4.0,4.0SP1,4.0SP2
Platform : WINDOWS
Issue type : kbbug


Last Reviewed: September 29, 1999
© 2000 Microsoft Corporation. All rights reserved. Terms of Use.