SNA Server SDLC Connection Fails to Reactivate After Host IPL (180538)
The information in this article applies to:
- Microsoft SNA Server 2.11
- Microsoft SNA Server 2.11 SP1
- Microsoft SNA Server 2.11 SP2
- Microsoft SNA Server 3.0
- Microsoft SNA Server 3.0 SP1
- Microsoft SNA Server 3.0 SP2
- Microsoft SNA Server 4.0
This article was previously published under Q180538 SYMPTOMS
An SDLC connection from SNA Server to a front-end processor (FEP) remains
in a pending state after the host performs an IPL. The only means of
recovery is to stop and restart the SNA Server service.
SNA Server may post an Event 23 in the Windows NT application event log
with a qualifier of 00A1 or 0025 as a result of these symptoms.
CAUSE
SNA Server is erroneously handling the non-activation XIDs sent from the
FEP on an SDLC connection and treating this as a connection outage.
STATUSMicrosoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section of this article. This problem was corrected in the latest SNA Server version 3.0 and 4.0 U.S. Service Packs. For information on obtaining these Service Packs, query on the following word in the Microsoft Knowledge Base (without the spaces):
MORE INFORMATION
With the fix applied, the Ibmsdlc.DLL interface allows for the correct
handling of SDLC non-activation XIDs.
The SNA Server Ibmsdlc.dll (SDLC Link Service) file supports a "dumb card"
driver interface that is published in the appendix of the SNA Device
Interface Specification (SNADIS) guide. This link service will work with
any dumb card implementation, such as Ibmsync.sys (the IBMSDLC driver),
Microgate, DCA ISCA, Attachmate SDLC, as well as others.
Other SDLC link services implement the full SNADIS interface so the
Ibmsdlc.dll is not used. Some examples of these link services
include Eicon SDLC and Barr SDLC.
| Modification Type: | Major | Last Reviewed: | 6/24/2004 |
|---|
| Keywords: | kbbug kbfix kbnetwork KB180538 |
|---|
|