This particular problem was reported to me by a customer, but I also found out that the same issue was being seen by the HIS Product Team on one of their iSeries systems. It was good timing all around as it might affect others that want to connect HIS 2006 or HIS 2009 to IBM iSeries (AS/400) systems using the IP-DLC link service.
The first symptom that you will notice is that the connection to the iSeries will display a status similar to the following in the SNA Manager MMC snap-in:
<connection name> [Pending](Failed @ <time>)
If you check the Application Event Log, you will likely see an event message similar to the following:
Event ID: 66
Source: SNA IP-DLC Link Service
XID protocol error during activation exchange
Sense code = 0x10160033
Port name = IPPORT00
LS name = @N000001
Adjacent CP name = APPN.CPNAME
Byte offset = 77
Bit offset = 00
XID frame :
32570000 00000000 00f4c800 800000a0
01010b70 0005b500 00000007 000e0ef4
c1d7d7d5 4bc3e2e3 c1d5d3c5 e81017f1
16110113 0011f9f4 f0f6f5f5 f0f4f4c7
f7f0f6f3 40404605 05800100 006108c8
XID protocol error during activation exchange. This may indicate an interoperability problem between this node and the adjacent node, or it may be cause by the adjacent node resetting and restarting the exchange without sending a DISC or DM frame. The sense codes are as follows.
The Cause section also includes a long list of sense codes and their meanings. I omitted them here for brevity. However, the sense code included in the event message above is not in the list of sense codes that is part of the Cause section. Just our luck, right?
I did look up the sense code and it is defined as follows:
0x10160033 – The Control Flows over RTP Supported indicator is set to 0 in the HPR Capabilities (X’61’) control vector of the XID3 received from the adjacent node. The IP port supports only links to nodes that support control flows over RTP.
If you are interested in what the Control Flows over RTP indicator is for, you can go to the following link to read how IBM explains the Control Flows over RTP Tower option.
If you check things on the iSeries side, you may see that the controllers used for the connection drop into a RCYPND (Recovery Pending) state. The QSYSOPR logs on the iSeries system may contain a message similar to the following when the problem occurs:
Technical description . . . . . . . . : The error log identifier is
X’00000000′. The XID is 328105DFFFFF000000B7D1008000008200010B700005D50000000000000E0EF4C1D7D7D54BC3
The error code is X’CCCC000E’: Control Vector X’22’ was found in the XID that was received from the remote system.
It turns out that the problem occurs because the Allow HPR transport tower support setting was set to *NO (it was disabled) on the IBM iSeries systems that were having this problem. To check this setting, you can do the following:
1. Connect to the iSeries system using a 5250 or TN5250 emulator or to a console on the iSeries system.
2. Type DSPNETA (stands for Display Network Attributes) on the command prompt and press ENTER.
3. Page down a couple of screens until you see the Allow HPR transport tower support option.
If it is set to *NO, you will need to change it to *YES to allow the IP-DLC connection to successfully connect to the iSeries system.
In addition, you need to setup the Ethernet line to autocreate controllers as well in order to get all of this working. You can check this by displaying the line description (DSPLIND command) of the communication line that is being used.
Hopefully, this information will prove useful for someone.