Auto-Recovery of APPC Sessions when Partner is Restarted
ID: Q107866
The information in this article applies to:
- Microsoft SNA Server for Windows NT, version 2.0
SUMMARY
By default, SNA Server automatically recovers APPC sessions under most circumstances if the remote end (such as CICS or an AS/400) is stopped and restarted. However, if APPC sessions are still not being recovered, SNA Server supports more aggressive session recovery when the RENEGLIMITS parameter is added to the Windows NT Registry.
WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.
MORE INFORMATION
To configure SNA Server 2.0 to support more aggressive APPC session recovery, do the following:
1. Run Registry Editor (REGEDT32.EXE).
2. From the HKEY_LOCAL_MACHINE subtree, go to the following key:
SYSTEM\CurrentControlSet\Services\SnaServr\Parameters
3. Add the following new parameter:
RENEGLIMITS:REG_SZ:YES
4. Restart SNA Server.
This causes SNA Server to re-negotiate CNOS session limits following any negative response to an APPC application bind request.
BACKGROUND
RENEGLIMITS and RETRYCNOS:
These variables only affect APPC LUs that support parallel sessions and determine SNA Server's behavior when an application BIND (non-CNOS BIND) fails.
By default, SNA Server performs CNOS negotiation:
- At start of day (when the session limits are initially zero).
- In response to an application issuing a CNOS verb.
Even after a connection outage, SNA Server does not reset session limits, so re-negotiation does not occur when the connection is reactivated.
The most likely reason for an application BIND to fail after a previously successful CNOS negotiation is that the partner LU has reset its session limits (perhaps because of a connection failure or being stopped and restarted) without SNA Server being informed by a request to re-negotiate the session limits.
If the remote application is now active, and there are no active sessions on the connection, performing CNOS re-negotiation solves this problem. If the CNOS re-negotiation fails, no further attempts are made to activate the session until the connection is restarted or the SNA Server application retries.
The default settings for SNA Server are: RENEGLIMITS=NO and RETRYCNOS=YES. These settings attempt to detect the conditions where the remote application requires re-negotiation of session limits, and to avoid unnecessary re-negotiation.
Setting RENEGLIMITS=YES causes re-negotiation in all circumstances (provided there are no active sessions).
Setting RENEGLIMITS=NO and RETRYCNOS=NO provides backward compatibility with the default behavior of Comm Server 1.x.
RENEGLIMITS:REG_SZ:NO:
When this variable is set to YES, SNA Server performs CNOS re-negotiation whenever an application BIND fails, regardless of the sense code. Otherwise, SNA Server performs CNOS re-negotiation according to the setting of RETRYCNOS.
Note that when RENEGLIMITS is set to YES, it overrides any setting of RETRYCNOS.
RETRYCNOS:REG_SZ:YES:
When this variable is set to NO, SNA Server does not automatically re- negotiate LU 6.2 session limits when an application BIND fails. Otherwise, SNA Server performs CNOS re-negotiation whenever an application BIND is rejected by an UNBIND request or with a BIND negative response containing one of the following sense codes:
Sense 1 Sense 2 ------------------------------------------- 0x0806 0x3426 (Resource Unknown) 0x0805 xxxxxx (Session Limit Exceeded) 0x0801 xxxxxx (Resource Not Available)
If the variable RENEGLIMITS is set to YES, it overrides any setting of RETRYCNOS.
Note that the default value for this variable was NO in Comm Server 1.x.
Additional query words: prodsna SNA CNOS APPC LU6.2 recovery reneglimits retrycnos
Keywords : kbnetwork ntnetserv Version : 2.0 Platform : WINDOWS
Last Reviewed: April 18, 1997
