Microsoft KB Archive/813564

= Applications Cannot Use LUs from Remote SNA and Host Integration Servers =

Article ID: 813564

Article Last Modified on 12/4/2007

-

APPLIES TO


 * Microsoft SNA Server 4.0
 * Microsoft SNA Server 4.0 Service Pack 1
 * Microsoft SNA Server 4.0 Service Pack 2
 * Microsoft SNA Server 4.0 Service Pack 3
 * Microsoft SNA Server 4.0 Service Pack 4
 * Microsoft Host Integration Server 2000 Standard Edition
 * Microsoft Host Integration Server 2000 Service Pack 1
 * Microsoft Host Integration Server 2004 Standard Edition

-



Important This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows Registry



SYMPTOMS
A Systems Network Architecture ( SNA) application that runs on an SNA Server or a Host Integration Server may not be able to use resources (such as 3270, LUA, TN3270, or APPC LUs) that are defined on other SNA Servers or other Host Integration Servers in the SNA subdomain. However, the SNA application can access resources on the local SNA Server or on the local Host Integration Server 2000 server.

For example, a TN3270 Server runs on an SNA Server SNA1 and uses a TN3270 pool that contains LUs from SNA1. Now, SNA2 cannot use any of the available LUs on SNA2 when all the LUs on SNA1 are in use. When this occurs, the 3270 Client (Win3270.exe) reports the following error when it tries to connect to an LU in the TN3270 pool:

[TN3270-36] : ERROR - An error occurred during device type/name processing.

The same problem may occur with native SNA Server or Host Integration Server clients that have a sponsor connection to one SNA Server or Host Integration Server server, in that an attempt is made to access an LU from another SNA Server or another Host Integration Server.

In addition, the problem may occur when the SNA Servers or the Host Integration Servers in the SNA subdomain use additional SNA Server services.



CAUSE
The problem occurs when an additional SNA Server service (for example, SnaSrv02) on an SNA Server or a Host Integration Server is restarted while there is a temporary communication outage between the SNA Servers and the Host Integration Servers in the SNA subdomain. When the additional SNA Server service is restarted, that service obtains a dynamic TCP/IP port to listen on. The new TCP/IP port is different from the one that the service previously used. The SNA Server or the Host Integration Server, where the additional SNA Server service is defined, sends out service table updates periodically to the rest of the SNA Servers and the Host Integration Servers in the SNA subdomain. Therefore, the new TCP/IP port information is sent to all the SNA Servers and the Host Integration Servers.

The problem results because the SNA Servers and the Host Integration Servers that receive these service table updates do not read all the fields in the update messages. Only several fields of interest are read in each of the service table update messages. If the additional SNA Server service is restarted during a communication outage on the network, then the other SNA Servers and the other Host Integration Servers are not notified that the service is restarted. Therefore, when communication resumes the other SNA Servers and the other Host Integration Servers assume nothing is changed with the status of the other SNA services in the SNA subdomain. The result is that the other SNA Servers and the other Host Integration Servers do not read the updated TCP/IP port information for the restarted additional SNA Server service.

Any SNA Server or Host Integration Server that tries to connect to the additional SNA Server service with the incorrect TCP/IP port cannot connect to that additional SNA Server service. This results in the failure to use any resources that are defined on that particular SNA Server service.



RESOLUTION
The following registry entry must be added to force SNA Servers and Host Integration Servers to read all the fields in the service table update messages each time the messages are received.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

Follow these steps, and then quit Registry Editor:  Click Start, click Run, type regedit, and then click OK. Locate and then click the following key in the registry:

 

 On the Edit menu, point to New, and then click DWORD Value. Type FullCompare, and then press ENTER. On the Edit menu, click Modify. Type 1, and then click OK.</li></ol>

<div class="status_section">

STATUS
Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the &quot;Applies to&quot; section of this article.

<div class="moreinformation_section">

MORE INFORMATION
If an SNA Server or a Host Integration Server server does not receive any service table updates from another SNA Server or another Host Integration Server for a period equal to 5 * (Mean Time between Server Broadcasts), the SNA Server or the Host Integration Server may time out all the service table entries for that particular server. The default value for the &quot;Mean Time between Server Broadcasts&quot; setting is 60 seconds, so the default timeout is 5 minutes. This value is configured in SNA Server Manager under the Server Broadcasts tab on the SNA Subdomain properties dialog box. If the communication outage between the servers lasts more than 5 minutes (assuming default values), this problem does not occur. After the communication between the servers resumes after this period of time, the service table entries for the SNA Server and the Host Integration Server that had entries timed out are completely refreshed.

Steps to Reproduce the Problem

 * 1) Set up two SNA Server or Host Integration Server systems. Name them SNA1 and SNA2.
 * 2) Add an additional SNA Server service to SNA2, and name the additional service SnaSrv02.
 * 3) Run the SnaSrv02 service on SNA2.
 * 4) Disconnect the network cable from SNA1.
 * 5) Stop and then restart the SnaSrv02 service on SNA2.
 * 6) Reconnect the network cable to SNA1.

At this point, SNA1 still has the TCP/IP port number that the SnaSrv02 service on SNA2 used before the service was restarted.

<div class="references_section">