Article ID: 171253
Article Last Modified on 6/29/2004
APPLIES TO
- Microsoft SNA Server 4.0
- Microsoft SNA Server 3.0 Service Pack 4
This article was previously published under Q171253
SYMPTOMS
A twinaxial connection goes to an Active state in SNA Server Manager after the connection is started, but users are unable to get active APPC sessions on an AS/400 through the twinaxial connection.
The System Operator Log (QSYSOPR) on the AS/400 may contain a message similar to the following after the twinaxial connection on the SNA Server is activated:
NOTE: The System Operator Log on the AS/400 can be accessed by entering the following command on an AS/400 command prompt:
DSPMSG QSYSOPR
The following event may also be logged in the Windows NT Application Event Log on the SNA Server computer:
This problem does not occur when you upgrade SNA Server 2.11 to SNA Server 3.0.
CAUSE
The problem is caused by the way SNA Server 3.0 saves the twinaxial connection properties in the SNA Server configuration. The twinaxial connection is saved as a Peer connection, as are all other connections to AS/400s. The problem is that twinaxial connections are not saved with all of the connection properties that other Peer connections include, such as Peer DLC Role and XID Type.
WORKAROUND
To work around this problem:
- Install SNA Server 2.11 and then upgrade to SNA Server 3.0 after getting the twinaxial connection to work under SNA Server 2.11.
STATUS
Microsoft has confirmed this to be a problem in SNA Server version 3.0 and 3.0 Service Pack 1 (SP1). This problem was corrected in the latest SNA Server version 3.0 U.S. Service Pack. For information on obtaining this Service Pack, query on the following word in the Microsoft Knowledge Base (without the spaces):
S E R V P A C K
After you apply the updated binary file, do the following so the twinaxial connection will successfully connect to the AS/400:
- Stop and restart the SnaBase service.
- Save the SNA Server configuration. If the Save option is greyed out in
SNA Server Manager, some kind of change will need to be made in the configuration before the configuration can be saved.
MORE INFORMATION
The problem is that twinaxial connections are not saved with all of the connection properties that other Peer connections include, such as Peer DLC Role and XID Type. This results in an incorrect sequence when activating a twinaxial connection, as shown below:
SNA Server Twinax Link Service ---------- ------------------- Open Link Request --> <-- Open Link RSP OK Open Stat Request --> <-- Open Stat RSP OK <-- DLCST STCD <-- DLCST RQOS DLCST SXID --> <-- DLCST RQOS
In this sequence, the XID negotiation, shown as SXID and RQOS messages, is done after the Station Contacted (DLCST STCD) message.
The correct sequence when activating a Peer connection is shown below:
SNA Server Twinax Link Service ---------- ------------------- Open Link Request --> <-- Open Link RSP OK <-- DLCST RQOS DLCST SXID --> <-- DLCST RQOS DLCST SXID --> <-- DLCST RQOS Open Stat Request --> <-- Open Stat RSP OK <-- DLCST STCD
In the correct sequence, the XID negotiation occurs before the Open Station (Open Stat) and Station Contacted messages.
SNA Server has been updated to correctly save the twinaxial connection with all of the Peer connection properties and to do the XID negotiation before it does the Open Station sequence.
In addition, the Twinaxial connection properties page will be updated to include a System Identification page. This page will include configuration options for the Local Node Name, Remote Node Name, XID Type, and Peer DLC Role.
Keywords: kbbug kbfix kbnetwork KB171253