Channel Interface Processor Microcode Release Note and Microcode Upgrade Requirements

This document contains the release notes for the unbundled CIP microcode software. Prior to Cisco IOS Release 11.1, CIP microcode was provided as part of the Cisco IOS software "bundle". In Cisco IOS Release 11.1 and later, the CIP microcode was unbundled from the Cisco IOS software. The CIP microcode is available as a separately loadable software module and you match the version of the CIP microcode to the Cisco IOS software release.

Refer to the "CIP Microcode and CIP Hardware Compatibility" section for a list of CIP microcode releases described by this document.

Caution If you are upgrading from a previous Cisco IOS release, a special microcode installation procedure is required or your CIP will not operate properly. For details, refer to the section "CIP Microcode Upgrade Overview."

Introduction

This CIP microcode release note describes the CIP microcode modifications and caveats for the latest versions of CIP microcode. It includes all CIP microcode releases described in the section "CIP Microcode and CIP Hardware Compatibility." Also included is an overview of the procedures required to upgrade to the latest version of CIP microcode depending on the CIP-compatible router platform you have.

This CIP microcode release note discusses the following topics:

Cisco IOS Software and Cisco 7000 Family Hardware Documentation

For documentation of CIP features in the Cisco IOS 11.1 Release, refer to Table 1.

Cisco IOS Release 11.1 Publication	Customer Order Number
Configuration Fundamentals Configuration Guide	DOC-CFCG11.1=
Configuration Fundamentals Command Reference	DOC-CFCR11.1=
Bridging and IBM Networking Configuration Guide	DOC-IBMNCG11.1=
Bridging and IBM Networking Command Reference	DOC-IBMNCR11.1=
Cisco IOS Software Command Summary	DOC-CIOSCS11.1=
System Error Messages	DOC-SYSEM11.1=
Release Notes for Cisco IOS Release 11.1	78-2886-xx

Table 1: Cisco IOS Release 11.1 Publications

Cisco IOS Release 11.1 Publication Customer Order Number

Configuration Fundamentals Configuration Guide

DOC-CFCG11.1=

Configuration Fundamentals Command Reference

DOC-CFCR11.1=

Bridging and IBM Networking Configuration Guide

DOC-IBMNCG11.1=

Bridging and IBM Networking Command Reference

DOC-IBMNCR11.1=

Cisco IOS Software Command Summary

DOC-CIOSCS11.1=

System Error Messages

DOC-SYSEM11.1=

Release Notes for Cisco IOS Release 11.1

78-2886-xx

For documentation of CIP features in the Cisco IOS 11.2 Release, refer to Table 2.

Cisco IOS Release 11.2 Publication	Customer Order Number
Configuration Fundamentals Configuration Guide	DOC-CFCG11.2=
Configuration Fundamentals Command Reference	DOC-CFCR11.2=
Bridging and IBM Networking Configuration Guide	DOC-IBMNCG11.2=
Bridging and IBM Networking Command Reference	DOC-IBMNCR11.2=
Cisco IOS Software Command Summary	DOC-CIOSCS11.2=
System Error Messages	DOC-SYSEM11.2=
Release Notes for Cisco IOS Release 11.2	78-3648-xx

Table 2: Cisco IOS Release 11.2 Publications

Cisco IOS Release 11.2 Publication Customer Order Number

Configuration Fundamentals Configuration Guide

DOC-CFCG11.2=

Configuration Fundamentals Command Reference

DOC-CFCR11.2=

Bridging and IBM Networking Configuration Guide

DOC-IBMNCG11.2=

Bridging and IBM Networking Command Reference

DOC-IBMNCR11.2=

Cisco IOS Software Command Summary

DOC-CIOSCS11.2=

System Error Messages

DOC-SYSEM11.2=

Release Notes for Cisco IOS Release 11.2

78-3648-xx

For documentation of CIP features in the Cisco IOS Release 11.2BC, refer to Table 3.

Cisco IOS Release 11.2BC Publication	Customer Order Number
Release Notes for Cisco IOS Release 11.2	78-3648-xx
Release Notes for Cisco IOS Release 11.2BC	78-4694-xx
Feature Guide for Cisco IOS Release 11.2BC	78-4693-xx

Table 3: Cisco IOS Release 11.2BC Publications

Cisco IOS Release 11.2BC Publication Customer Order Number

Release Notes for Cisco IOS Release 11.2

78-3648-xx

Release Notes for Cisco IOS Release 11.2BC

78-4694-xx

Feature Guide for Cisco IOS Release 11.2BC

78-4693-xx

For documentation of CIP features in the Cisco IOS Release 11.3, refer to Table 4.

Cisco IOS 11.3 Release Publication	Customer Order Number
Configuration Fundamentals Configuration Guide	DOC-CFCG11.3=
Configuration Fundamentals Command Reference	DOC-CFCR11.3=
Bridging and IBM Networking Configuration Guide	DOC-IBMNCG11.3=
Bridging and IBM Networking Command Reference	DOC-IBMNCR11.3=
Cisco IOS Software Command Summary	DOC-CIOSCS11.3=
System Error Messages	DOC-SYSEM11.3=
Release Notes for Cisco IOS Release 11.3	78-4998-xx

Table 4: Cisco IOS Release 11.3 Publications

Cisco IOS 11.3 Release Publication Customer Order Number

Configuration Fundamentals Configuration Guide

DOC-CFCG11.3=

Configuration Fundamentals Command Reference

DOC-CFCR11.3=

Bridging and IBM Networking Configuration Guide

DOC-IBMNCG11.3=

Bridging and IBM Networking Command Reference

DOC-IBMNCR11.3=

Cisco IOS Software Command Summary

DOC-CIOSCS11.3=

System Error Messages

DOC-SYSEM11.3=

Release Notes for Cisco IOS Release 11.3

78-4998-xx

For documentation of CIP features in the Cisco IOS Release 11.3T, refer to Table 5.

Cisco IOS Release 11.3T Publication	Tracking Number
Release Notes for Cisco IOS Release 11.3	78-4998-xx
Release Notes for Cisco 7000 Family for Cisco IOS Release 11.3T	78-5015-xx
Cisco IOS Release 11.3T New Features	Available on CCO only

Table 5: Cisco IOS Release 11.3T Publications

Cisco IOS Release 11.3T Publication Tracking Number

Release Notes for Cisco IOS Release 11.3

78-4998-xx

Release Notes for Cisco 7000 Family for Cisco IOS Release 11.3T

78-5015-xx

Cisco IOS Release 11.3T New Features

Available on CCO only

For documentation of CIP features in the Cisco IOS Release 12.0, refer to Table 6.

Table 6: Cisco IOS Release 12.0 Publications

Cisco IOS Release 12.0 Publication Customer Order Number

Configuration Fundamentals Configuration Guide

DOC-785829=

Configuration Fundamentals Command Reference

DOC-785830=

Bridging and IBM Networking Configuration Guide

DOC-785850=

Bridging and IBM Networking Command Reference

DOC-785851=

Cisco IOS Software Command Summary

DOC-785859=

Cisco IOS Software System Error Messages

DOC-785860=

Debug Command Reference

DOC-785858=

Release Notes for Cisco IOS Release 12.0

78-6035-xx

Cisco IOS Release 12.0 Publication	Customer Order Number
Configuration Fundamentals Configuration Guide	DOC-785829=
Configuration Fundamentals Command Reference	DOC-785830=
Bridging and IBM Networking Configuration Guide	DOC-785850=
Bridging and IBM Networking Command Reference	DOC-785851=
Cisco IOS Software Command Summary	DOC-785859=
Cisco IOS Software System Error Messages	DOC-785860=
Debug Command Reference	DOC-785858=
Release Notes for Cisco IOS Release 12.0	78-6035-xx

For documentation of CIP features in the Cisco IOS Release 12.0T, refer to Table 7.

Cisco IOS Release 12.0T Publication	Tracking Number
Release Notes for Cisco IOS Release 12.0	78-6035-xx
Release Notes for Cisco 7000 Family for Cisco IOS Release 12.0T	78-6055-xx
Cisco IOS Release 12.0T New Features	Available on CCO only

Table 7: Cisco IOS Release 12.0T Publications

Cisco IOS Release 12.0T Publication Tracking Number

Release Notes for Cisco IOS Release 12.0

78-6035-xx

Release Notes for Cisco 7000 Family for Cisco IOS Release 12.0T

78-6055-xx

Cisco IOS Release 12.0T New Features

Available on CCO only

For documentation of CIP features in Cisco IOS Release 12.1, refer to Table 8.

Cisco IOS Release 12.1 Publication	Tracking Number
Cisco IOS Configuration Fundamentals Configuration Guide	DOC-7810222=
Cisco IOS Configuration Fundamentals Command Reference	DOC-7810223=
Cisco IOS Bridging and IBM Networking Configuration Guide	DOC-7810256=
Cisco IOS Bridging and IBM Networking Command Reference, Volume I	DOC-7810257=
Cisco IOS Bridging and IBM Networking Command Reference, Volume II	DOC-7810520=
Cisco IOS Command Summary	DOC-7810262=
Cisco IOS System Error Messages	DOC-7810263=
Cisco IOS Debug Command Reference	DOC-7810264=
Release Notes for Cisco IOS Release 12.1	78-10724-xx

Table 8:

Cisco IOS Release 12.1 Publication Tracking Number

Cisco IOS Configuration Fundamentals Configuration Guide

DOC-7810222=

Cisco IOS Configuration Fundamentals Command Reference

DOC-7810223=

Cisco IOS Bridging and IBM Networking Configuration Guide

DOC-7810256=

Cisco IOS Bridging and IBM Networking Command Reference, Volume I

DOC-7810257=

Cisco IOS Bridging and IBM Networking Command Reference, Volume II

DOC-7810520=

Cisco IOS Command Summary

DOC-7810262=

Cisco IOS System Error Messages

DOC-7810263=

Cisco IOS Debug Command Reference

DOC-7810264=

Release Notes for Cisco IOS Release 12.1

78-10724-xx

Cisco IOS Release 12.1 Publications

For documentation of CIP features in Cisco IOS Release 12.1T, refer to Table 9.

Cisco IOS Release 12.1T Publication	Tracking Number
Release Notes for Cisco IOS Release 12.1	78-10724-xx
Release Notes for Cisco 7000 Family for Cisco IOS Release 12.1T	78-10811-xx
Cisco IOS Release 12.1T New Features	Available on CCO only

Table 9:

Cisco IOS Release 12.1T Publication Tracking Number

Release Notes for Cisco IOS Release 12.1

78-10724-xx

Release Notes for Cisco 7000 Family for Cisco IOS Release 12.1T

78-10811-xx

Cisco IOS Release 12.1T New Features

Available on CCO only

Cisco IOS Release 12.1T Publications

For chassis-specific hardware configuration or troubleshooting information, refer to the following publications:

Cisco 7000 Hardware Installation and Maintenance (DOC-7000IM3)
Cisco 7010 Hardware Installation and Maintenance (DOC-7010IM2)
Cisco 7505 Hardware Installation and Maintenance (DOC-7505HIM1)
Cisco 7507 Hardware Installation and Maintenance (DOC-7507HIM1)
Cisco 7513 Hardware Installation and Maintenance (DOC-7513HIM1)

These hardware publications are available on Cisco Connection Online (CCO) in the Core/High-End Routers database.

How Does CIP Microcode Ship?

For the Cisco 7000 family routers (Cisco 7000 series routers and Cisco 7500 series), CIP microcode is available on Flash memory cards (which also include the Cisco IOS release compatible with the microcode version) and via CCO.

Starting with Cisco IOS Release 11.1, CIP microcode images are shipped separately from the Cisco IOS software. For Cisco 7000 family routers shipped with Cisco Release IOS 11.1 and later, the CIP microcode is shipped pre-installed on the Flash memory card. For Cisco IOS Release 11.1, 11.2, 11.2BC, 11.3, 11.3T, 12.0, 12.0T, 12.1, and 12.1T software upgrades, the CIP microcode is shipped or available on the following media:

Via electronic download from Cisco Connection Online using File Transfer Protocol (FTP) for all Cisco 7000 family routers
Pre-installed on a Flash memory card with Cisco IOS software (available as an upgrade for RP-based Cisco 7000 series routers only)

CIP Microcode and CIP Hardware Compatibility

In Cisco IOS Release 11.1(5) and later, two versions of the CIP card are supported. The initial CIP card is no longer produced. The CIP2 card replaces the CIP.

There are no microcode issues associated with this change. The Route Switch Processor (RSP) card in the Cisco 7000 family router automatically determines which version of the microcode is appropriate for the installed CIP or CIP2.

Cisco IOS Release 11.1(5) and CIP microcode Version 22.6 and Cisco IOS Release 11.2(2) and CIP microcode Version 22.7 support both a CIP and a CIP2 card in the same router. Prior to this release, different versions of a CIP card in the same router are not supported.

CIP Microcode/Cisco IOS Software Compatibility Matrix

Table 10 lists CIP microcode version and Cisco IOS software compatibility for the Cisco 7000 family. The CIP microcode image is shipped in a bundle separate from the Cisco IOS software images.

Note Starting with Cisco IOS Releases 10.3(9) and 11.0(5), the Cisco 7000 series routers and the Cisco 7500 series routers use the same CIP microcode image. The first version of integrated CIP microcode in Cisco IOS Release 10.3 is cip20-5, in Cisco IOS Release 11.0 it is cip21-3. Cisco IOS Release 11.1 and later use the integrated CIP microcode rather than a separate microcode version for each chassis and processor type.

Table 10: Unbundled CIP Microcode Releases and Corresponding Cisco IOS Releases for the Cisco 7000 Family

Default CIP Microcode Version Cisco IOS Release 11.1 Cisco IOS Release 11.2 Cisco IOS Release 11.2 BC Cisco IOS Release 11.3 Cisco IOS Release 11.3T Cisco IOS Release 12.0 Cisco IOS Release 12.0T Cisco IOS Release 12.1 Cisco IOS Release 12.1T

21-3

11.1(1)

22-0

11.1(1)

22-3

11.1(3)

22-6

11.1(5)

22-7

11.1(6)

22-10

11.1(7)

11.2(1), 11.2(2)

22-12

11.1(8)

11.2(3), 11.2(4)

22-14

11.1(9)

22-15

11.1(10)

22-17

11.2(5)

22-18

11.1(11)

22-19

11.2(6)

22-20

11.1 (12)

11.2(7)

22-21

11.1 (13)

11.2(8)

22-22

11.1(14)

11.2(9)

22-23

11.1(15)

22-25

11.1(16)

11.2(10)

22-26

11.1(17)

11.2(11)

22-27

11.1(18)

11.2(12), 11.2(13)

22-30

11.1(20)

11.2(14)

22-31

11.2(15)

22-32

11.1(22)

11.2(16)

22-34

11.1(24)

11.2(17)

22-35

11.2(18)

22-38

11.2(19)

22-39

11.2(20)

22-40

11.2(21)

22-41

11.2(22)

22-43

11.2(23)

24-0

11.2(8) BC

24-1

11.2(9) BC

24-2

11.2(10) BC

24-3

11.2(11) BC

24-4

11.2(12) BC

24-5

11.2(13) BC

24-6

11.2(14) BC

24-7

11.2(15) BC

24-8

11.2(16) BC

24-9

11.2(17) BC

24-11

11.2(18) BC

24-13

11.2(19) BC

24-14

11.2(20) BC

24-15

11.2(21) BC

24-16

11.2(22) BC

24-18

11.2(23) BC

25-3

11.3(1)

25-6

11.3(2)

25-7

11.3(3), 11.3(4)

25-8

11.3(5), 11.3(6)

25-9

11.3(7)

25-10

11.3(8)

25-11

11.3(9)

25-12

11.3(10)

25-13

11.3(11)

26-0

11.3(3)T

26-1

11.3(4)T

26-2

11.3(5)T, 11.3(6)T,

26-4

11.3(7)T

12.0(1), 12.0(2)

12.0(1)T, 12.0(2)T

26-5

11.3(8)T

12.0(3)

26-7

11.3(9)T

12.0(4)

26-8

11.3(10)T, 11.3(11)T

12.0(5)

26-9

12.0(6), 12.0(7)

26-10

12.0(8)

26-11

12.0(9)

26-12

12.0(10)

26-13

12.0(11)

26-15

12.0(12)

27-0

12.0(3)T

27-1

12.0(4)T

27-2

12.0(5)T

27-4

12.0(7)T

27-6

12.1(1)

12.1(1)T

27-7

12.1(2)

12.1(2)T

27-8

12.1(3)

12.1(3)T

Note For Cisco IOS Release 11.2BC, the CIP card is supported only on the Cisco 7000 with RSP7000 and the Cisco 7500 series routers.

CIP Microcode Release cip27 Caveats and Modifications

The following section describes the caveats to current CIP microcode versions and the modifications made in current CIP microcode versions for cip27 microcode. The caveats listed apply to only the most serious problems. See Table 10 for the Cisco IOS software releases supported by cip27 microcode.

Caveats for Version 27.8/Version 27.9 Modifications

This section describes possible unexpected behavior by Version 27.8. All the caveats listed in this section are resolved in Version 27.9. See Table 10 for the Cisco IOS software release that corresponds to the 27.9 microcode version.

The TN3270 server disconnects the session. This occurs when a client connects to a dynamic LU that has received a DACTLU message. The TN3270 server requests an ACTLU response and starts a two-minute timer. A timer value of this length is invalid because the LU has been deactivated by the VTAM console operators. The TN3270 server does not receive the ACTLU response within the timer period and disconnects the session.

: The workaround is to configure the TN3270 server to assign a different LU. [CSCdk30136]

Users are unable to start new CMCC sessions. The results of a show extended channel x/2 tn command show that some PUs are in an ACT/Busy state. The results of a VTAM display of the PU show that the PU is in an active state.

: The workaround is to reload the microcode. [CSCdm44279]

When a parallel link that connects a Cisco TN3270 server to another server and carries the control point-to-control point sessions goes down, the Cisco TN3270 cannot establish a control point-to-control point session with any server.

: The workaround is to define alternate links to the same VTAM host only at the host end, or avoid multiple links to the same VTAM host. [CSCdp02702]

The CMCC adapter fails with a fatal error message number 9.

CIP2-3-MSG: slot0 %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../ssi/ssi_buff.c @ 1035 - msgP->m_next
Jan 31 15:40:12: %CIP2-0-MSG: slot0 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: There is no workaround. [CSCdp84989]

VTAM issues a V NET,INACT,TYPE=GIVEBACK message. The control point-to-control point session moves to the other DLUS, but the DLUR pipe stops and restarts on the same host.

: There is no workaround. [CSCdr28173]

The last logical PU in an IP pool of listen points is placed into the WAIT state. This problem occurs when changing the TCP-port while PUs are in an ACTIVE state.

: The workaround is to shutdown and restart the TN3270 server using the shutdown command. [CSCdr30174]

TN3270 server LUs can not be used. This problem occurs when the TN3270 server does not clear the indication that LUs were nailed during processing and delete the nailing definition.

: The workaround is to avoid manipulating nailing definitions without issuing the microcode reload command. [CSCdr32205]

The Offload socket response on the transaction processing facility (TPF) is delayed by 10 seconds or more. This problem occurs when there is a lack of MEMD buffers on the channel interface on the Cisco 7500 series router for a prolonged length of time. This applies to the CIP, only.

: There is no workaround. [CSCdr33661]

The TN3270 server inconsistently names the TN3270E clients. Sometimes the name is a fully-qualified APPN name such as NETA.BTEST001. At other times the name is the local LU name, such as BTEST001.

: There is no workaround. [CSCdr38323]

The TN3270 server uses an incorrect default value of 30 minutes for the max response time for the keepalive timer. This problem occurs if the keepalive command is configured without specifying any values for the nop or timing-mark or max-response-time parameters.

: The workaround is to configure the nop or timing-mark parameters. [CSCdr59806]

Caveats for Version 27.7/Version 27.8 Modifications

This section describes possible unexpected behavior by Version 27.7. All the caveats listed in this section are resolved in Version 27.8. See Table 10 for the Cisco IOS software release that corresponds to the 27.8 microcode version.

The TN3270 server loses pool-based LU nailing information. This problem occurs when the no shutdown command is configured multiple times on the same PU.

: The workaround for customers who are using pool-based LU nailing is to avoid configuring the no shut command multiple times on the same PU. [CSCdm24372]

A user receives another user's session when both users are logged into the same applications owning region (AOR) in the Customer Information Control System and that AOR is manually cancelled.

: The workaround is to not disconnect a client during the logon process; that is, after requesting an application from the SSCP screen, but before establishing the LU-LU session with that application. [CSCdm51110]

The following message appears on the CMCC console:

: bad error-code 12 given
: This valid error code indicates a missing TERMSELF response. The code to log and format this specific error into a console message is missing.
: There is no workaround. [CSCdm55961]

The CMCC adapter fails with error message number 32. This problem occurs when the TN3270 server is configured and is using, or has used, the TN3270 monitor or a similar product.

: The workaround is to not configure the TN3270 monitor or a similar product. [CSCdp16086]

The CMCC adapter fails with fatal error message number 35. This problem occurs when the no client ip ipaddr [ipmask] pool poolname command is configured when using LU pooling. The command configuration causes memory corruption and the CMCC failure. The failure usually occurs because the TN3270 server attempts to access ODD addresses when EVEN addresses are expected.

: There is no workaround. [CSCdp18803]

The TN3270 server disconnects a TCP session after sending an "in use" message. This problem occurs when OpenConnect clients are configured to negotiate multiple LU names by using a device list used by the client.

: The workaround is to configure the OpenConnect client to use a single device name. [CSCdp24684]

The TN3270 server show pu command output is missing LU states. The missing states are displayed as P-RESET. This applies also to the LU state objects in the TN3270 server MIB.

: There is no workaround. [CSCdp51038]

The CMCC adapter fails with fatal error message number 32. This problem occurs when approximately 25 or more DLUR links are configured. The reply buffer is too small to contain all of the Cross Domain Init vectors and the positive locate reply.

: The workaround is to configure fewer DLUR links. [CSCdp79125]

The CMCC adapter may fail when the shutdown command is configured in TN3270 sub-mode.

: There is no workaround. [CSCdp99538]

The CMCC adapter configured for CSNA may not respond to a test poll. This problem occurs because there is a miscount of the available IBM VTAM External Communications Adapter (XCA) resources. Typically an XCA autogen parameter is configured to automatically generate lines and PUs. This is not required for PU5-to-PU4 or PU5-to-PU5 communications.

: The workaround is to recycle the XCA major node. [CSCdr03103]

The TN3270 Server running on TPF returns the following error message:

Offload time out

: This problem occurs when the client establishes a connection to the server, issues a request, gets the response and then closes the connection by sending a RST (reset) segment.
: The server issues a read to the connection, the read message is blocked and returns with the error message. The read message should return with a 0 message, meaning that the connection was closed. This problem happens after one minute.
: There is no workaround. [CSCdr05011]

The LU number in the show extended channel tn3270-server command output decreases every time a client fails to telnet. Once the LU number reaches zero, clients cannot telnet to the TN3270 server although LUs are available.

: There is no workaround. [CSCdr09662]

Unless the Definite Response option is set in the request/response unit (RU) from the host, nothing which can measure IP response time is sent to the client. This problem applies to response times obtained from the TN3270E-RT-MIB, or by using the TN3270 server show commands.

: The workaround is to use only Definite Response flows. [CSCdr10939]

The TN3270 server allows a client to access LUs which are nailed to another subnet.

: There is no workaround. [CSCdr12567]

The CMCC adapter fails with the following error message:

%ECPA-4-MSG: slotx %TN3270S-4-NO_LU_SESSIONS
: No LU sessions left in :GENERIC for PUs at IP addr xxx.xxx.xxx.xxx, port 23

: The TN3270 server PU output displays skipped LUs. The TN3270 server does not select these LUs. All other LUs are set to ACT/SESS. Note that there is no LU display for lu4 and lu9.

lu    name   client-ip:tcp       nail   state    model frames in out   idle for
1   ABCD2001 xxx.xxx.xxx.x:1042    N   ACT/SESS 3278S5E  38418   19615   0:6:6
2   ABCD2002 xxx.xxx.xxx.xxx:1043  N   ACT/SESS 3278S2E  21473   14085   0:18:11
3   ABCD2003 xxx.xxx.xxx.xx:1665   N   ACT/SESS 3278S5E  9992    6147    0:0:6
5   ABCD2005 xxx.xxx.xxx.x:1046    N   ACT/SESS 3278S5E  12731   8074    10:33:7
6   ABCD2006 xxx.xxx.xxx.x:4033    N   ACT/SESS 3278S2E  31367   18838   2:0:51
7   ABCD2007 xxx.xxx.xxx.x:1045    N   ACT/SESS 3278S5E  8184    4413    2:55:4
8   ABCD2008 xxx.xxx.xxx.xx:1323   N   ACT/SESS 3278S2E  16274   7580    4:28:19
10  ABCD200A xxx.xxx.xxx.xxx:1205  N   ACT/SESS 3278S2E  7752    4175    1:3:39

: The workaround is to add more PUs to the TN3270 server and VTAM configuration. [CSCdr13016]

The TN3270E client cannot connect when it specifies PAC04 as the LU. This problem occurs when a direct PU is named PAC and an LU seed is named PAC##. Incorrect LU names such as PAC001, PAC002,... PAC255 (note decimal locaddrs) are generated. The PAC04 name is not found and the connection is refused.

: The workaround is for the TN3270E client to specify PAC004 instead of PAC04. [CSCdr13524]

The CMCC adapter fails with the following fatal error message number 35:

%CTA-0-INACTIVE: PA1 CTA 7C00-50 reset after being inactive for 180 seconds

: The workaround is to shutdown the CSNA subchannel before shutting down VTAM. [CSCdr13804]

The LU-available number in the show extended channel tn3270 command output is incremented on inactive PUs when adding nailing configuration commands.

: The workaround is to ignore or activate the PU to correct the lu-available number. [CSCdr17334]

The TN3270 server improperly releases nodes which had not been deleted from the resource AVL tree. This problem occurs when the TN3270 server is restarted by configuring the shutdown and no shutdown TN3270 commands.

: A workaround is to avoid restarting the TN3270 server when there is a heavy processing load. [CSCdr18250]

The CMCC adapter fails with fatal error message number 35. This problem occurs when the no listen-point TN3270 server command is configured.

: There is no workaround. [CSCdr19257]

The CMCC adapter fails with fatal error message number 7. This problem occurs when the client disconnects after the response time group is removed from the configuration. This occurs when the response time group and the subnet are configured.

: The workaround is to remove the response time group configuration. [CSCdr20842]

When using the TN3270 server monitor or a similar product such as SOLVE:Netmaster for TCP/IP, the length of the message fragment field is reported incorrectly. The field length is reported as "18". It should be reported as "20". The message fragment field is defined as follows:

  struct {short PACKED(pktLength); short PACKED(len); 
          unsigned char PACKED(bytes[16]);}

: This is a cosmetic failure and is present in all CIP and CPA microcode releases.
: There is no workaround. [CSCdr24412]

VTAM issues a V NET,INACT,TYPE=GIVEBACK message. The control point-to-control point session moves to the other DLUS, but the DLUR pipe stops and restarts on the same host.

: There is no workaround. [CSCdr28173]

Caveats for Version 27.6/Version 27.7 Modifications

This section describes possible unexpected behavior by Version 27.6. All the caveats listed in this section are resolved in Version 27.7. See Table 10 for the Cisco IOS software release that corresponds to the 27.7 microcode version.

At show ext cn/2 pu/lu, some dddlu LU names appear blank if Host applications send NULL slu data in the bind.

: There is no workaround. [CSCdj90734]

Users are unable to start new CMCC sessions. The results of a show extended channel x/2 tn command show that some PUs are in an ACT/Busy state. The results of a VTAM display of the PU show that the PU is in an active state.

: The workaround is to reload the microcode. [CSCdm44279]

A Cisco Multipath Channel (CMPC) transmission group (TG) does not activate and the following duplicate group token message is returned:

: Get CMPCP_DUPL_TOKEN:
: This problem occurs when bringing up a TG from the host that is activating a transport resource list entry (TRLE) and when multiple TGs are configured with paths to multiple mainframes via a director.
: The workaround is to activate the TRLE again. [CSCdp66330]

The CMCC adapter fails with fatal error message number 32. This problem occurs when approximately 25 or more DLUR links are configured. The reply buffer is too small to contain all of the Cross Domain Init vectors and the positive locate reply.

: The workaround is to configure fewer DLUR links. [CSCdp79125]

The CMCC adapter running CIP Offload returns the following error message:

: %CIP2-4-MSG: slot0 %OFFL-4-BADDESC: 0/9300/60 Socket descriptor 259 in request is bad: state DESC_Holddown compare 259
: This is a cosmetic problem that should not impact performance.
: There is no workaround. [CSCdp84965]

The CMCC adapter running CIP Offload reloads with fatal error message number 35. This problem occurs when too many Offload and CLAW statements are configured on the same interface. The process table is shared by two interfaces and can not exceed 530 processes. Each Offload uses 4 processes. Each CLAW uses 2 processes. There are about 20 to 30 processes that are always running in addition to any Offload or CLAW configurations.

: The workaround is to configure fewer Offload and CLAW statements. [CSCdp85560]

The CMCC adapter fails with fatal error message number 32. This problem occurs when changing the IP address of a loopback interface.

: There is no workaround. [CSCdp85890]

There is a 10-second delay from the time that the host application sends a SHUTDOWN message until the TN3270 server responds with the SHUTC RU message. This delay applies to printer emulators and should not apply to screen devices.

: There is no workaround. [CSCdp90214]

A CMCC adapter error occurs when host-defined LU names for one PU conflict with implicit lu-seed derived names on another PU.

: The workaround is to avoid name conflicts by specifying lu-seed names on every PU in the configuration that do not overlap with the host-defined names. [CSCdr06007]

The TN3270 Server LU goes into P-RESET mode. This problem occurs when the server closes a client connection that is using a static LU due to an inactivity or keepalive timeout. The server sends an unbind message to the host and then waits 6 seconds before sending a Notify/Unavailable message. If the same client attempts to reconnect within that time window and the System Service Control Point (SSCP) logon screen is received after the reconnect, but still within that window, the TN3270 Server locks up. This problem occurs because the accepted SSCP screen stops the timer that would normally send in the Notify/Unavailable message. Also, the SSCP logon screen will be rejected with an 0x0831 sense code.

: The workaround is to reject any connect requests for that LU until the Notify/Unavailable message transmission is complete. [CSCdp66402]

The LU termination setting is incorrect in SNA-NAU-MIB. The snaLuAdminTerm and snaLuOperTerm objects are set to unbind even if termself is configured.

: There is no workaround. [CSCdp88662]

Caveats for Version 27.5/Version 27.6 Modifications

This section describes possible unexpected behavior by Version 27.5. All the caveats listed in this section are resolved in Version 27.6. See Table 10 for the Cisco IOS software release that corresponds to the 27.6 microcode version.

BADTIMER messages appear when running TN3270 Server. In this case, the messages appear because a TN3270 session is being negotiated or recently has been negotiated. The messages do not impact normal TN3270 Server operations.

: There is no workaround. [CSCdk21633]

The CMCC Adapter fails with error message 37. The following error messages appear:

%CONFIG-3-WORKLEFT:Work pending on work queue when device terminated 
%DEBUGGER-0-FATAL_ERROR:Fatal error (code=37)

: There is no workaround. [CSCp54593]

The tn-parameter code codevalue command incorporates a code value of 3. PUs configured on the TN3270 Server request activation by sending ReqACTPU (DLUR PUs) or TEST/XID (Direct PUs) messages to the host. When the TN3270 Server and its PUs are in backup or standby mode, the PUs should not request activation. The PUs must wait to be activated by the host.

: To enable this passive activation, enter the tn-parameter code codevalue command with a code value of 3. This command tells the Server to put all PUs in a waiting state and not to send ReqACTPU or TEST/XID messages to the host. [CSCdm80770]

In duplicate MAC environments, idle Systems Application Architecture (SAA) gateway sessions terminate. SAA gateways time out the route to the CMCC MAC address and send receive ready poll (RR(P)) single route explorer (SRE) messages to rediscover the route. The CMCC Adapter is not in session and responds to the RR(P) messages with a disconnect mode final (DM(F)) message. The SAA gateway then disconnects the session. The RR(P) SRE is contrary to the LLC2 specifications.

: The workaround is to specify XTX=7 on the route.nlm. [CSCdp09295]

The CMCC adapter fails with the following message:

%CIP2-3-MSG: slot0 %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta802/ciptask.c @ 322 - !mxcb->mx_next
%CIP2-0-MSG: slot0 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: The assertion is intended to detect messages with 15 or more memory buffers (mbufs). There is no workaround. [CSCdp13245]

The CMCC Adapter fails when running CSNA. This problem occurs while processing the detection of idle subchannel conditions.

: The workaround is to avoid creating idle subchannel conditions by not using the Z NET cancel command. Other possible workarounds include shutting down the router channel interface or removing the CSNA configuration statement before issuing the Z NET cancel command. [CSCdp31175]

The CMCC Adapter deletes all the PUs associated with IP pool and fails with error message 35. This problem occurs when a listen-point PU and another non-listen-point PU are configured with the same IP address and TCP port pair and the no listen command is issued. PUs that are not configured under the listen-point are deleted.

: The workaround is to not configure a listen-point PU and another PU with the same IP address and TCP port pair. [CSCdp45166]

CMCC Adapter configuration errors occur when the CIP microcode is upgraded from version cip24-14 to cip24-15. The following error message occurs when attempting to delete an allocate LU pool statement:

dec 20 05:48:57 UTC: %CBUS-3-CIPCFGFAIL: Channel0/2: configuration command TN3270S_LISTEN_POINT_PU_LU_POOL  cmd 40 failed

: There is no workaround. [CSCdp56576]

The CMCC Adapter fails with error message 35 when the TN3270 Server is shut down. This problem occurs when using CIP microcode version cip24-15 or later.

: There is no workaround. [CSCdp58083]

When the TN3270 Server statistics are displayed, a negative LU IN USE message appears. This is a cosmetic problem. LUs are still available to the clients as needed.

: There is no workaround. [CSCdp69064]

When an online insertion and removal (OIR) of an IP card is performed on a Cisco 7500 series router with a CIP, the following error messages are displayed:

*Jan 18 00:56:35: %OIR-6-REMCARD: Card removed from slot 1, interfaces disabled
*Jan 18 00:56:40: %CIP2-6-MSG: slot5 %SYSMGT_RPC-6-STATE_CHANGE: System 
Management activated
*Jan 18 00:56:47: %CIP2-3-MSG: slot5 %LOVE-3-LOVELETTER: Error in love 
letter processing for port 0(0)

: There is no workaround. [CSCdp75240]

The TN3270 Server LU Nailing feature fails in a subnetted IP address scheme. This problem occurs because the client addresses are not recognized.

: The workaround is to configure the tn-parameter code codevalue command with a code value of 9. This workaround applies only if the client is capable of requesting a specific LU name. If the client does not specify an LU name, then an LU will be awarded based on the LU Nailing rules configured. [CSCdp58041]

Caveats for Version 27.4/Version 27.5 Modifications

This section describes possible unexpected behavior by Version 27.4. All the caveats listed in this section are resolved in Version 27.5. See Table 10 for the Cisco IOS software release that corresponds to the 27.5 microcode version.

BADTIMER messages appear when running TN3270 Server. In this case, the messages appear because a TN3270 session is being negotiated or recently has been negotiated. The messages do not impact normal TN3270 Server operations.

: There is no workaround. [CSCdk21633]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The TN3270 Server configured for a direct, non-APPN connection sets the parallel transmission group (TG) supported bit on xid3 to byte = 15(bit 0 of XID3).

: This setting is incorrect for a LEN node direct connect configuration and causes connection failure problems when connecting to the SNA Switch. The SNA Switch expects the device to negotiate a TG number, but the TN3270 Server does not support this action. The TN3270 Server must either negotiate a TG number or not configure a TG-capable bit setting.
: The workaround is to configure the snasw port command with the conntype len keyword specified on the SNA Switch port to which the TN3270 Server connects. The TN3270 Server will no longer set the parallel TGs supported bit during the XID exchange for direct PUs. [CSCdm71315]

The user is unable to acquire specific LUs when using TN3270E clients. This error occurs intermittently on one of the several configured PUs. This error occurs when the customer is running direct-connect PUs (no DLUR) and does not have the INCLUD0E=YES parameter set on the switched major node. This error occurs in CIP microcode version cip210-140, but the affected PUs do not have LU pools defined.

: There is no workaround. [CSCdm73361]

Data is lost on printer emulators. This problem occurs when the user is running TN3270 Server in an environment with small (768) RU sizes and low pacing values. The printer receives the first RU of data, but intermittently fails to receive the second. The TN3270 Server received an EXPEDITED SHUTD command prior to receiving the last-in-chain RU. The shutdown process causes loss of data.

: This fix adds a 10 second delay between receiving the shutdown command and responding to the shutdown command. This time window will allow any data that is in queue to transmit before the shutdown procedure.
: There is no workaround. [CSCdm80945]

CSNA devices fail with INOP messages during Interface Control Check (IFCC) status. This problem occurs when CLAW and CSNA are operating in high traffic conditions. It can occur in CMPC and CSNA, also.

: The workaround is to upgrade the CMCC microcode or to restart the external communication adapter (XCA) nodes. [CSCdm88239]

A BIND REQUEST or SSCP-LU message is expected but not received from the host within 30 seconds from the start of an SSCP-LU session for the CMCC Adapter TN3270 server session. If the condition continues for another 2 minutes, the LU is declared bad and the following error message appears:

%TN3270S-1-NO_BIND_REQ_RCVD: No BIND REQ received on LU [chars].[dec], 120*ONESEC

: This error and several others are logged as priority 1 (alert) messages in error reports. The priority level of the following error messages is now priority level 3:

NO_PSID_RSP_RCVD
NO_NTFY_AV_RSP_RCVD
NO_BIND_REQ_RCVD
NO_SDT_REQ_RCVD
NO_SDT_TMARK_RCVD
NO_UNBIND_TMARK_RCVD
NO_NTFY_UA_RSP_RCVD
NO_DYN_ACTLU_REQ_RCVD
NO_UNBIND_RSP_RCVD 
NO_TERMSELF_RSP_RCVD

: [CSCdm94788]

Support is added for the TCP/IP information vector (CV64). The CV64 carries TN3270 Server clients IP address, TCP port number, and optionally the DNS name. The CV64 is sent inbound along with the NOTIFY(enable) and RSP(ACTLU) messages.

: VTAM indicates whether it can receive the CV64 by setting a bit in the PU Capabilities vector (CV80) in the outbound ACTPU Request message. For DLUR PUs with all static LUs, the VTAM may not send the CV80 and the TN3270 Server will not send the CV64.
: If the parameter INCLUD0E=YES is coded for this PU in the switched major node, the VTAM will send CV80 and enable the TN3270 Server to send the CV64. [CSCdp06211]

The TN3270 Server client fails when configuring printer LUs. This problem occurs when the two LU definitions required to configure the printer are set. One LU is nailed with the client IP address and the other is nailed with the client IP address of the printer. The TN2370 Server allocates the video client to the printer LU and then neither client works. This problem occurs in CIP microcode versions cip24-10 through cip24-13 and later.

: There is no workaround. [CSCdp06760]

The TN3270 Server or TN3270E client fails when it connects to the server, but does not specify the name of an LU to be obtained. This problem occurs in CIP microcode version cip24-14 and later when a combination of DDDLU and nailed LUs are used.

: The workaround is to code an lu-seed in the router on the PU, then connect to a TN3270E client configured with the correct LU name. [CSCdp09708]

When an ICMP Host Unreachable packet is received by the TCP stack, it generates several soft errors before the error becomes permanent. The Offload select() returns readable to the soft errors. [CSCdp18373]
The CMCC adapter with TN3270 Server configured fails with fatal error message 35. This problem occurs when attempting to clear the TN3270 configuration from the router. After entering the no tn3270-server command while in configuration mode on the virtual channel interface, the microcode reloads and all the interfaces flap. The CSNA devices are removed from the running configuration and must be reconfigured.

: There is no workaround. [CSCdp24670]

The printer emulators receive an -RSP sense 2005 message. The problem is caused by an emulator that sends data to the host after the BIND, but before the Start Data Traffic (SDT) processing is complete. This data is rejected from the host and the following -RSP sense 2005 message appears:

J+FKP4390E UNEXPECTED DATA RECEIVED.QUE.HELD.LU="LUname"

: There is no workaround. [CSCdp30854]

The CMCC Adapter fails when running CSNA. This problem occurs while processing the detection of idle subchannel conditions.

: The workaround is to avoid creating idle subchannel conditions by not using the Z NET cancel command. Other possible workarounds include shutting down the router channel interface or removing the CSNA configuration statement before issuing the Z NET cancel command. [CSCdp31175]

The CLAW control link does not establish. This problem most likely occurs on a TPF system or on an IBM TCP/IP system. The problem occurs because the timing of the Halt Subchannel message related to the Start Subchannel message is off.

: The workaround is to stop and restart the CLAW driver causing the CLAW control link to synchronize again. [CSCdp32675]

The CMCC Adapter fails with error message 35. This problem occurs when adding a second TN3270 Server PU under the DLUR and when the CMCC Adapter is offline.

: There is no workaround. [CSCdp43223]

A print server with 10 LUs fails to get 10 TNET connections with the TN3270 Server. The tenth LU client receives a FIN message from the TN3270 Server. The TN3270 Server rejects the TNET message indicating Listen Closed on the PU. Additional attempts to connect to the tenth LU fail until the LU is reactivated or another LU is disconnected. The problem only occurs when the last ACTLU static LU is obtained by a client. It is standard practice for the TN3270 Server to close the listen vector at this time; however, it should not close any connections that are being negotiated and have obtained LUs.

: The workaround is to add an additional 3 LUs to the VTAM switched major node, leaving the print server to request only 10 TNET connections. [CSCdp43253]

The CMCC Adapter calculates a set buffer address (SBA) that is above the screen size. This problem occurs when connecting a 327802 client using a 3270 datastream. This causes the connected session to hang on the MSG0 screen.

: The workaround is to code the LUGROUP parameter with one of the following values: SSCPFM=USS3270 or SSCPFM=USS3270. [CSCdp46564]

The CMCC Adapter configured for TCP/IP Offload fails with a error message 35. This problem occurs after a %MBUF-0-MFREEx2 message error. The problem occurs in rare circumstances when a socket request close() is issued on a TCP/IP server socket which has an outstanding accept() socket response on a BLOCKING socket. This problem also occurs in the same circumstances on a CMCC Adapter configured for TPF Offload.

: There is no workaround. [CSCdp47885]

The CMCC Adapter fails with error message 35. This problem occurs when the no client ip command is issued in listen point submode.

: There is no workaround. [CSCdp55519]

The TN3270 Server client does not connect when requesting a resource by name. This problem occurs because the ACTLU improperly truncates the LU name. This problem effects all DLUR configurations and direct-connect configurations when INCLUD0E is specified in the Switched Major Node definitions.

: There is no workaround. [CSCdp34029]

Caveats for Version 27.3/Version 27.4 Modifications

This section describes possible unexpected behavior by Version 27.3. All the caveats listed in this section are resolved in Version 27.4. See Table 10 for the Cisco IOS software release that corresponds to the 27.4 microcode version.

OpenConnect has an informal extension to the Termtype in TN3270. When connecting through an OpenConnect TN3270 gateway, the client IP address is concatenated on the end with a percent (%) symbol.

: The CMCC TN3270 Server does not use this client IP address for matching on LU nailing statements in the configuration. [CSCdj44584]

MSG10 data from one LU might be seen on an LU already in session. This problem occurs when the TN3270 server remote MAC address resides on a different physical adapter or in a different physical machine, such as a front-end processor (FEP).

: The workaround is to make sure that the RMAC TN3270 server PU resides on the same CMCC adapter as the TN3270 Server. [CSCdm01837]

In a duplicate MAC environment, the CIP will continue to respond to a TEST command when the lines configured for the XCA are in use. This problem prevents other duplicate MAC adapters from responding to new requests.

: The workaround is to configure the maximum LLC or threshold to equal the number of XCA lines configured. [CSCdm29597]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The CMCC displays a RSP sense 089F0004 message when processing a REQACTPU message. The problem occurs when the VARY command is entered for DLUR PUs that have multiple PATH statements. The problem occurs because the DLUR sends a message to the DLUS containing an FQPCID value which DLUS created on an earlier acquisition of the PU. The host processes the FQPCID message as invalid.

: The workaround is to remove the PATH statements. [CSCdm42103]

Users are unable to start new CMCC sessions. The results of a show extended channel x/2 tn command show that some PUs are in an ACT/Busy state. The results of a VTAM display of the PU show that the PU is in an active state.

: The workaround is to reload the microcode. [CSCdm44279]

A user receives another user's session when both users are logged into the same applications owning region (AOR) in the Customer Information Control System and that AOR is manually cancelled.

: The workaround is to not disconnect a client during the logon process; that is, after requesting an application from the SSCP screen, but before establishing the LU-LU session with that application. [CSCdm51110]

The CMCC adapter fails with fatal error code 35 during the TN3270 Server shutdown. This problem occurs because the TN3270 Server PUs are not communicating with the host.

: A workaround is available. Contact the Cisco TN3270 Server development engineers for the interim fix. [CSCdm61159]

The TN3270 Server running DLUR/DLUS fails with fatal error message code 35. This problem occurs because the TN3270 Server tries to invoke a SendACTLURSP using a NULL object reference.

: This fix adds a debug message to the log and marks the ACTLU as not processed.
: There is no workaround. [CSCdm69186]

The DLUR pipe between VTAM and the CMCC adapter hangs. This problem occurs when a large number of TN3270 Server TCP/IP requests (1000 per CMCC adapter) arrive at the same time.

: The workaround is to space out the TCP/IP requests. [CSCdm75120]

When the CMCC adapter is configured with a large number of offload sessions, the following error message occurs:

%CIP2-3-MSG: slot0 %OFFL-3-NOMEM2: Not enough memory to process socket requests,              0 open, 0 in holddown

: The workaround is to increase memory. [CSCdm76552]

The TN3270 Server fails with the following error message:

%DEBUGGER-0-FATAL_ERROR: Fatal error (code=35)

: This error occurs when the TN3270 Server is shut down while traffic is still transmitting. [CSCdm78261]

The unbind/bind sequence in the response time logic during a transaction does not reset the sample. This error causes an invalid response time which might be extremely large, depending upon the timing of the transaction. This problem occurs when the unbind keep is configured when the next transaction completes.

: There is no workaround. [CSCdm82521]

A select() message does not respond or times out when the peer closes the connection. This problem is more likely to occur when using TPF.

: The workaround is to delay the shutdown for 20 ms after the last send() message. [CSCdm85311]

The TN3270 IND$FILE file transfer performs poorly if the RU size is smaller than the maximum transmission unit (MTU). This problem occurs because the Cisco TN3270 Server uses the Nagle algorithm by default.

: The workaround is to set the RU size so that it is at least as big as the MTU on the file transfer path. [CSCdm86734]

The TN3270 Server overwrites 1 byte of a Read Partition Query (RPQ) response. The overwrite occurs because of a logic that was entered to capture a non-standard SYSREQ key sequence for non-TN3270E emulators.

: There is no workaround. [CSCdm88195]

A TPF receive message fails to retrieve all the data. The problem occurs when the TPF client performs a shutdown-writing and then tries to receive the data.

: The workaround is to not perform the shutdown-writing. [CSCdm92713]

A CMCC file transfer hangs or the keyboard stops working. The problem occurs when the IND$FILE uses structured fields and buffers that are 2000 bytes or greater. The keyboard is restored using the TN3270 write command instead of the structured field.

: The workaround is to use buffers that are 2000 bytes or less or non-structured fields (presentation space transfer. To enable the fix in CMCC releases cip27-4 and greater and xcpa27-4 and greater, you must configure the TN3270 tn-parameter code codevalue command with a code value of 7. [CSCdm93990]

The VTAM to VTAM communication for APPN and FID2 hangs. The non-LLC2 HPR traffic does not hang. This problem occurs when both VTAMs are attached to the CIP running the CMPC feature.

: There is no workaround. [CSCdp00921]

The CMCC displays the following error message:

slot0:Fix this

: This error will not cause any serious problems.
: There is no workaround. [CSCdp04360]

A 4-to-5 second delay occurs between the CMCC connection to the server and the USSMSG10 screen display. This problem occurs only in CMCC trains cip24-x, cip27-x, and xcpa27-x.

: There is no workaround. [CSCdp06877]

The CMCC fails with error message 35. The problem occurs when the TN3270 Server is using the LU Nailing feature with the older PU definition for the nailed LUs instead of the LU Pooling definition in CMCC branches cip24-x, cip27-x, and xcpa27-x. The following example shows the old PU without the LU Pooling definition:

  pu CISCO    04921002 157.2.196.101   token-adapter 31 24 rmac 4000.7206.0001
  client ip 157.2.0.0 255.255.255.0 lu 4 20

: The problem occurs when the client ip or no tn3270 server command is entered. The problem also can occur when the interface is shut down.
: There is no workaround. [CSCdp07729]

A TCP/IP Offload select() for readability message indicates that there are no readable sockets in the descriptor list when in fact there are readable sockets available. This problem occurs when the TCP/IP connection fails while a select() for readability message is outstanding on the socket.

: There is no workaround. [CSCdp08103]

Caveats for Version 27.2/Version 27.3 Modifications

This section describes possible unexpected behavior by Version 27.2. All the caveats listed in this section are resolved in Version 27.3. See Table 10 for the Cisco IOS software release that corresponds to the 27.3 microcode version.

The TN3270 Server session disconnects after 150 seconds when the LOGON APPLID is not entered. In this case, there is no unformatted system services table (USSTAB).

: There is no workaround. [CSCdk83774]

Adding and removing PUs configured in TN3270 DLUR causes the CMCC adapter to reload with fatal error message 32. This failure occurs when a shutdown command is issued during high traffic periods on the server. The following messages appear immediately before the error:

: %CIP2-1-MSG: slot1 %TN3270S-1-RP_PU_CONFLICT:RP & CIP hold conflicting PU name(xxxxxxxx) or index(92)
: Where "xxxxxxxx" is the PU name.
: %CBUS-3-CIPCFGFAIL: Channel1/2: configuration command TN3270S_DLUR_PU_NEW cmd 18 failed
: %CIP2-0-MSG: slot1 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=32)
: The workaround is to perform the shutdown when the server load is light. [CSCdk83807]

The CIP running TN3270 fails with fatal error number 35 when a shut command is issued to the TN3270 Server. This problem occurs when the shut command is issued and the TN3270 Server is operating at high capacity.

: The workaround is to issue the shut command only after the client traffic terminates. [CSCdk87658]

If a CIP2 PCA (Bus and Tag) has an Altera FLEX chip (the large chip on the PCA daughter card) with a date code of 9601 or greater, the CIP will fail with parity errors shortly after the card is first installed. The date code on the PCA can be found only by looking for a code on the edge of the chip or the top heat sink area.

: The workaround is to upgrade to the recommended CIP microcode version which corresponds to your Cisco IOS software. [CSCdm28629]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The CIP running TN3270 Server receives DSI562I error messages on the NetView console. The messages indicate that in the activate physical unit (ACTPU) control vector 80, unsolicited network management vector transport (NMVT) request units are not allowed. The CIP TN3270 Server still sends product-set identification (PSID) NMVT messages for VTAM PUs with only LUs.

: There is no workaround.
: To enable the fix in the cip24-13 microcode, the maximum-lu command must be added to the TN3270 Server configuration file. [CSCdm36152]

The CIP VTAM session hangs at the VTAM message10 menu. This problem occurs when the user is at the VTAM message10 menu and hits multiple blank Enter keys and when the inbound request unit on the SSCP-LU session is 256 bytes or greater.

: There is no workaround. [CSCdm37663]

The CIP fails and causes a CBUS restart. Activating the VTAM external communication adapter (XCA) causes the CIP to fail with fatal error number 35. Repeated restarts and reactivation of the XCA produces the same results. This problem occurs when running Cisco IOS Release 11.2(18)BC and CIP microcode version cip24-11.

: The workaround is to use Cisco IOS Release 11.2(16)BC and CIP microcode version cip24-10. [CSCdm53220]

When the Attention (ATTN) key is pressed, the TN3270 client sends PA1 and ATTN messages. This problem occurs for IBM Personal Communication clients only.

: To enable this fix and filter out the PA1 messages, you must configure the TN3270 tn-parameter code codevalue command with a code value of 2.
: There is no workaround. [CSCdm54076]

Every other CIP TN3270 Server client connection fails. This problem occurs when clients are trying to connect at a slow rate and the TN3270 Server is operating with a light traffic load.

: There is no workaround. [CSCdm55234]

The following message appears on the CMCC console:

: bad error-code 12 given
: This valid error code indicates a missing TERMSELF response. The code to log and format this specific error into a console message is missing.
: There is no workaround. [CSCdm55961]

The downstream mini-EN/DLUR is unable to connect because it incorrectly calculates the lengths on the REGISTER general data stream (GDS). Shutting down and restarting exacerbates the problem.

: The workaround is to reload the CMCC adapter after changing the DLUR configuration. [CSCdm56389]

Attachmate clients loop when attempting to connect to the server. This problem occurs when the client is running Attachmate software version 6.2, the auto-reconnect feature is enabled, and invalid client names are configured.

: The workaround is to upgrade to Attachmate software release 6.3. [CSCdm58334]

The TN3270 Server response time to the clients is slow (2 to 90 seconds). This problem occurs only if the clients are on a Token Ring or FDDI network and the server is on an Ethernet network. The problem occurs when there is a moderate to heavy load on the network.

: The problem occurs because the client network maximum segment size (MSS) is set to 4000 and the server network MSS is set to 1500. The CMCC TCP stack attempts to increase the maximum transmission unit (MTU) from 1500 to 4000 every 10 minutes for each TCP connection. The Cisco IOS software sends only one or two ICMP messages per second, therefore some TCP packets are dropped and must be retransmitted. The retransmission intervals increase exponentially and these intervals appear to the user as a delay in response time.
: To enable this fix in microcode version cip22-39 and later, you must configure the TN3270 server keepalive seconds command with a value of 14444. To enable this fix in microcode version cip27-3, xcpa27-3 and later, you must configure the TN3270 server tn-parameter code codevalue value minutes command with a code value of 5. Value is the number of minutes between path MTU discovery retries. The default is 10 minutes. A value of 0 implies an infinite timer value.
: There is no workaround for other microcode versions. [CSCdm61803]

The CMCC TCP/IP Offload server socket application hangs. This problem occurs because an accept() socket request blocks after the select() indicated that the server socket was READABLE. The accept() socket request should have returned a so_error condition or the socket ID of a new client socket. In TPF Offload environments, where a single select() may monitor multiple sockets, this problem can cause the application to hang on multiple server sockets if an accept() is issued from the same thread that processes the select() response.

: The workaround is to close and re-open the server socket by restarting the server application on the host. [CSCdm63283]

The CMCC TN3270 server fails with fatal error code 35. This error occurs if the fix in CSCdm58334 has been applied.

: There is no workaround. [CSCdm69837]

The TN3270 server sends an LIC message to the DLUS on a +RSP. This message causes the DLUS to send an unbind message with sense data 400B0000 and to shut down the DLUR/DLUS pipe. The DLUR/DLUS pipe will re-establish and the user LU-LU sessions will not be affected.

This problem occurs when the TN3270 server DLUR component improperly saves RU chain bits from the original request to create a response message. This generates the +RSP sense data 400B0000.

The workaround is to increase the RU sizes on the DLUR/DLUS sessions. To increase the RU sizes on the DLUR/DLUS sessions, the user must do the following:

Create a new member called ISTINCLM in the customizable datasets ahead of SYS1.VTAMLIB in the concatenation sequence for DD name VTAMLIB.
Copy the ISTINCLM member from SYS1.SAMPLIB.
Change the RU sizes in member CPSVRMGR from 0x9797 to 0xC8C8 and assemble and link.
Issue the VTAM command FNET,TABLE,TYPE=MODETAB,OPTION=LOAD,NEWTAB=ISTINCLM
Restart the TN3270 server DLUR end node. [CSCdm70432]

When the CMCC adapter is configured with a large number of offload sessions, the following error message occurs:

%CIP2-3-MSG: slot0 %OFFL-3-NOMEM2: Not enough memory to process socket requests,              0 open, 0 in holddown

: The workaround is to increase memory. [CSCdm76552]

To enable the fix for CSCdk83774, the user must set the seconds value of the TN3270 keepalive seconds command to a multiple of 21. This prevents clients from disconnecting when the idle timer expires because there was not an SSCP screen.

: To enable the CSCdk83774 fix in microcode versions cip27-3, xcpa27-3 and later, you must configure the TN3270 tn-parameter code codevalue command with a code value of 6. [CSCdm76554]

Caveats for Version 27.1/Version 27.2 Modifications

This section describes possible unexpected behavior by Version 27.1. All the caveats listed in this section are resolved in Version 27.2. See Table 10 for the Cisco IOS software release that corresponds to the 27.2 microcode version.

An Offload application uses up resources and prevents traffic from going through the port adapter on the CMCC. This occurs in very unusual circumstances only, for example, when closing several thousand established TCP connections in a very short period of time.

: The workaround is to reload the CMCC microcode. [CSCdj08904]

A VTAM connect out completion time greater than 20 seconds causes unexpected connection failures and XCA major node failures. This failure occurs because VTAM overloads the PORT TIMER and, if the PORT TIMER is set too low, the LSA commands start to time out.

: VTAM version 4.3 introduced restrictions for the PORT TIMER value. The TIMER value cannot be less than the CMCC's T1 * N2. VTAM uses a hard-coded N2 value of 2. Before this fix, the CMCC reported a T1 value of 10. The VTAM documentation indicates that the T1 value is measured in tenths of a second. Therefore, a T1 value of 10 should equal 1 second. However, VTAM interprets the T1 value in seconds so a T1 value of 10 equals 10 seconds, not 1 second. VTAM then multiplies the value by 2 to get a minimum TIMER value of 20 seconds.
: The CMCC's reported T1 value is not the CMCC LLC T1 value. Because VTAM overloads the use of the PORT TIMER, do not adjust the CMCC's real LLC T1 value to alter the PORT TIMER. These adjustments can cause severe LLC2 problems.
: VTAM overloads the use of PORT TIMER. TIMER is used to set TEST request interval on connect outs. After each TEST request is sent, VTAM sets a timer equal to the PORT TIMER number of seconds and waits for a TEST response. If the TEST response is not received by VTAM before the timer expires, the next TEST request is sent. In CMCC scenarios, the first TEST request is a TEST local, the second is a spanning-route explorer.
: For the CMCC, most VTAM initiated LLC connections will not complete before the PORT TIMER seconds expire because the local TEST does not leave the CMCC's internal LAN. LLC connection setup requires a minimum of 20 seconds. VTAM will timeout on LSA commands if a response is not received within the set PORT TIMER value. For example, when VTAM sends a CONNECT request the CONNECT CONFIRM must be received before the PORT TIMER expires. The SABME and UA must be exchanged within the value set in PORT TIMER. If the SABME must be retried, the PORT ITMER might expire before the CONNECT CONFIRM is returned to VTAM.
: The workaround is to set the PORT TIMER value to 20 seconds or more unless the user is confident that the LSA commands will not timeout. [CSCdj45782]

When an online insertion and removal (OIR) of an IP card is performed on a Cisco 7500 series router with a CIP, the CIP processor utilization reaches maximum capacity (99 to 100 percent). This occurs when any IP card besides the CIP is inserted and removed online. If there are two CIPs in the router, an OIR of one CIP can effect the other.

: The workaround is to not OIR IP cards in a Cisco 7500 series router when the CIP is running. [CSCdj90287]

The TN3270 Server crashes with fatal error code 35. See caveat CSCdk02535. [CSCdk11968]
During a brief TCP connection, the CMCC TCP/IP Offload feature fails to return a response to a Read/Recv type socket request causing the connection's host application to hang while waiting for a response.

: A window exists for brief TCP connections when a connection is made with TCP/IP on the CMCC and then broken (FIN received) before Offload has received and processed an Accept socket request from the host. In this situation, Offload misses the notification from TCP/IP that the connection had been terminated.
: There is no workaround. [CSCdk12291]

The TN3270 Server session fails with the following error message:

INOP STATUS

: The workaround is to reactivate the external communication adapter (XCA) major node. [CSCdk36329]

If a user disconnects without properly logging off the mainframe, a new user can connect to those existing sessions. This problem occurs when accessing Customer Information Control System (CICS) applications through the TN3270 Server. [CSCdk48736]
Sometimes TN3270 client disconnections are counted twice. This miscount results in an incorrect TN3270 active session count. The dynamic LU count for that PU becomes one less than the actual number. This is not a problem until the actual count reaches zero and the dynamic LU count cycles to 255. When this miscount occurs, if you enter the show extended ch4/2 tn command, (which shows how many LUs are in use) the result is inflated by 255.

: The workaround is to shut down and restart the PU or to cycle the PU in VTAM. [CSCdk57112]

Inconsistent keepalives occur when multiple TN3270 sessions are configured to the same server. When the sessions are idle for an hour or more, keepalives are not sent even though the keepalive value is set to 300 (5 minutes).

: The workaround is to restart the session. [CSCdk57453]

Dynamic LUs remain in a P-NFT/UA state when the TN3270 Server is configured. The LUs cannot be used again when in this state.

: The workaround is to deactivate the LU or the owning PU in VTAM. [CSCdk60263]

The TN3270 session between the client and TN3270 server is disconnected when the client issues the logoff command at the VTAM MSG10 screen. [CSCdk80609]
The TN3270 Server session disconnects after 150 seconds when the LOGON APPLID is not entered. In this case, there is no unformatted system services table (USSTAB).

: There is no workaround. [CSCdk83774]

When the TN3270 server is configured, entering the SYSREQ key followed by the logoff command does not return the user to the queued session. Instead, the VTAM MSG1 warning is displayed.

Other SYSREQ key errors that occur when the TN3270 server is configured include:

Pressing the SYSREQ key twice does not return the user to the LU-LU session. An LUSTAT is sent inbound on the second SYSREQ key entry.
Entering the logoff command incorrectly locks the session. SSCP-LU does not recognize the change direction in a sense data frame. This problem might occur in other remote cases.
LU-LU data shows up on an SSCP-LU session.
When responding to DACTLU in LU-LU or bound states, an inbound unbind should be sent. This inbound unbind was not working, but it was not evident because the client is normally disconnected which causes a SESSEND.

The workaround is to not use the SYSREQ key. [CSCdk83960]

The TN3270 Server does not process the 0x016C6102 message from the client as a system request (SYSREQ). Therefore, the TN3270 Server does not send a logoff message to the system services control point (SSCP). This message should produce the sequence described in RFC 1647 (TN3270E), except that 0x016C6102 is used to indicate SYSREQ instead of Abort Output (FFF5).

: There is no workaround. [CSCdk89383]

CMCC devices with Bus and Tag connections do not activate properly when connected to an Amdahl 857 running the UTS operating system.

: There is no workaround. [CSCdk91964]

For extended periods of time, the write device for a CLAW connection experiences the same number of command retries and connects. Data throughput decreases significantly during these periods, but the connection is not lost. The connections and the command retries are displayed with the show extended channel slot/port command. This situation occurs when the channel operates at 95 percent or greater capacity for many hours.

: A workaround is to distribute the traffic to multiple boxes to avoid a channel capacity of 95 percent or greater. [CSCdk92004]

The CMCC TCP/IP Offload feature fails during select() processing when 28 or more sockets are defined in a single select request. If a select() request contains 28 or more socket descriptors in the descriptor list, the select() response is truncated after the offload message header. If the mainframe offload application does not validate the offload message header buffer_length field and detect the ZERO length response data, it may process random data in the memory which follows the offload message header as the start of response data and incorrectly interprets the select() response results.

: This problem does not occur when using select() under VM or MVS because select() is issued for one socket at a time. This problem occurs when using TPF if the select() request contains 28 or more socket descriptors.
: There is no workaround for this problem. This DDTS is a continuation of CSCdk86184. [CSCdm02126]

If IP fragments that are 21 to 23 bytes long are sent to the CLAW of an OFFLOAD connection to a mainframe the packet is dropped and the following error message is sent:

: CLAW-6-TOOSMALL: xx byte IP datagram is to small, device x/yyyy/zz
: The workaround is to modify the network so that IP fragments do not occur. [CSCdm11522]

The CMCC unexpectedly reloads with the following error messages:

: %CBUS-3-CMDTIMEOUT: Cmd timed out, CCB 0x5800FF50, slot 3, cmd code 2
: %CMCC-3-RSETFAIL: Interface Channel3/2: Error (8010) enable
: %DEBUGGER-0-FATAL_ERROR: Fatal error (code=35)
: The problem occurs when the CMCC virtual interface is shut down or when a no tg hsas-ip or tg ip command is issued.
: There is no workaround. [CSCdm21378]

If a CIP2 PCA (Bus and Tag) has an Altera FLEX chip (the large chip on the PCA daughter card) with a date code of 9601 or greater, the CIP will fail with parity errors shortly after the card is first installed. The date code on the PCA can be found only by looking for a code on the edge of the chip or the top heat sink area.

: The workaround is to upgrade to the recommended CIP microcode version which corresponds to your Cisco IOS software. [CSCdm28629]

The TN3270 Server session disconnects and brings up the Sign On menu. This problem occurs when a user has entered an AID command that it is queued in the server and then is scrolling through the session window. The server sends the AID to the host before receiving the end bracket specifying the direction.

The following trace scenario illustrates the problem:

The BID command is received from the host:

: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=10,2C003601 00AE4B81 00C8
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8501,lu-flags=0D24D204
: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=10,2C000136 00AECB81 00C8

An AID command is received before the host has a chance to send the BB command. Since the BID command was already received the server queues the AID frame:

: *Apr 26 13:36:24: %CIP: slot0 In Tnet 212: len=13,00000100 42F7D7F5 11D7F5FF EF
: *Apr 26 13:36:24: slot0 Out Lu 5.54: sna-state=8D01,lu-flags=0D24D204

The host sends the next write with the BB/keyboard restored (note that there is no EB command):

: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=1484,2C003601 00AF0381 80F10611 5D611DE8
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8D01,lu-flags=0D24D204
: *Apr 26 13:36:24: %CIP: slot0 Out Tnet 212: len=1482,00000200 6C010411 5D611DE8 40404040

The client sends the response to the frame:

: *Apr 26 13:36:24: %CIP: slot0 In Tnet 212: len=8,02000000 6C00FFEF
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8509,lu-flags=0B24D204
: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=9,2C000136 00AF8381 00

The BUG-inbound queued data was sent inbound before the EB command was received from the host:

: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=15,2C000136 00200392 20F7D7F5 11D7F5
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=9,2C003601 00B00391 40

There is no workaround. [CSCdm31347]

The TN3270 server LUs using LU Nailing fail. If a client IP address is nailed to an LU or range of LUs then it cannot connect to the host. This problem occurs whether or not an LU name is supplied.

: The following messages appear on the TN3270 console:
: %CMCC: slot4 [bad telnet connect]13[ipAddrClient]172.16.25.255:[tcpPortCl
: %CMCC: slot4 ----ient]0x40C:[connectReasonCode]0xE:[tn3270eDeviceType]IBM
: %CMCC: slot4 -----3278-5-E:[tn3270eDeviceName]:[tn3270eSubErr]no-naill:
: The workaround is to remove LU Nailing and restart the TN3270 server. Removing the LU Nailing command is not sufficient. Another workaround is to use a dynamic LU build. This build works with LU Nailing. [CSCdm36117]

Caveats for Version 27.0/Version 27.1 Modifications

This section describes possible unexpected behavior by Version 27.0. All the caveats listed in this section are resolved in Version 27.1. See Table 10 for the Cisco IOS software release that corresponds to the 27.1 microcode version.

If the maxpiu value of the csna command is set to 4096 bytes a CSNA-LONGREC error occurs when the sum of the size of an inbound frame and the size of the LSA DataInd command exceeds 4 K. The CSNA-LONGREC error causes VTAM to terminate the connection.

: The workaround is to increase the maxpiu value, preferably to the default which is 20470 bytes. [CSCdk71668]

The CMCC TCP/IP Offload feature fails during select() processing when more than 27 sockets are defined in a single select request. Failures include premature response to select requests, corrupt descriptor list in the select response, and intermittent fatal error (code=32). These failures should only occur in Transaction Processing Facility (TPF) Offload environments.

: The workaround is to limit the number of sockets selected in a single select request to 27 or less. [CSCdk86184]

The CMCC unexpectedly reloads with the following error messages:

: %CBUS-3-CMDTIMEOUT: Cmd timed out, CCB 0x5800FF50, slot 3, cmd code 2
: %CMCC-3-RSETFAIL: Interface Channel3/2: Error (8010) enable
: %DEBUGGER-0-FATAL_ERROR: Fatal error (code=35)
: The problem occurs when the CMCC virtual interface is shut down or when a no tg hsas-ip or tg ip command is issued.
: There is no workaround. [CSCdm21378]

CIP Microcode Release cip26 Caveats and Modifications

The following section describes the caveats to current CIP microcode versions and the modifications made in current CIP microcode versions for cip26 microcode. The caveats listed apply to only the most serious problems. See Table 10 for the Cisco IOS software releases supported by cip26 microcode.

Caveats for Version 26.14/Version 26.15 Modifications

This section describes possible unexpected behavior by Version 26.14. All the caveats listed in this section are resolved in Version 26.15. See Table 10 for the Cisco IOS software release that corresponds to the 26.15 microcode version.

When a parallel link that connects a Cisco TN3270 server to another server and carries the control point-to-control point sessions goes down, the Cisco TN3270 cannot establish a control point-to-control point session with any server.

: The workaround is to define alternate links to the same VTAM host only at the host end, or avoid multiple links to the same VTAM host. [CSCdp02702]

The CMCC adapter fails with a fatal error message number 9.

CIP2-3-MSG: slot0 %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../ssi/ssi_buff.c @ 1035 - msgP->m_next
Jan 31 15:40:12: %CIP2-0-MSG: slot0 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: There is no workaround. [CSCdp84989]

The Offload socket response on the transaction processing facility (TPF) is delayed by 10 seconds or more. This problem occurs when there is a lack of MEMD buffers on the channel interface on the Cisco 7500 series router for a prolonged length of time. This applies to the CIP, only.

: There is no workaround. [CSCdr33661]

The CMCC adapter fails with multiple fatal error messages (number 35). This problem occurs when running Cisco IOS release 12.0(10) and CIP or CPA microcode version 26-10 or later.

: There is no workaround. [CSCdr54396]

Caveats for Version 26.13/Version 26.14 Modifications

This section describes possible unexpected behavior by Version 26.13. All the caveats listed in this section are resolved in Version 26.14. See Table 10 for the Cisco IOS software release that corresponds to the 26.14 microcode version.

A user receives another user's session when both users are logged into the same applications owning region (AOR) in the Customer Information Control System and that AOR is manually cancelled.

: The workaround is to not disconnect a client during the logon process; that is, after requesting an application from the SSCP screen, but before establishing the LU-LU session with that application. [CSCdm51110]

The following message appears on the CMCC console:

: bad error-code 12 given
: This valid error code indicates a missing TERMSELF response. The code to log and format this specific error into a console message is missing.
: There is no workaround. [CSCdm55961]

The CMCC adapter fails with error message number 32. This problem occurs when the TN3270 server is configured and is using, or has used, the TN3270 monitor or a similar product.

: The workaround is to not configure the TN3270 monitor or a similar product. [CSCdp16086]

The TN3270 server show pu command output is missing LU states. The missing states are displayed as P-RESET. This applies also to the LU state objects in the TN3270 server MIB.

: There is no workaround. [CSCdp51038]

The CMCC adapter fails with fatal error message number 32. This problem occurs when approximately 25 or more DLUR links are configured. The reply buffer is too small to contain all of the Cross Domain Init vectors and the positive locate reply.

: The workaround is to configure fewer DLUR links. [CSCdp79125]

The CMCC adapter fails with fatal error message number 32 and the following log message:

%TN3270S-1-RP_PU_CONFLICT:RP & CIP hold conflicting PU name(XXXXX) or index(xxx)

: This problem occurs when multiple PUs are defined and the no pu command is issued to remove a PU that is not the last in chain. The problem also may occur when DLUR is configured.
: The workaround is to remove the last PUs in the list first (also known as last in first out [LIFO] order). [CSCdp98933]

The CMCC adapter may fail when the shutdown command is configured in TN3270 sub-mode.

: There is no workaround. [CSCdp99538]

The CMCC adapter configured for CSNA may not respond to a test poll. This problem occurs because there is a miscount of the available IBM VTAM External Communications Adapter (XCA) resources. Typically an XCA autogen parameter is configured to automatically generate lines and PUs. This is not required for PU5-to-PU4 or PU5-to-PU5 communications.

: The workaround is to recycle the XCA major node. [CSCdr03103]

The CMCC adapter fails with the following fatal error message number 35:

%CTA-0-INACTIVE: PA1 CTA 7C00-50 reset after being inactive for 180 seconds

: The workaround is to shutdown the CSNA subchannel before shutting down VTAM. [CSCdr13804]

When using the TN3270 server monitor or a similar product such as SOLVE:Netmaster for TCP/IP, the length of the message fragment field is reported incorrectly. The field length is reported as "18". It should be reported as "20". The message fragment field is defined as follows:

  struct {short PACKED(pktLength); short PACKED(len); 
          unsigned char PACKED(bytes[16]);}

: This is a cosmetic failure and is present in all CIP and CPA microcode releases.
: There is no workaround. [CSCdr24412]

VTAM issues a V NET,INACT,TYPE=GIVEBACK message. The control point-to-control point session moves to the other DLUS, but the DLUR pipe stops and restarts on the same host.

: There is no workaround. [CSCdr28173]

Caveats for Version 26.12/Version 26.13 Modifications

This section describes possible unexpected behavior by Version 26.12. All the caveats listed in this section are resolved in Version 26.13. See Table 10 for the Cisco IOS software release that corresponds to the 26.13 microcode version.

Users are unable to start new CMCC sessions. The results of a show extended channel x/2 tn command show that some PUs are in an ACT/Busy state. The results of a VTAM display of the PU show that the PU is in an active state.

: The workaround is to reload the microcode. [CSCdm44279]

The TN3270 Server running on TPF returns the following error message:

Offload time out

: This problem occurs when the client establishes a connection to the server, issues a request, gets the response and then closes the connection by sending a RST (reset) segment.
: The server issues a read to the connection, the read message is blocked and returns with the error message. The read message should return with a 0 message, meaning that the connection was closed. This problem happens after one minute.
: There is no workaround. [CSCdr05011]

The CMCC adapter running CIP Offload returns the following error message:

: %CIP2-4-MSG: slot0 %OFFL-4-BADDESC: 0/9300/60 Socket descriptor 259 in request is bad: state DESC_Holddown compare 259
: This is a cosmetic problem that should not impact performance.
: There is no workaround. [CSCdp84965]

The CMCC adapter running CIP Offload reloads with fatal error message number 35. This problem occurs when too many Offload and CLAW statements are configured on the same interface. The process table is shared by two interfaces and can not exceed 530 processes. Each Offload uses 4 processes. Each CLAW uses 2 processes. There are about 20 to 30 processes that are always running in addition to any Offload or CLAW configurations.

: The workaround is to configure fewer Offload and CLAW statements. [CSCdp85560]

The CMCC adapter fails with fatal error message number 32. This problem occurs when changing the IP address of a loopback interface.

: There is no workaround. [CSCdp85890]

Caveats for Version 26.11/Version 26.12 Modifications

This section describes possible unexpected behavior by Version 26.11. All the caveats listed in this section are resolved in Version 26.12. See Table 10 for the Cisco IOS software release that corresponds to the 26.12 microcode version.

BADTIMER messages appear when running TN3270 Server. In this case, the messages appear because a TN3270 session is being negotiated or recently has been negotiated. The messages do not impact normal TN3270 Server operations.

: There is no workaround. [CSCdk21633]

The CMCC adapter fails with error message 37. The following error messages appear:

%CONFIG-3-WORKLEFT:Work pending on work queue when device terminated 
%DEBUGGER-0-FATAL_ERROR:Fatal error (code=37)

: There is no workaround. [CSCp54593]

The CIP configured for CSNA crashes with the following error message:

: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ./cta802/dlu.c Fatal error (09).
: [CSCdm22660]

In duplicate MAC environments, idle Systems Application Architecture (SAA) gateway sessions terminate. SAA gateways time out the route to the CMCC MAC address and send receive ready poll (RR(P)) single route explorer (SRE) messages to rediscover the route. The CMCC adapter is not in session and responds to the RR(P) messages with a disconnect mode final (DM(F)) message. The SAA gateway then disconnects the session. The RR(P) SRE is contrary to the LLC2 specifications.

: The workaround is to specify XTX=7 on the route.nlm. [CSCdp09295]

The CMCC adapter fails with the following message:

%CIP2-3-MSG: slot0 %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta802/ciptask.c @ 322 - !mxcb->mx_next
%CIP2-0-MSG: slot0 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: The assertion is intended to detect messages with 15 or more memory buffers (mbufs). There is no workaround. [CSCdp13245]

The CMCC Adapter fails when running CSNA. This problem occurs while processing the detection of idle subchannel conditions.

: The workaround is to avoid creating idle subchannel conditions by not using the Z NET cancel command. Other possible workarounds include shutting down the router channel interface or removing the CSNA configuration statement before issuing the Z NET cancel command. [CSCdp31175]

A print server with 10 LUs fails to get 10 TNET connections with the TN3270 Server. The tenth LU client receives a FIN message from the TN3270 Server. The TN3270 Server rejects the TNET message indicating Listen Closed on the PU. Additional attempts to connect to the tenth LU fail until the LU is reactivated or another LU is disconnected. The problem only occurs when the last ACTLU static LU is obtained by a client. It is standard practice for the TN3270 Server to close the listen vector at this time; however, it should not close any connections that are being negotiated and have obtained LUs.

: The workaround is to add an additional 3 LUs to the VTAM switched major node, leaving the print server to request only 10 TNET connections. [CSCdp43253]

When an online insertion and removal (OIR) of an IP card is performed on a Cisco 7500 series router with a CIP, the following error messages are displayed:

*Jan 18 00:56:35: %OIR-6-REMCARD: Card removed from slot 1, interfaces disabled
*Jan 18 00:56:40: %CIP2-6-MSG: slot5 %SYSMGT_RPC-6-STATE_CHANGE: System 
Management activated
*Jan 18 00:56:47: %CIP2-3-MSG: slot5 %LOVE-3-LOVELETTER: Error in love 
letter processing for port 0(0)

: There is no workaround. [CSCdp75240]

Caveats for Version 26.10/Version 26.11 Modifications

This section describes possible unexpected behavior by Version 26.10. All the caveats listed in this section are resolved in Version 26.11. See Table 10 for the Cisco IOS software release that corresponds to the 26.11 microcode version.

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The following message appears on the CMCC console:

: bad error-code 12 given
: This valid error code indicates a missing TERMSELF response. The code to log and format this specific error into a console message is missing.
: There is no workaround. [CSCdm55961]

CSNA devices fail with INOP messages during Interface Control Check (IFCC) status. This problem occurs when CLAW and CSNA are operating in high traffic conditions. It can occur in CMPC and CSNA, also.

: The workaround is to upgrade the CMCC microcode or to restart the external communication adapter (XCA) nodes. [CSCdm88239]

A BIND REQUEST or SSCP-LU message is expected but not received from the host within 30 seconds from the start of an SSCP-LU session for the CMCC Adapter TN3270 server session. If the condition continues for another 2 minutes, the LU is declared bad and the following error message appears:

%TN3270S-1-NO_BIND_REQ_RCVD: No BIND REQ received on LU [chars].[dec], 120*ONESEC

: This error and several others are logged as priority 1 (alert) messages in error reports. The priority level of the following error messages is now priority level 3:

NO_PSID_RSP_RCVD
NO_NTFY_AV_RSP_RCVD
NO_BIND_REQ_RCVD
NO_SDT_REQ_RCVD
NO_SDT_TMARK_RCVD
NO_UNBIND_TMARK_RCVD
NO_NTFY_UA_RSP_RCVD
NO_DYN_ACTLU_REQ_RCVD
NO_UNBIND_RSP_RCVD 
NO_TERMSELF_RSP_RCVD

: [CSCdm94788]

When an ICMP Host Unreachable packet is received by the TCP stack, it generates several soft errors before the error becomes permanent. The Offload select() returns readable to the soft errors. [CSCdp18373]
The CMCC adapter with TN3270 Server configured fails with fatal error message 35. This problem occurs when attempting to clear the TN3270 configuration from the router. After entering the no tn3270-server command while in configuration mode on the virtual channel interface, the microcode reloads and all the interfaces flap. The CSNA devices are removed from the running configuration and must be reconfigured.

: There is no workaround. [CSCdp24670]

The CMCC Adapter fails when running CSNA. This problem occurs while processing the detection of idle subchannel conditions.

: The workaround is to avoid creating idle subchannel conditions by not using the Z NET cancel command. Other possible workarounds include shutting down the router channel interface or removing the CSNA configuration statement before issuing the Z NET cancel command. [CSCdp31175]

The CLAW control link does not establish. This problem most likely occurs on a TPF system or on an IBM TCP/IP system. The problem occurs because the timing of the Halt Subchannel message related to the Start Subchannel message is off.

: The workaround is to stop and restart the CLAW driver causing the CLAW control link to synchronize again. [CSCdp32675]

The CMCC Adapter calculates a set buffer address (SBA) that is above the screen size. This problem occurs when connecting a 327802 client using a 3270 datastream. This causes the connected session to hang on the MSG0 screen.

: The workaround is to code the LUGROUP parameter with one of the following values: SSCPFM=USS3270 or SSCPFM=USS3270. [CSCdp46564]

The CMCC Adapter configured for TCP/IP Offload fails with a error message 35. This problem occurs after a %MBUF-0-MFREEx2 message error. The problem occurs in rare circumstances when a socket request close() is issued on a TCP/IP server socket which has an outstanding accept() socket response on a BLOCKING socket. This problem also occurs in the same circumstances on a CMCC Adapter configured for TPF Offload.

: There is no workaround. [CSCdp47885]

Caveats for Version 26.9/Version 26.10 Modifications

This section describes possible unexpected behavior by Version 26.9. All the caveats listed in this section are resolved in Version 26.10. See Table 10 for the Cisco IOS software release that corresponds to the 26.10 microcode version.

OpenConnect has an informal extension to the Termtype in TN3270. When connecting through an OpenConnect TN3270 gateway, the client IP address is concatenated on the end with a percent (%) symbol.

: The CMCC TN3270 Server does not use this client IP address for matching on LU nailing statements in the configuration. [CSCdj44584]

MSG10 data from one LU might be seen on an LU already in session. This problem occurs when the TN3270 server remote MAC address resides on a different physical adapter or in a different physical machine, such as a front-end processor (FEP).

: The workaround is to make sure that the RMAC TN3270 server PU resides on the same CMCC adapter as the TN3270 Server. [CSCdm01837]

In a duplicate MAC environment, the CIP will continue to respond to a TEST command when the lines configured for the XCA are in use. This problem prevents other duplicate MAC adapters from responding to new requests.

: The workaround is to configure the maximum LLC or threshold to equal the number of XCA lines configured. [CSCdm29597]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The CMCC displays a RSP sense 089F0004 message when processing a REQACTPU message. The problem occurs when the VARY command is entered for DLUR PUs that have multiple PATH statements. The problem occurs because the DLUR sends a message to the DLUS containing an FQPCID value which DLUS created on an earlier acquisition of the PU. The host processes the FQPCID message as invalid.

: The workaround is to remove the PATH statements. [CSCdm42103]

Users are unable to start new CMCC sessions. The results of a show extended channel x/2 tn command show that some PUs are in an ACT/Busy state. The results of a VTAM display of the PU show that the PU is in an active state.

: The workaround is to reload the microcode. [CSCdm44279]

A user receives another user's session when both users are logged into the same applications owning region (AOR) in the Customer Information Control System and that AOR is manually cancelled.

: The workaround is to not disconnect a client during the logon process; that is, after requesting an application from the SSCP screen, but before establishing the LU-LU session with that application. [CSCdm51110]

The CMCC adapter fails with fatal error code 35 during the TN3270 Server shutdown. This problem occurs because the TN3270 Server PUs are not communicating with the host.

: A workaround is available. Contact the Cisco TN3270 Server development engineers for the interim fix. [CSCdm61159]

The TN3270 Server running DLUR/DLUS fails with fatal error message code 35. This problem occurs because the TN3270 Server tries to invoke a SendACTLURSP using a NULL object reference.

: This fix adds a debug message to the log and marks the ACTLU as not processed.
: There is no workaround. [CSCdm69186]

The TN3270 server sends an LIC message to the DLUS on a +RSP. This message causes the DLUS to send an unbind message with sense data 400B0000 and to shut down the DLUR/DLUS pipe. The DLUR/DLUS pipe will re-establish and the user LU-LU sessions will not be affected.

This problem occurs when the TN3270 server DLUR component improperly saves RU chain bits from the original request to create a response message. This generates the +RSP sense data 400B0000.

The workaround is to increase the RU sizes on the DLUR/DLUS sessions. To increase the RU sizes on the DLUR/DLUS sessions, the user must do the following:

Create a new member called ISTINCLM in the customizable datasets ahead of SYS1.VTAMLIB in the concatenation sequence for DD name VTAMLIB.
Copy the ISTINCLM member from SYS1.SAMPLIB.
Change the RU sizes in member CPSVRMGR from 0x9797 to 0xC8C8 and assemble and link.
Issue the VTAM command FNET,TABLE,TYPE=MODETAB,OPTION=LOAD,NEWTAB=ISTINCLM
Restart the TN3270 server DLUR end node. [CSCdm70432]

The DLUR pipe between VTAM and the CMCC adapter hangs. This problem occurs when a large number of TN3270 Server TCP/IP requests (1000 per CMCC Adapter) arrive at the same time.

: The workaround is to space out the TCP/IP requests. [CSCdm75120]

When the CMCC adapter is configured with a large number of offload sessions, the following error message occurs:

%CIP2-3-MSG: slot0 %OFFL-3-NOMEM2: Not enough memory to process socket requests,              0 open, 0 in holddown

: The workaround is to increase memory. [CSCdm76552]

The TN3270 Server fails with the following error message:

%DEBUGGER-0-FATAL_ERROR: Fatal error (code=35)

: This error occurs when the TN3270 Server is shut down while traffic is still transmitting. [CSCdm78261]

The unbind/bind sequence in the response time logic during a transaction does not reset the sample. This error causes an invalid response time which might be extremely large, depending upon the timing of the transaction. This problem occurs when the unbind keep is configured when the next transaction completes.

: There is no workaround. [CSCdm82521]

A select() message does not respond or times out when the peer closes the connection. This problem is more likely to occur when using TPF.

: The workaround is to delay the shutdown for 20 ms after the last send() message. [CSCdm85311]

The TN3270 IND$FILE file transfer performs poorly if the RU size is smaller than the maximum transmission unit (MTU). This problem occurs because the Cisco TN3270 Server uses the Nagle algorithm by default.

: The workaround is to set the RU size so that it is at least as big as the MTU on the file transfer path. [CSCdm86734]

The TN3270 Server overwrites 1 byte of a Read Partition Query (RPQ) response. The overwrite occurs because of a logic that was entered to capture a non-standard SYSREQ key sequence for non-TN3270E emulators.

: There is no workaround. [CSCdm88195]

A TPF receive message fails to retrieve all the data. The problem occurs when the TPF client performs a shutdown-writing and then tries to receive the data.

: The workaround is to not perform the shutdown-writing. [CSCdm92713]

A CMCC file transfer hangs or the keyboard stops working. The problem occurs when the IND$FILE uses structured fields and buffers that are 2000 bytes or greater. The keyboard is restored using the TN3270 write command instead of the structured field.

: The workaround is to use buffers that are 2000 bytes or less or non-structured fields (presentation space transfer. To enable the fix in CMCC releases cip27-4 and greater and xcpa27-4 and greater, you must configure the TN3270 tn-parameter code codevalue command with a code value of 7. [CSCdm93990]

The VTAM to VTAM communication for APPN and FID2 hangs. The non-LLC2 HPR traffic does not hang. This problem occurs when both VTAMs are attached to the CIP running the CMPC feature.

: There is no workaround. [CSCdp00921]

A TCP/IP Offload select() for readability message indicates that there are no readable sockets in the descriptor list when in fact there are readable sockets available. This problem occurs when the TCP/IP connection fails while a select() for readability message is outstanding on the socket.

: There is no workaround. [CSCdp08103]

Caveats for Version 26.8/Version 26.9 Modifications

This section describes possible unexpected behavior by Version 26.8. All the caveats listed in this section are resolved in Version 26.9. See Table 10 for the Cisco IOS software release that corresponds to the 26.9 microcode version.

An Offload application uses up resources and prevents traffic from going through the port adapter on the CMCC. This occurs in very unusual circumstances only, for example, when closing several thousand established TCP connections in a very short period of time.

: The workaround is to reload the CMCC microcode. [CSCdj08904]

A VTAM connect out completion time greater than 20 seconds causes unexpected connection failures and XCA major node failures. This failure occurs because VTAM overloads the PORT TIMER and, if the PORT TIMER is set too low, the LSA commands start to time out.

: VTAM version 4.3 introduced restrictions for the PORT TIMER value. The TIMER value cannot be less than the CMCC's T1 * N2. VTAM uses a hard-coded N2 value of 2. Before this fix, the CMCC reported a T1 value of 10. The VTAM documentation indicates that the T1 value is measured in tenths of a second. Therefore, a T1 value of 10 should equal 1 second. However, VTAM interprets the T1 value in seconds so a T1 value of 10 equals 10 seconds, not 1 second. VTAM then multiplies the value by 2 to get a minimum TIMER value of 20 seconds.
: The CMCC's reported T1 value is not the CMCC LLC T1 value. Because VTAM overloads the use of the PORT TIMER, do not adjust the CMCC's real LLC T1 value to alter the PORT TIMER. These adjustments can cause severe LLC2 problems.
: VTAM overloads the use of PORT TIMER. TIMER is used to set TEST request interval on connect outs. After each TEST request is sent, VTAM sets a timer equal to the PORT TIMER number of seconds and waits for a TEST response. If the TEST response is not received by VTAM before the timer expires, the next TEST request is sent. In CMCC scenarios, the first TEST request is a TEST local, the second is a spanning-route explorer.
: For the CMCC, most VTAM initiated LLC connections will not complete before the PORT TIMER seconds expire because the local TEST does not leave the CMCC's internal LAN. LLC connection setup requires a minimum of 20 seconds. VTAM will timeout on LSA commands if a response is not received within the set PORT TIMER value. For example, when VTAM sends a CONNECT request the CONNECT CONFIRM must be received before the PORT TIMER expires. The SABME and UA must be exchanged within the value set in PORT TIMER. If the SABME must be retried, the PORT ITMER might expire before the CONNECT CONFIRM is returned to VTAM.
: The workaround is to set the PORT TIMER value to 20 seconds or more unless the user is confident that the LSA commands will not timeout. [CSCdj45782]

When an online insertion and removal (OIR) of an IP card is performed on a Cisco 7500 series router with a CIP, the CIP processor utilization reaches maximum capacity (99 to 100 percent). This occurs when any IP card besides the CIP is inserted and removed online. If there are two CIPs in the router, an OIR of one CIP can effect the other.

: The workaround is to not OIR IP cards in a Cisco 7500 series router when the CIP is running. [CSCdj90287]

The TN3270 Server crashes with fatal error code 35. See caveat CSCdk02535. During a brief TCP connection, the CMCC TCP/IP Offload feature fails to return a response to a Read/Recv type socket request causing the connection's host application to hang while waiting for a response.

: A window exists for brief TCP connections when a connection is made with TCP/IP on the CMCC and then broken (FIN received) before Offload has received and processed an Accept socket request from the host. In this situation, Offload misses the notification from TCP/IP that the connection had been terminated.
: There is no workaround. [CSCdk12291]

The TN3270 Server session fails with the following error message:

INOP STATUS

: The workaround is to reactivate the external communication adapter (XCA) major node. [CSCdk36329]

An error occurs when using the TN3270 Server to establish a connection to an application residing on a Migration Data Host (MDH) using a virtual routing node connection network.

: If a prior connection to the MDH from the server does not exist, it might take several attempts to make a connection. Once the initial connection is made, all subsequent connections will work.

Note IBM VTAM has opened an APAR for the 8002 sense portion of this problem. Users must get the APAR PTF from IBM to get MDH to work with the virtual routing node on the CMCC.

: [CSCdk37107]

The user is unable to track, using Hot Standby Router Protocol (HSRP) or SNMP Traps, the channel interface on a Cisco 7200 series router with a Channel Port Adapter (CPA). The channel interface is always up/up even if the physical interface cable is not attached to the CPA.

: There is no workaround.
: A new channel interface configuration command which is valid only for the CPA, state-tracks-signal, fixes this problem. This command directs the CPA's channel interface state to follow the physical signal value when the interface is in the no shut state. [CSCdk44052]

If a user disconnects without properly logging off the mainframe, a new user can connect to those existing sessions. This problem occurs when accessing Customer Information Control System (CICS) applications through the TN3270 Server. [CSCdk48736]
Sometimes TN3270 client disconnections are counted twice. This miscount results in an incorrect TN3270 active session count. The dynamic LU count for that PU becomes one less than the actual number. This is not a problem until the actual count reaches zero and the dynamic LU count cycles to 255. When this miscount occurs, if you enter the show extended ch4/2 tn command, (which shows how many LUs are in use) the result is inflated by 255.

: The workaround is to shut down and restart the PU or to cycle the PU in VTAM. [CSCdk57112]

Inconsistent keepalives occur when multiple TN3270 sessions are configured to the same server. When the sessions are idle for an hour or more, keepalives are not sent even though the keepalive value is set to 300 (5 minutes).

: The workaround is to restart the session. [CSCdk57453]

Dynamic LUs remain in a P-NFT/UA state when the TN3270 Server is configured. The LUs cannot be used again when in this state.

: The workaround is to deactivate the LU or the owning PU in VTAM. [CSCdk60263]

The TN3270 session between the client and TN3270 server is disconnected when the client issues the logoff command at the VTAM MSG10 screen. [CSCdk80609]
The TN3270 Server session disconnects after 150 seconds when the LOGON APPLID is not entered. In this case, there is no unformatted system services table (USSTAB).

: There is no workaround. [CSCdk83774]

Adding and removing PUs configured in TN3270 DLUR causes the CIP to reload with fatal error message 32. This failure occurs when a shutdown command is issued during high traffic periods on the server. The following messages appear immediately before the error:

: %CIP2-1-MSG: slot1 %TN3270S-1-RP_PU_CONFLICT:RP & CIP hold conflicting PU name(xxxxxxxx) or index(92)
: Where "xxxxxxxx" is the PU name.
: %CBUS-3-CIPCFGFAIL: Channel1/2: configuration command TN3270S_DLUR_PU_NEW cmd 18 failed
: %CIP2-0-MSG: slot1 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=32)
: The workaround is to perform the shutdown when the server load is light. [CSCdk83807]

When the TN3270 server is configured, entering the SYSREQ key followed by the logoff command does not return the user to the queued session. Instead, the VTAM MSG1 warning is displayed.

Other SYSREQ key errors that occur when the TN3270 server is configured include:

Pressing the SYSREQ key twice does not return the user to the LU-LU session. An LUSTAT is sent inbound on the second SYSREQ key entry.
Entering the logoff command incorrectly locks the session. SSCP-LU does not recognize the change direction in a sense data frame. This problem might occur in other remote cases.
LU-LU data shows up on an SSCP-LU session.
When responding to DACTLU in LU-LU or bound states, an inbound unbind should be sent. This inbound unbind was not working, but it was not evident because the client is normally disconnected which causes a SESSEND.

The workaround is to not use the SYSREQ key. [CSCdk83960]

The CIP running TN3270 fails with fatal error number 35 when a shut command is issued to the TN3270 server. This problem occurs when the shut command is issued and the TN3270 Server is operating at high capacity.

: The workaround is to issue the shut command only after the client traffic terminates. [CSCdk87658]

The TN3270 Server does not process the 0x016C6102 message from the client as a system request (SYSREQ). Therefore, the TN3270 Server does not send a logoff message to the system services control point (SSCP). This message should produce the sequence described in RFC 1647 (TN3270E), except that 0x016C6102 is used to indicate SYSREQ instead of Abort Output (FFF5).

: There is no workaround. [CSCdk89383]

CMCC devices with Bus and Tag connections do not activate properly when connected to an Amdahl 857 running the UTS operating system.

: There is no workaround. [CSCdk91964]

For extended periods of time, the write device for a CLAW connection experiences the same number of command retries and connects. Data throughput decreases significantly during these periods, but the connection is not lost. The connections and the command retries are displayed with the show extended channel slot/port command. This situation occurs when the channel operates at 95 percent or greater capacity for many hours.

: A workaround is to distribute the traffic to multiple boxes to avoid a channel capacity of 95 percent or greater. [CSCdk92004]

The CMCC TCP/IP Offload feature fails during select() processing when 28 or more sockets are defined in a single select request. If a select() request contains 28 or more socket descriptors in the descriptor list, the select() response is truncated after the offload message header. If the mainframe offload application does not validate the offload message header buffer_length field and detect the ZERO length response data, it may process random data in the memory which follows the offload message header as the start of response data and incorrectly interprets the select() response results.

: This problem does not occur when using select() under VM or MVS because select() is issued for one socket at a time. This problem occurs when using TPF if the select() request contains 28 or more socket descriptors.
: There is no workaround for this problem. This DDTS is a continuation of CSCdk86184. [CSCdm02126]

A query on the snaLuOperSnaName field in the SNA-NAU MIB returns an unexpected value. The MIB query returns the administrative name instead of the SNA name. This problem occurs if a direct PU, not a DLUR, has an LUSEED defined. Direct PUs do not support DDDLU. Also, this problem occurs when the INCLUD0E = YES field is not specified on the switched major node (SWM).

: The workaround is to use DLUR or DDDLU, or to specify the INCLUD0E = YES field on the SWM. [CSCdm13637]

If IP fragments that are 21 to 23 bytes long are sent to the CLAW of an OFFLOAD connection to a mainframe the packet is dropped and the following error message is sent:

: CLAW-6-TOOSMALL: xx byte IP datagram is to small, device x/yyyy/zz
: The workaround is to modify the network so that IP fragments do not occur. [CSCdm11522]

CIP response times and utilization increase when a large number of TN3270 Server connection attempts are made to the same source IP address. A large number of TCP no-op (NOP) messages are sent by the TN3270 Server to the clients.

: The fix limits the number of NOP messages sent to the clients. No configuration is required to enable the fix.
: There is no workaround. [CSCdm23252]

If a CIP2 PCA (Bus and Tag) has an Altera FLEX chip (the large chip on the PCA daughter card) with a date code of 9601 or greater, the CIP will fail with parity errors shortly after the card is first installed. The date code on the PCA can be found only by looking for a code on the edge of the chip or the top heat sink area.

: The workaround is to upgrade to the recommended CIP microcode version which corresponds to your Cisco IOS software. [CSCdm28629]

The TN3270 Server session disconnects and brings up the Sign On menu. This problem occurs when a user has entered an AID command that it is queued in the server and then is scrolling through the session window. The server sends the AID to the host before receiving the end bracket specifying the direction.

The following trace scenario illustrates the problem:

The BID command is received from the host:

: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=10,2C003601 00AE4B81 00C8
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8501,lu-flags=0D24D204
: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=10,2C000136 00AECB81 00C8

An AID command is received before the host has a chance to send the BB command. Since the BID command was already received the server queues the AID frame:

: *Apr 26 13:36:24: %CIP: slot0 In Tnet 212: len=13,00000100 42F7D7F5 11D7F5FF EF
: *Apr 26 13:36:24: slot0 Out Lu 5.54: sna-state=8D01,lu-flags=0D24D204

The host sends the next write with the BB/keyboard restored (note that there is no EB command):

: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=1484,2C003601 00AF0381 80F10611 5D611DE8
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8D01,lu-flags=0D24D204
: *Apr 26 13:36:24: %CIP: slot0 Out Tnet 212: len=1482,00000200 6C010411 5D611DE8 40404040

The client sends the response to the frame:

: *Apr 26 13:36:24: %CIP: slot0 In Tnet 212: len=8,02000000 6C00FFEF
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8509,lu-flags=0B24D204
: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=9,2C000136 00AF8381 00

The BUG-inbound queued data was sent inbound before the EB command was received from the host:

: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=15,2C000136 00200392 20F7D7F5 11D7F5
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=9,2C003601 00B00391 40

There is no workaround. [CSCdm31347]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The CIP running TN3270 Server receives DSI562I error messages on the NetView console. The messages indicate that in the activate physical unit (ACTPU) control vector 80, unsolicited network management vector transport (NMVT) request units are not allowed. The CIP TN3270 Server still sends product-set identification (PSID) NMVT messages for VTAM PUs with only LUs.

: There is no workaround.
: To enable the fix in the cip24-13 microcode, the maximum-lu command must be added to the TN3270 Server configuration file. [CSCdm36152]

The CIP VTAM session hangs at the VTAM message10 menu. This problem occurs when the user is at the VTAM message10 menu and hits multiple blank Enter keys and when the inbound request unit on the SSCP-LU session is 256 bytes or greater.

: There is no workaround. [CSCdm37663]

Every other CIP TN3270 Server client connection fails. This problem occurs when clients are trying to connect at a slow rate and the TN3270 Server is operating with a light traffic load.

: There is no workaround. [CSCdm55234]

The CMCC TCP/IP Offload server socket application hangs. This problem occurs because an accept() socket request blocks after the select() indicated that the server socket was READABLE. The accept() socket request should have returned a so_error condition or the socket ID of a new client socket. In TPF Offload environments, where a single select() may monitor multiple sockets, this problem can cause the application to hang on multiple server sockets if an accept() is issued from the same thread that processes the select() response.

: The workaround is to close and re-open the server socket by restarting the server application on the host. [CSCdm63283]

Caveats for Version 26.7/Version 26.8 Modifications

This section describes possible unexpected behavior by Version 26.7. All the caveats listed in this section are resolved in Version 26.8. See Table 10 for the Cisco IOS software release that corresponds to the 26.8 microcode version.

The TN3270 Server crashes with fatal error code 35. See caveat CSCdk02535. [CSCdk11968]
If a CIP2 PCA (Bus and Tag) has an Altera FLEX chip (the large chip on the PCA daughter card) with a date code of 9601 or greater, the CIP will fail with parity errors shortly after the card is first installed. The date code on the PCA can be found only by looking for a code on the edge of the chip or the top heat sink area.

: The workaround is to upgrade to the recommended CIP microcode version which corresponds to your Cisco IOS software. [CSCdm28629]

Caveats for Version 26.5/Version 26.7 Modifications

This section describes possible unexpected behavior by Version 26.5. All the caveats listed in this section are resolved in Version 26.7. See Table 10 for the Cisco IOS software release that corresponds to the 26.7 microcode version.

If the maxpiu value of the csna command is set to 4096 bytes, a CSNA-LONGREC error occurs when the sum of the size of an inbound frame and the size of the LSA DataInd command exceeds 4 K. The CSNA-LONGREC error causes VTAM to terminate the connection.

: The workaround is to increase the maxpiu value, preferably to the default, which is 20470 bytes. [CSCdk71668]

The CMCC TCP/IP Offload feature fails during select() processing when more than 27 sockets are defined in a single select request. Failures include premature response to select requests, corrupt descriptor list in the select response, and intermittent fatal error (code=32). These failures should only occur in Transaction Processing Facility (TPF) Offload environments.

: The workaround is to limit the number of sockets selected in a single select request to 27 or less. [CSCdk86184]

The CMCC TCP/IP Offload feature fails during select() processing when 28 or more sockets are defined in a single select request. If a select() request contains 28 or more socket descriptors in the descriptor list, the select() response is truncated after the offload message header. If the mainframe offload application does not validate the offload message header buffer_length field and detect the ZERO length response data, it may process random data in the memory which follows the offload message header as the start of response data and incorrectly interprets the select() response results.

: This problem does not occur when using select() under VM or MVS because select() is issued for one socket at a time. This problem occurs when using TPF if the select() request contains 28 or more socket descriptors.
: There is no workaround for this problem. This DDTS is a continuation of CSCdk86184. [CSCdm02126]

Caveats for Version 26.4/Version 26.5 Modifications

This section describes possible unexpected behavior by Version 26.4. All the caveats listed in this section are resolved in Version 26.5. See Table 10 for the Cisco IOS software release that corresponds to the 26.5 microcode version.

Certain ESCON conditions lead to LOGDATA error messages that result in a fatal error. The fatal error dump can cause the LOGDATA error messages to be lost. The lost LOGDATA messages contain critical information needed to determine the cause of the problems. The fatal error information usually contains secondary information about the problem.

: A workaround is to use the CIP core dump feature that is available in Cisco IOS Release 11.2BC and later. This feature saves all CIP memory to a file on an FTP server. The missing LOGDATA can be extracted from the core dump file. The workaround applies only for the CIP. [CSCdj61710]

A print job hangs when printing through the CMCC TN3270 Server. The Host application sends an exception response on the end bracket chain followed by a CHASE.

: There is no workaround. [CSCdk27199]

The AS/400 TN client attempts to establish an IBM-3180-2 terminal-type session with a TN5250 terminal. If a session is not available, the AS/400 TN client automatically switches to the TN3270 with a 3270 terminal type. The AS/400 TN client receives an ACK message from the 3180 terminal type when expecting a 5250 datastream. Instead, the TN3270 server sends it a 3270 datastream. Because the CMCC TN3270 Server accepts the IBM-3180-2 terminal-type the client does not switch to TN3270. [CSCdk37980]
The OFFL-3-NOMEM2 and OFFL-3-REJSOCK error messages indicate the same problem and should be combined into one message called OFFL-3-NOMEMSOCK. [CSCdk39425]
The CMCC crashes with fatal error code 37 after the BSQ-0-SCB_CHAIN: Read SCB chain is out of sequence. If the routing processor sends an IP packet to the CMCC for a CLAW-type device and that IP packet header indicates a 0 byte packet, the CMCC incorrectly tries to send a 0 byte message to the host and eventually causes a FATAL_ERROR on the CMCC.

: There is no workaround. [CSCdk41469]

LLC_DUP_CCB error messages appear on the router console. This problem occurs when multiple remote stations are configured with the same local MAC or SAP. The following is a sample configuration:

interface Channel2/2
no ip address
no keepalive
lan TokenRing 2
  source-bridge 102 1 400
  adapter 2 4000.8001.0102
tg PAN12    llc token-adapter 2  10 rmac 4000.9000.beef
tg PAN2     llc token-adapter 2  10 rmac 4000.8000.beef

: The error occurs if PAN2 is in the LocatingRemoteLinkStation state and the local SNA associated with PAN2 is deactivated then reactivated.
: Possible workarounds include reconfiguring the router not to use the same local MAC or SAP, or deactivating then reactivating all local SNA nodes associated with that local MAC or SAP. Another workaround is to reload the microcode on the CMCC having the problem. [CSCdk41506]

The CMCC adapter crashes with a fatal error code 35 when reconfiguring an offload statement using the same IP address that was used in a previously configured offload connection. This error occurs if the CMCC adapter has not completed deconfiguration cleanup of the previous offload statement before the new offload statement is configured using the same IP address. For example, the current configuration is as follows:

: offload e200 50 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: Reconfigure the offload statement as follows:
: no offload e200 50 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: offload e100 52 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: To workaround, after deconfiguring the offload statement, exit the configuration and issue the show extended channel slot/port ip-stack ip address command. When the offload deconfiguration is complete for the indicated offload statement IP address, the output should indicate "...No IP statistics found". At this point the new offload statement using the same IP address can be configured.
: The following is an example configuration:
: rispix#show ext ch 0/1 ip-stack
: IP Statistics for IP Address 80.11.198.2
: Forwarding : no DefaultTTL : 64 InReceives : 0
: InHdrErrors : 0 InAddrErrors : 0 ForwDatagrams: 0
: InUnknownProtos: 0 InDiscards : 0 InDelivers : 0
: OutRequests : 0 OutDiscards : 0 OutNoRoutes : 0
: ReasmTimeout : 60 ReasmReqds : 0 ReasmOKs : 0
: ReasmFails : 0 FragOKs : 0 FragFails : 0
: FragCreates : 0 RoutingDiscards: 0
: rispix#config t
: Enter configuration commands, one per line. End with CNTL/Z.
: rispix(config)#in ch 0/1
: rispix(config-if)#no offload e200 50
: rispix(config-if)#end
: rispix#
: 01:22:25: %SYS-5-CONFIG_I: Configured from console by console
: rispix#show ext ch 0/1 ip-stack
: ...No IP statistics found

: [CSCdk45042]

The TCP connection is closed (a FIN sent) before all data is sent. The remaining data (1 to 12 bytes) is sent after the connection is closed with another FIN. This problem occurs only with TCP connections that include TCP options in the TCP header and if the remaining data to be sent on the connection will fill up the packet before taking into account the length of the TCP options (12 bytes). This problem occurs when using the TCP large window support, which utilizes the TCP Timestamp option, implemented per RFC 1323.

: The workaround is to complete the following tasks:

Step 1 Log into the CMCC console:

if-con <CCMCC Slot> c

Step 2 Display the current state of this RFC:

ipconf <Offload IP Address> tcp_rfc1323

Step 3 Disable this RFC:

ipconf <Offload IP Address> tcp_rfc1323 off

Step 4 Verify the configuration change using Step 2. This RFC can be re-enabled, if necessary, using the same command but with the "on" option.

ipconf <Offload IP Address> tcp_rfc1323 on

Step 5 Exit the CMCC console:

quit (CIP21-x/CIP204-x releases)
if-quit or ^C^C^C (CIP22-x/CIP205-x and all later releases or XCPA26-x/XCPA214-x and all later releases)

: Unlike configuration commands issued from the router console, this CMCC configuration command is not retained if the CMCC or the router reloads or crashes and reloads. [CSCdk57139]

When running the CMCC TN3270 Server, LU 1 print jobs hang if the print application sends the RU chains as EXR (exception response) and the connection is running over a RFC1646-style TN3270 print connection.

: The workaround is to print the job using LU 3 printing or to reconfigure the print application to send the SNA RU chains with DR (definite response) requested. [CSCdk59063]

IP datagram connectivity no longer works if the following message appears on the router log for each IP datagram packet sent to the host:

%PKTS-3-NOSUPP:

: There is no workaround. [CSCdk67396]

Caveats for Version 26.2/Version 26.4 Modifications

This section describes possible unexpected behavior by Version 26.2. All the caveats listed in this section are resolved in Version 26.4. See Table 10 for the Cisco IOS software release that corresponds to the 26.4 microcode version.

After shutting down the CMCC physical interface, the channel mib variables, cipCardDtrBrdStatus, cipCardDtrBrdSignal and cipCardDtrBrdOnline, show the values prior to shutting down the interface instead of the current values. The information displayed on a show ext ch x/y subchannel command does not reflect the current state of the CMCC card. [CSCdj78246]
When running the CMCC Offload feature, the WRONGDESC error message was displayed if the host application issues a socket purge request using the host descriptor instead of the offload box socket descriptor. Socket purge requests are normally issued by VM/MVS/TPF TCP/IP applications when closing a socket.

: The message is misleading because the host application must sometimes use the host descriptor if it has not been notified of the offload box socket descriptor. This occurs when an error is detected during socket connection establishment. The WRONGDESC error message has been removed. [CSCdj92653]

During a brief TCP connection, the CMCC TCP/IP Offload feature fails to return a response to a Read/Recv type socket request causing the connection's host application to hang while waiting for a response.

: A window exists for brief TCP connections when a connection is made with TCP/IP on the CMCC and then broken (FIN received) before Offload has received and processed an Accept socket request from the host. In this situation, Offload misses the notification from TCP/IP that the connection had been terminated.
: There is no workaround. [CSCdk12291]

CMCC TN3270 Server's session switch feature (DLUR End Node) does not support parallel transmission groups (TGs). Only one LLC link is permitted between the end node and each of its adjacent APPN nodes.

: Parallel TGs can be used to provide redundancy. [CSCdk15431]

An architectural constraint causes CMCC TN3270 Server's DLUR to report only approximately 20 of the links to DLUS. This prevents LU-LU sessions from being routed over the unreported links. The topology database update (TDU) message reporting the links is limited to 1024 bytes. In order to report more links, DLUR has to send multiple TDUs.

: The workaround is that once the DLUR-DLUS pipe is established additional links will be reported if they become active. [CSCdk15446]

After changing or removing a configured virtual routing node (VRN) on a CMCC TN3270 Server dlur lsap, VTAM still shows the VRN D NET,TOPO,ORIG=dlurname,DEST=vrnname as OPER. VTAM shows the resource sequence number (RSN) as odd, indicating some uncertainty. This uncertainty is because DLUR fails to increment the RSN when sending the TDU (topology database update) generated by the VRN name change.

: A workaround is to close and then reopen the DLUS-DLUR pipe by using the VTAM V NET,INACT,ID=dlurname command. This will not disrupt the LU-LU sessions if the dependent PUs are configured ANS=CONT. New sessions cannot be established while the pipe is down. [CSCdk21067]

BADTIMER messages appear when running TN3270 Server. In this case, the messages appear because a TN3270 session is being negotiated or recently has been negotiated. The messages do not impact normal TN3270 Server operations.

: There is no workaround. [CSCdk21633]

During connection, the CMCC TN3270 Server delays sending DEVTYPE IS to the client for up to one minute. The client shows a blank screen during the delay if the client requests connection to a specific LU, and that LU only became available within the last six seconds. The delay is generally much shorter than one minute. It is only that long if there are clients in the network taking 30 to 40 seconds to respond to the Timing Mark.

: The workaround is to delay reconnecting for six seconds or to disconnect and reconnect immediately upon noticing the delay. [CSCdk28081]

When using a logon manager through CMCC TN3270 DLUR, the logon manager queues a session for the SLU to recover the session after the user has finished an application. VTAM sends UNBIND 02 (bind forthcoming). The CMCC TN3270 Server LU sends an UNBIND +RSP and the DLUR sends SESSEND with code 0A (SSCP gone). This forces SSCP to clean up the queued session from the logon manager. The expected PREALC-P session from the logon manager no longer exists. Using CMCC TN3270 Server DLUR EN capability, connect to a logon manager such as NetView access or TPX. [CSCdk29362]

Caveats for Version 26.1/Version 26.2 Modifications

This section describes possible unexpected behavior by Version 26.1. All the caveats listed in this section are resolved in Version 26.2. See Table 10 for the Cisco IOS software release that corresponds to the 26.2 microcode version.

When running CMCC TN3270 Server, the CMCC adapter reports fatal error code 35 and reloads. This error occurs when the CMCC adapter is running low on memory and a packet arrives that is larger than the SNA inbound request/response unit (RU) size. Typically, this error occurs when the router is running transports such as FDDI between the CMCC adapter and the client.

: The workaround is to increase the inbound RU size defined in the host logmode tables. [CSCdj76007]

With Offload, a socket can be closed in a way that the control block lingers for 60 seconds. If an attempt is made to re-establish the same connection before the 60 second period has expired, connection failure may occur. [CSCdj80952]
Stronger type checking was added to allow recovery from internal errors. These errors should not occur in normal use. [CSCdj90536]
When aborting and restarting a remote APPN mode while connectionless traffic is flowing, the following error messages are displayed:

%CMPCTG-3-LS_FSM_ERR: TG Name: CMPCTG -CnlsLs, Event ITestInd, State SCnlsConnected
%MBUF-0-MFREEx2: mfree: mbuf 845F0160 already free'ed from pc=8015D228 ra=80044040 @(pc=80057F20ra=80044040)


: This is a cosmetic problem. There is no workaround. [CSCdj91905]

The MSG_PEEK flag on the RECV, RECVwait, and RECVwaitFORfin socket requests was ignored (for example, RECV requests were treated like READ requests). This error causes transaction processing facility (TPF) offload applications to drop incoming data if MSG_PEEK was used with RECV requests.

: There is no workaround. [CSCdk00532]

The CMCC adapter fails because of corruption in SNA-related code. Very small timing windows, which occur in unreliable or high latency networks, can cause this failure. These networks create many asynchronous balanced mode extended (SABMEs), which can trigger this bug.

: The workaround is to tune the LLC timers to reflect true delays in the network. [CSCdk02032]

CMCC adapter crashes with fatal error 35. The CMCC adapter reports the following message:

bad LU on DISC...


: This error is caused by CSCdj81522. The crash may occur if a TN3270E client connects and does not negotiate bind-image.
: The workaround is to ensure that all clients support bind-image. [CSCdk02535]

Repeated inact/act of the XCA major node or the switched major node causes the TN3270 PUs to become stuck in a RESET/XID cycle.

: The workaround is to shut and then no shut the TN3270 Server. [CSCdk03985]

The CMCC TN3270 Server connects then disconnects a client. This occurs with LOGAPPL applications when the client sends data to the host application and the host's response to Notify reaches the server after the bind.

: The workaround is to reconnect. [CSCdk06887]

A connection can be terminated if the flowoff condition is reached. [CSCdk07022]
When the CMCC receives a corrupted XID3 message the CMCC adapter spontaneously reloads with the message:

%SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../mpc/mpcxid.C @ 66 - nextCv <= (Cv *) ((byte *) &fmtType + xidLength)

: The workaround is to fix the component that is generating the corrupted XID3 message. See CSCdk10071. [CSCdk08437]

During bulk transfer operations that move data to the host, throughput to the host is limited by overhead on the channel causing channel utilization to approach 100 percent. Use the show controller cbus command to determine the ECA utilization. The ECA statistic is updated once a minute.

: There is no workaround. [CSCdk08438]

The CMCC microcode reports a fatal error and reloads. This is an infrequent problem that occurs when there is a very small timing window. [CSCdk08533]
The client is disconnected when the host sends a DACTLU followed by an ACTLU. In VTAM through cross domain, the host can send a DACTLU followed by an ACTLU to clean up the LU session, but not to disconnect the LU session. [CSCdk08642]
The CMCC microcode reports a fatal error and reloads. This error occurs when unconnected PUs attempt to send XIDs and TEST frames to the host. The PU timer expires and corrupts the TN3270 Server timer-queue. This error occurs when the PU disconnects or when a NULL XID is about to be sent to the host.

: The workaround is to ensure that all PUs are either shut down or connected. [CSCdk09978]

When the connection to a host from the CMCC TN3270 Server is not via the channel, data corruption may occur, resulting in bad XIDs or binds being reported.

: There is no workaround. [CSCdk10071]

TN3270 user cannot log on because the keyboard is locked. The keyboard can lock if a TN3270 user presses an invalid AID key (such as PF or PA) before logging on to a host application. This does not occur with TN3270 clients or LOGAPPL'd LUs.

: The workaround is to locally clear the keyboard lock, if the client supports this feature. Otherwise, the user must disconnect and reconnect. [CSCdk10200]

The TN3270 Server refuses new TCP connections. This problem lasts for 2 to 20 minutes depending on the number of TCP requests and occurs when there is one-way network congestion between one or more clients and the server. The congestion direction must be from the server to the client. The congestion causes the client not to see the SYN/ACK coming from the server so the client resends the SYN.

: There is no workaround. [CSCdk11113]

When using TN3270 Server to connect to NetView when the NetView type ahead feature is used the LU-LU session can be stopped with a PROG MSG.

: The workaround is to recycle the LU in VTAM and restart the session.[CSCdk11361]

The CMCC adapter reports the IPC-NO-MEMD message and hangs. This occurs when CMCC adapter host communications are cut off before a hierarchical reset. [CSCdk11787]
CMCC TN3270 Server's DLUR session is unbound by DLUS with sense 1002 (RU length error) soon after the DLUR-DLUS pipe is established. This error occurs when 10 or more LLC links connected to DLUR generate a topology database update (TDU) to DLUS that exceeds the maximum RU size specified in the bind. The CP-CP session can fail with the same sense code for the same reason. In this case, the RU that exceeds the maximum RU size is the one specified in the locate that DLUR sends to find the DLUS.

: The workaround is to reduce the number of LLC links available to DLUR until the DLUR-DLUS pipe is established. [CSCdk11790]

When the MSG_PEEK flag is set on a RECV, RECVwait, or RECVwaitFORfin socket request, only the Offload message header and response header are returned to the host. The buffer length field in the Offload message header indicates MSG_PEEK data is present in the message but no data is sent to the host. This problem causes TPF offload applications to collect invalid data when accessing the MSG_PEEK data.

: There is no workaround. [CSCdk14244]

An error in the channel connection causes incorrect channel events, sometimes accompanied by LOGDATA, resulting in an SSI_ASSERT in attn_state_fsm in cta/cta.c with the following message:

SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta/cta.c @ 350 - FALSE

: There is no workaround. The user must cycle the XCA node. [CSCdk14424]

Caveats for Version 26.0/Version 26.1 Modifications

This section describes possible unexpected behavior by Version 26.0. All the caveats listed in this section are resolved in Version 26.1. See Table 10 for the Cisco IOS software release that corresponds to the 26.1 microcode version.

The CSNA responds to single router explorers with a specific router instead of an all routers explorer response. [CSCdi64614]
After certain low memory conditions, CMPC fails to recover. [CSCdi77372]
If the channel transport adapter device registers after the LLC2, the LLC2 informs the channel transport adapter of the connection count. [CSCdj32856]
Under certain conditions during memory allocation, the CIP can encounter a fatal error upon completion of a direct memory access transfer from or to MEMD. The fatal error code is typically 35 and it can coincide with the following message:

"RSP-3-RESTART: Interface Channel4/x, output stuck

: This error can be triggered by all software features with the exception of CLAW (IP datagram). It is more likely to occur with features that use a lot of memory, like the TN3270 Server. [CSCdj52480]

The CMCC Adapter reports a BSQ-x-SCB_CHAIN error message indicating that the read SCB chain is out of sequence. The problem is caused by unusual conditions during status presentation such as ESCON link errors. There is no workaround. [CSCdj61319]
The CMCC TCP/IP stack uses path MTU discovery (RFC 1191) to select the size of an outgoing IP packet. The algorithm used does not work if the IP layer adds IP options to the packet. If this situation occurs, TCP connections will hang and eventually timeout as soon as they try to send a segment larger than the smallest MTU in the path. Of all the problems that could lead to dropped TCP connections because of path MTU discovery, this is probably the least likely to occur. It is much more common that the problem is caused by an improperly designed network (for instance, a configuration with a bridge connecting two networks with different MTUs) or a misconfigured router that does not send an ICMP type "Destination unreachable" with code "Fragmentation needed but DF bit set".

To confirm that the IP option caused path MTU discovery not to work, get a sniffer trace to show the TCP segments from the CMCC Adapter as well as any ICMPs going back to it. If the router that sends the ICMPs is the CMCC router, collect the output of the following commands before and after a session is dropped:

show extended channel slot/port ip-stack
show extended channel slot/port icmp-stack
show extended channel slot/port tcp-stack
show ip traffic

[CSCdj65774]

In networks with a high volume of type 1 traffic (typically XIDs) the VTAM may combine many type 1 messages in a block, mistakenly causing the frame to appear badly formed and resulting in the ASSERT message and an automatic reload of the CMCC image. This problem occurs only with cip21-19 images and earlier. It does not happen with cip22-xx and higher.

: The workaround is to artificially limit the rate at which remote stations can connect by adding delays to a startup script. [CSCdj69281]

The kernel timeout function hits a fatal error when called with a negative time value. For example, this will happen if the Offload code gets a connect request with a timeout value of 0x7fffffff seconds.

: The workaround for the offload problem is to reconfigure for IP datagram mode. There is no workaround available for the bug in the kernel timeout function. [CSCdj72646]

On a Cisco 7000 router with a CIP, if all interfaces on the CIP are shut down when the CIP is loaded then the interprocess communication (IPC) subfacility will not work on the CIP even after no shut commands are issued for the interfaces. [CSCdj74844]
CMCC TN3270 sessions can linger for up to 10 minutes after the PU that the sessions ran through is shut down. This situation causes subsequent activations of the XCA major node to fail at the host because the CMCC adapter/SAP is not ready to open.

: A workaround is to issue a shut and then a no shut command on the TN3270 Server, causing the connections to be brought down quickly. [CSCdj76280]

Following a reload, microcode reload, or after a no shutdown command is issued, IBM's MVS TCPIP could complain about channel status of x'06'. This problem occurs following a resetting event condition where MVS IOS expected to have cleared the resetting event condition prior to the event actually occurring. The recovery mechanism that is already in place should recover from this error. If the channel interface is always shut down prior to a reload or microcode reload and this fix is applied, the host should stop complaining about the channel status of x'06'. [CSCdj78947]
The CMCC Adapter reloads spontaneously after the following error message:

%CTA-0-UNEXP_LSI_CMD: PA1 CTA C020-56 received LSI command 0x4D11 at 0x8042CA8C

: An unrecognized command code was recognized during communication between the LLC2 and CSNA components on the CMCC Adapter. This problem has never been detected in customer use, and has only been seen during the debugging of a new feature. However, the problem could be caused by configuring High Performance Routing (HPR) in a remote device.
: The workaround is to reconfigure the remote device to not specify HPR. [CSCdj79403]

The CMCC adapter reports fatal error code 35 when running TN3270. Before the fatal error, the CMCC adapter reports the following error message:

%CIP24-4-MSG: %TN3270S-4-NO_LU_SESSIONS: No LU sessions left for PUs at IP addr a.b.c.d, port x

: The problem may occur when the maximum-lu limit has been reached or when no more LUs are available at a given TN3270 Server listening point.
: The workaround is to increase the maximum-lu limit to a level that will not be reached during operation of the server. Also, the user should increase the number of PUs (really LUs) on each listening point. [CSCdj80602]

This problem results in the mainframe complaining about SIOCC2, which is a start I/O condition code 2. SIOCC2 is an indication that the device is busy for an extended period of time. Without this fix, the problem can be worked around by shutting down the CMCC interface and then bringing it up again. [CSCdj80886]
The CSNA responds to the TEST command when no SAP is active. This error may result in an end station trying to connect to a CMCC Adapter that has no connectivity to the host. This situation occurs when the CSNA interface is shut down manually or by other media problems (for example, a loose cable). [CSCdj80925]
With Offload, a socket can be closed in a way that the control block lingers for 60 seconds. If an attempt is made to re-establish the same connection before the 60 second period has expired, connection failure may occur. [CSCdj80952]
The CMCC Offload code prints an OFFL-0-WRONGFREE error message and hits a fatal error. This problem occurs if the read channel program ends in the middle of a socket response that spans more than one CLAW buffer and a halt subchannel is issued before the read channel program resumes.

: There is no workaround. [CSCdj80990]

During the recovery from certain error conditions in the CMCC TN3270 Server, the CMCC Adapter may sometimes report a Fatal error message (code=35) and spontaneously reload. [CSCdj81522]
The CMCC microcode may log the message "Fatal Error 35" and spontaneously reload. This situation can happen if the CMCC TN3270 Server session switch (DLUR) feature is being used and either the DLUR component or TN3270 Server is shut down or deconfigured while there are configured DLUR links. The workaround is to remove the DLUR links first, using no link name. [CSCdj82232]
CSNA fails to send disconnect when indication buffer is in use. This causes the following results: the end-station is not able to connect back in and if the connection is flow-off, it will remain in flow-off state. [CSCdj82785]
With certain TN3270 client software, the user can successfully establish an LU-to-LU session, but when the user enters the first data after the bind, the CMCC TN3270 Server disconnects the client. The CMCC TN3270 Server logs the fact that it received invalid Telnet data from the client.

: The problem occurs only with certain clients (for example, PC3270 and Attachmate) and when the user enters data before the host application sends out its first screen (most applications send a screen of data immediately after the bind, start data traffic).
: Because the problem only occurs in TN3270E mode, and some clients have an option to disable TN3270E mode, it is possible to bypass this problem in situations where TN3270E mode is not required. The alternatives are to use a different client or change the host application. [CSCdj84064]

When a TN3270E client connects to a CMCC TN3270 Server and enters a logon request, the server sometimes discards the request and sends a "-B" message to the client. This message becomes appended, on the screen, to the logon request data. If the user now presses enter, the host replies with the following message:

"unsupported function".

: This problem occurs if the same LU can be used by TN3270 and TN3270E clients.
: The workaround is to retry the logon request. [CSCdj84122]

In some customer environments, LOGDATA records that consist of multiple error messages can result from the mainframe not responding to device level activity for longer the 500 ms. The ESCON architecture states that this timeout value can range from 400 ms to 850 ms. To avoid some of the occurrences of LOGDATA, adjust the timeout from 500 ms to 800 ms. [CSCdj84218]
Additional information was added to the CMCC fatal error output report.This will help identify the events leading up to the failure. [CSCdj85568]
The channel transport architecture device is informed of the connection count irrespective of the order in which the channel transport adapter and LLC2 register. [CSCdj87846]
The CMCC DLUR repeatedly tries to establish CP-CP sessions with an incompatible NN server and fails to try other links for a NN server in the following conditions:
- When using CMCC TN3270 Server DLUR/DLUS with preferred-NNserver configured, when the DLUR is varied inactive by lu/cpname on the primary host and is defined statically on the primary, as cross-domain resource (CDRSC) or LU, but the link between the primary and the CMCC adapter is left active. This situation makes controlled SSCP takeover difficult.

: The workaround is to not configure preferred-NNserver. [CSCdj87854]

When running fast mainframe processors in offload mode, 10-20 percent of the channel bandwidth can be wasted by improperly handling the more-to-come processing within the CLAW protocol.

: There is no workaround. [CSCdj88636]

If a DMA write error occurs on the CIP in the process of sending a packet to the Cisco IOS software, the CIP could go into an infinite loop when the CIP interface the DMA error occurred on is shut down or the router performs a cbus complex restart. [CSCdj90280]
At show ext cn/2 pu/lu, some DDDLU LU names appear blank if Host applications send NULL SLU data in the bind.

: There is no workaround. [CSCdj90734]

Sometimes outbound data is randomly corrupted. This situation occurs with CMCC images in Cisco IOS Release 11.2(BC) if the TN3270 PUs are attached to VTAM by Token Ring (rather than channel attached) and some clients are running 3270 extended datastream. The problem usually occurs after file transfer of binary data.

: There is no workaround. [CSCdj90738]

A reset of the CIP virtual interface configured with LLC2 can cause MEMD buffer errors resulting in a cbus complex restart. [CSCdj90822]
The CMCC TN3270 Server command show extended ch x/2 tn3270 pu lu history may cause the router to reload. This situation happens if the LU's history buffer contains an event indicating that it received data from the client after it sent unbind to the client.

: The workaround is to not use the show lu history command. [CSCdj91756]

When the maximum-lu is reached, clients cannot connect for a few minutes. Usually only one listening point is affected.

: The workaround is to increase the maximum-lu in the configuration so that the maximum-lu will not be reached. [CSCdj92158]

The CMCC adapter returned User Datagram Protocol (UDP) data with 32 bytes less than expected to the host application under transaction processing facility (TPF). TCP/IP running Offload is not affected by this problem.

: There is no workaround. [CSCdj93915]

An attempt to activate an SNA local node where CMCC statements define the subchannels but for which there is no corresponding transmission group (TG) statement results in an unexpected reload.

: The workaround is to make sure the TG statement is configured before the associated CMCC statements. [CSCdk01922]

The CMCC adapter fails because of corruption in SNA-related code. Very small timing windows, which occur in unreliable or high latency networks, can cause this failure. These networks create many asynchronous balanced mode extended (SABMEs), which can trigger this bug.

: The workaround is to tune the LLC timers to reflect true delays in the network. [CSCdk02032]

CMCC adapter crashes with fatal error 35. The CMCC adapter reports the following message:

bad LU on DISC...


: This error is caused by CSCdj81522. The crash may occur if a TN3270E client connects and does not negotiate bind-image.
: The workaround is to ensure that all clients support bind-image. [CSCdk02535]

An attempt to configure more than 32 transmission groups (TG) using the CMCC may cause the CMCC to reload.

: The workaround is to limit the number of TG statements to 32. The changes incorporated by this DDTS increase the TG limit to 64. [CSCdk03733]

When the CMCC receives a corrupted XID3 message the CMCC adapter spontaneously reloads with the message:

%SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../mpc/mpcxid.C @ 66 - nextCv <= (Cv *) ((byte *) &fmtType + xidLength)

: The workaround is to fix the component that is generating the corrupted XID3 message. See CSCdk10071. [CSCdk08437]

When the connection to a host from the CMCC TN3270 Server is not via the channel, data corruption may occur, resulting in bad XIDs or Binds being reported.

: There is no workaround. [CSCdk10071]

CIP Microcode Release cip25 Caveats and Modifications

The following sections describe the caveats to current CIP microcode versions and the modifications made in current CIP microcode versions for cip25 microcode. The caveats listed apply to only the most serious problems. See Table 10 for the Cisco IOS software releases supported by cip25 microcode.

Caveats for Version 25.14/Version 25.15 Modifications

This section describes possible unexpected behavior by Version 25.14. All the caveats listed in this section are resolved in Version 25.15. See Table 10 for the Cisco IOS software release that corresponds to the 25.15 microcode version.

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The following message appears on the CMCC console:

: bad error-code 12 given
: This valid error code indicates a missing TERMSELF response. The code to log and format this specific error into a console message is missing.
: There is no workaround. [CSCdm55961]

CSNA devices fail with INOP messages during Interface Control Check (IFCC) status. This problem occurs when CLAW and CSNA are operating in high traffic conditions. It can occur in CMPC and CSNA, also.

: The workaround is to upgrade the CMCC microcode or to restart the external communication adapter (XCA) nodes. [CSCdm88239]

A BIND REQUEST or SSCP-LU message is expected but not received from the host within 30 seconds from the start of an SSCP-LU session for the CMCC Adapter TN3270 server session. If the condition continues for another 2 minutes, the LU is declared bad and the following error message appears:

%TN3270S-1-NO_BIND_REQ_RCVD: No BIND REQ received on LU [chars].[dec], 120*ONESEC

: This error and several others are logged as priority 1 (alert) messages in error reports. The priority level of the following error messages is now priority level 3:

NO_PSID_RSP_RCVD
NO_NTFY_AV_RSP_RCVD
NO_BIND_REQ_RCVD
NO_SDT_REQ_RCVD
NO_SDT_TMARK_RCVD
NO_UNBIND_TMARK_RCVD
NO_NTFY_UA_RSP_RCVD
NO_DYN_ACTLU_REQ_RCVD
NO_UNBIND_RSP_RCVD 
NO_TERMSELF_RSP_RCVD

: [CSCdm94788]

The VTAM to VTAM communication for APPN and FID2 hangs. The non-LLC2 HPR traffic does not hang. This problem occurs when both VTAMs are attached to the CIP running the CMPC feature.

: There is no workaround. [CSCdp00921]

A TCP/IP Offload select() for readability message indicates that there are no readable sockets in the descriptor list when in fact there are readable sockets available. This problem occurs when the TCP/IP connection fails while a select() for readability message is outstanding on the socket.

: There is no workaround. [CSCdp08103]

In duplicate MAC environments, idle Systems Application Architecture (SAA) gateway sessions terminate. SAA gateways time out the route to the CMCC MAC address and send receive ready poll (RR(P)) single route explorer (SRE) messages to rediscover the route. The CMCC Adapter is not in session and responds to the RR(P) messages with a disconnect mode final (DM(F)) message. The SAA gateway then disconnects the session. The RR(P) SRE is contrary to the LLC2 specifications.

: The workaround is to specify XTX=7 on the route.nlm. [CSCdp09295]

The CMCC adapter with TN3270 Server configured fails with fatal error message 35. This problem occurs when attempting to clear the TN3270 configuration from the router. After entering the no tn3270-server command while in configuration mode on the virtual channel interface, the microcode reloads and all the interfaces flap. The CSNA devices are removed from the running configuration and must be reconfigured.

: There is no workaround. [CSCdp24670]

The CMCC Adapter fails when running CSNA. This problem occurs while processing the detection of idle subchannel conditions.

: The workaround is to avoid creating idle subchannel conditions by not using the Z NET cancel command. Other possible workarounds include shutting down the router channel interface or removing the CSNA configuration statement before issuing the Z NET cancel command. [CSCdp31175]

Caveats for Version 25.13/Version 25.14 Modifications

This section describes possible unexpected behavior by Version 25.13. All the caveats listed in this section are resolved in Version 25.14. See Table 10 for the Cisco IOS software release that corresponds to the 25.14 microcode version.

OpenConnect has an informal extension to the Termtype in TN3270. When connecting through an OpenConnect TN3270 gateway, the client IP address is concatenated on the end with a percent (%) symbol.

: The CMCC TN3270 Server does not use this client IP address for matching on LU nailing statements in the configuration. [CSCdj44584]

MSG10 data from one LU might be seen on an LU already in session. This problem occurs when the TN3270 server remote MAC address resides on a different physical adapter or in a different physical machine, such as a front-end processor (FEP).

: The workaround is to make sure that the RMAC TN3270 server PU resides on the same CMCC adapter as the TN3270 Server. [CSCdm01837]

In a duplicate MAC environment, the CIP will continue to respond to a TEST command when the lines configured for the XCA are in use. This problem prevents other duplicate MAC adapters from responding to new requests.

: The workaround is to configure the maximum LLC or threshold to equal the number of XCA lines configured. [CSCdm29597]

The CMCC displays a RSP sense 089F0004 message when processing a REQACTPU message. The problem occurs when the VARY command is entered for DLUR PUs that have multiple PATH statements. The problem occurs because the DLUR sends a message to the DLUS containing an FQPCID value which DLUS created on an earlier acquisition of the PU. The host processes the FQPCID message as invalid.

: The workaround is to remove the PATH statements. [CSCdm42103]

Users are unable to start new CMCC sessions. The results of a show extended channel x/2 tn command show that some PUs are in an ACT/Busy state. The results of a VTAM display of the PU show that the PU is in an active state.

: The workaround is to reload the microcode. [CSCdm44279]

A user receives another user's session when both users are logged into the same applications owning region (AOR) in the Customer Information Control System and that AOR is manually cancelled.

: The workaround is to not disconnect a client during the logon process; that is, after requesting an application from the SSCP screen, but before establishing the LU-LU session with that application. [CSCdm51110]

The CMCC adapter fails with fatal error code 35 during the TN3270 Server shutdown. This problem occurs because the TN3270 Server PUs are not communicating with the host.

: A workaround is available. Contact the Cisco TN3270 Server development engineers for the interim fix. [CSCdm61159]

The CMCC TCP/IP Offload server socket application hangs. This problem occurs because an accept() socket request blocks after the select() indicated that the server socket was READABLE. The accept() socket request should have returned a so_error condition or the socket ID of a new client socket. In TPF Offload environments, where a single select() may monitor multiple sockets, this problem can cause the application to hang on multiple server sockets if an accept() is issued from the same thread that processes the select() response.

: The workaround is to close and re-open the server socket by restarting the server application on the host. [CSCdm63283]

The TN3270 Server running DLUR/DLUS fails with fatal error message code 35. This problem occurs because the TN3270 Server tries to invoke a SendACTLURSP using a NULL object reference.

: This fix adds a debug message to the log and marks the ACTLU as not processed.
: There is no workaround. [CSCdm69186]

The DLUR pipe between VTAM and the CMCC adapter hangs. This problem occurs when a large number of TN3270 Server TCP/IP requests (1000 per CMCC Adapter) arrive at the same time.

: The workaround is to space out the TCP/IP requests. [CSCdm75120]

The TN3270 Server fails with the following error message:

%DEBUGGER-0-FATAL_ERROR: Fatal error (code=35)

: This error occurs when the TN3270 Server is shut down while traffic is still transmitting. [CSCdm78261]

The unbind/bind sequence in the response time logic during a transaction does not reset the sample. This error causes an invalid response time which might be extremely large, depending upon the timing of the transaction. This problem occurs when the unbind keep is configured when the next transaction completes.

: There is no workaround. [CSCdm82521]

A select() message does not respond or times out when the peer closes the connection. This problem is more likely to occur when using TPF.

: The workaround is to delay the shutdown for 20 ms after the last send() message. [CSCdm85311]

The TN3270 IND$FILE file transfer performs poorly if the RU size is smaller than the maximum transmission unit (MTU). This problem occurs because the Cisco TN3270 Server uses the Nagle algorithm by default.

: The workaround is to set the RU size so that it is at least as big as the MTU on the file transfer path. [CSCdm86734]

The TN3270 Server overwrites 1 byte of a Read Partition Query (RPQ) response. The overwrite occurs because of a logic that was entered to capture a non-standard SYSREQ key sequence for non-TN3270E emulators.

: There is no workaround. [CSCdm88195]

A CMCC file transfer hangs or the keyboard stops working. The problem occurs when the IND$FILE uses structured fields and buffers that are 2000 bytes or greater. The keyboard is restored using the TN3270 write command instead of the structured field.

: The workaround is to use buffers that are 2000 bytes or less or non-structured fields (presentation space transfer. To enable the fix in CMCC releases cip27-4 and greater and xcpa27-4 and greater, you must configure the TN3270 tn-parameter code codevalue command with a code value of 7. [CSCdm93990]

Caveats for Version 25.12/Version 25.13 Modifications

This section describes possible unexpected behavior by Version 25.12. All the caveats listed in this section are resolved in Version 25.13. See Table 10 for the Cisco IOS software release that corresponds to the 25.13 microcode version.

An Offload application uses up resources and prevents traffic from going through the port adapter on the CMCC. This occurs in very unusual circumstances only, for example, when closing several thousand established TCP connections in a very short period of time.

: The workaround is to reload the CMCC microcode. [CSCdj08904]

A VTAM connect out completion time greater than 20 seconds causes unexpected connection failures and XCA major node failures. This failure occurs because VTAM overloads the PORT TIMER and, if the PORT TIMER is set too low, the LSA commands start to time out.

: VTAM version 4.3 introduced restrictions for the PORT TIMER value. The TIMER value cannot be less than the CMCC's T1 * N2. VTAM uses a hard-coded N2 value of 2. Before this fix, the CMCC reported a T1 value of 10. The VTAM documentation indicates that the T1 value is measured in tenths of a second. Therefore, a T1 value of 10 should equal 1 second. However, VTAM interprets the T1 value in seconds so a T1 value of 10 equals 10 seconds, not 1 second. VTAM then multiplies the value by 2 to get a minimum TIMER value of 20 seconds.
: The CMCC's reported T1 value is not the CMCC LLC T1 value. Because VTAM overloads the use of the PORT TIMER, do not adjust the CMCC's real LLC T1 value to alter the PORT TIMER. These adjustments can cause severe LLC2 problems.
: VTAM overloads the use of PORT TIMER. TIMER is used to set TEST request interval on connect outs. After each TEST request is sent, VTAM sets a timer equal to the PORT TIMER number of seconds and waits for a TEST response. If the TEST response is not received by VTAM before the timer expires, the next TEST request is sent. In CMCC scenarios, the first TEST request is a TEST local, the second is a spanning-route explorer.
: For the CMCC, most VTAM initiated LLC connections will not complete before the PORT TIMER seconds expire because the local TEST does not leave the CMCC's internal LAN. LLC connection setup requires a minimum of 20 seconds. VTAM will timeout on LSA commands if a response is not received within the set PORT TIMER value. For example, when VTAM sends a CONNECT request the CONNECT CONFIRM must be received before the PORT TIMER expires. The SABME and UA must be exchanged within the value set in PORT TIMER. If the SABME must be retried, the PORT ITMER might expire before the CONNECT CONFIRM is returned to VTAM.
: The workaround is to set the PORT TIMER value to 20 seconds or more unless the user is confident that the LSA commands will not timeout. [CSCdj45782]

When an online insertion and removal (OIR) of an IP card is performed on a Cisco 7500 series router with a CIP, the CIP processor utilization reaches maximum capacity (99 to 100 percent). This occurs when any IP card besides the CIP is inserted and removed online. If there are two CIPs in the router, an OIR of one CIP can effect the other.

: The workaround is to not OIR IP cards in a Cisco 7500 series router when the CIP is running. [CSCdj90287]

The TN3270 Server crashes with fatal error code 35. See caveat CSCdk02535. [CSCdk11968]
An error occurs when using the TN3270 Server to establish a connection to an application residing on a Migration Data Host (MDH) using a virtual routing node connection network.

: If a prior connection to the MDH from the server does not exist, it might take several attempts to make a connection. Once the initial connection is made, all subsequent connections will work.

Note IBM VTAM has opened an APAR for the 8002 sense portion of this problem. Users must get the APAR PTF from IBM to get MDH to work with the virtual routing node on the CMCC.

: [CSCdk37107]

If a user disconnects without properly logging off the mainframe, a new user can connect to those existing sessions. This problem occurs when accessing Customer Information Control System (CICS) applications through the TN3270 Server. [CSCdk48736]
Inconsistent keepalives occur when multiple TN3270 sessions are configured to the same server. When the sessions are idle for an hour or more, keepalives are not sent even though the keepalive value is set to 300 (5 minutes).

: The workaround is to restart the session. [CSCdk57453]

Dynamic LUs remain in a P-NFT/UA state when the TN3270 Server is configured. The LUs cannot be used again when in this state.

: The workaround is to deactivate the LU or the owning PU in VTAM. [CSCdk60263]

The TN3270 session between the client and TN3270 server is disconnected when the client issues the logoff command at the VTAM MSG10 screen. [CSCdk80609]
The TN3270 Server session disconnects after 150 seconds when the LOGON APPLID is not entered. In this case, there is no unformatted system services table (USSTAB).

: There is no workaround. [CSCdk83774]

Adding and removing PUs configured in TN3270 DLUR causes the CIP to reload with fatal error message 32. This failure occurs when a shutdown command is issued during high traffic periods on the server. The following messages appear immediately before the error:

: %CIP2-1-MSG: slot1 %TN3270S-1-RP_PU_CONFLICT:RP & CIP hold conflicting PU name(xxxxxxxx) or index(92)
: Where "xxxxxxxx" is the PU name.
: %CBUS-3-CIPCFGFAIL: Channel1/2: configuration command TN3270S_DLUR_PU_NEW cmd 18 failed
: %CIP2-0-MSG: slot1 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=32)
: The workaround is to perform the shutdown when the server load is light. [CSCdk83807]

When the TN3270 server is configured, entering the SYSREQ key followed by the logoff command does not return the user to the queued session. Instead, the VTAM MSG1 warning is displayed.

Other SYSREQ key errors that occur when the TN3270 server is configured include:

Pressing the SYSREQ key twice does not return the user to the LU-LU session. An LUSTAT is sent inbound on the second SYSREQ key entry.
Entering the logoff command incorrectly locks the session. SSCP-LU does not recognize the change direction in a sense data frame. This problem might occur in other remote cases.
LU-LU data shows up on an SSCP-LU session.
When responding to DACTLU in LU-LU or bound states, an inbound unbind should be sent. This inbound unbind was not working, but it was not evident because the client is normally disconnected which causes a SESSEND.

The workaround is to not use the SYSREQ key. [CSCdk83960]

The CIP running TN3270 fails with fatal error number 35 when a shut command is issued to the TN3270 server. This problem occurs when the shut command is issued and the TN3270 Server is operating at high capacity.

: The workaround is to issue the shut command only after the client traffic terminates. [CSCdk87658]

The TN3270 Server does not process the 0x016C6102 message from the client as a system request (SYSREQ). Therefore, the TN3270 Server does not send a logoff message to the system services control point (SSCP). This message should produce the sequence described in RFC 1647 (TN3270E), except that 0x016C6102 is used to indicate SYSREQ instead of Abort Output (FFF5).

: There is no workaround. [CSCdk89383]

CMCC devices with Bus and Tag connections do not activate properly when connected to an Amdahl 857 running the UTS operating system.

: There is no workaround. [CSCdk91964]

For extended periods of time, the write device for a CLAW connection experiences the same number of command retries and connects. Data throughput decreases significantly during these periods, but the connection is not lost. The connections and the command retries are displayed with the show extended channel slot/port command. This situation occurs when the channel operates at 95 percent or greater capacity for many hours.

: A workaround is to distribute the traffic to multiple boxes to avoid a channel capacity of 95 percent or greater. [CSCdk92004]

The CMCC TCP/IP Offload feature fails during select() processing when 28 or more sockets are defined in a single select request. If a select() request contains 28 or more socket descriptors in the descriptor list, the select() response is truncated after the offload message header. If the mainframe offload application does not validate the offload message header buffer_length field and detect the ZERO length response data, it may process random data in the memory which follows the offload message header as the start of response data and incorrectly interprets the select() response results.

: This problem does not occur when using select() under VM or MVS because select() is issued for one socket at a time. This problem occurs when using TPF if the select() request contains 28 or more socket descriptors.
: There is no workaround for this problem. This DDTS is a continuation of CSCdk86184. [CSCdm02126]

CIP response times and utilization increase when a large number of TN3270 Server connection attempts are made to the same source IP address. A large number of TCP no-op (NOP) messages are sent by the TN3270 Server to the clients.

: The fix limits the number of NOP messages sent to the clients. No configuration is required to enable the fix.
: There is no workaround. [CSCdm23252]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The CIP running TN3270 Server receives DSI562I error messages on the NetView console. The messages indicate that in the activate physical unit (ACTPU) control vector 80, unsolicited network management vector transport (NMVT) request units are not allowed. The CIP TN3270 Server still sends product-set identification (PSID) NMVT messages for VTAM PUs with only LUs.

: There is no workaround.
: To enable the fix in the cip24-13 microcode, the maximum-lu command must be added to the TN3270 Server configuration file. [CSCdm36152]

The CIP VTAM session hangs at the VTAM message10 menu. This problem occurs when the user is at the VTAM message10 menu and hits multiple blank Enter keys and when the inbound request unit on the SSCP-LU session is 256 bytes or greater.

: There is no workaround. [CSCdm37663]

Every other CIP TN3270 Server client connection fails. This problem occurs when clients are trying to connect at a slow rate and the TN3270 Server is operating with a light traffic load.

: There is no workaround. [CSCdm55234]

Caveats for Version 25.11/Version 25.12 Modifications

This section describes possible unexpected behavior by Version 25.11. The caveat listed in this section is resolved in Version 25.12. See Table 10 for the Cisco IOS software release that corresponds to the 25.12 microcode version.

If a CIP2 PCA (Bus and Tag) has an Altera FLEX chip (the large chip on the PCA daughter card) with a date code of 9601 or greater, the CIP will fail with parity errors shortly after the card is first installed. The date code on the PCA can be found only by looking for a code on the edge of the chip or the top heat sink area.

: The workaround is to upgrade to the recommended CIP microcode version which corresponds to your Cisco IOS software. [CSCdm28629]

Caveats for Version 25.10/Version 25.11 Modifications

This section describes possible unexpected behavior by Version 25.10. All the caveats listed in this section are resolved in Version 25.11. See Table 10 for the Cisco IOS software release that corresponds to the 25.11 microcode version.

If the maxpiu value of the csna command is set to 4096 bytes, a CSNA-LONGREC error occurs when the sum of the size of an inbound frame and the size of the LSA DataInd command exceeds 4 K. The CSNA-LONGREC error causes VTAM to terminate the connection.

: The workaround is to increase the maxpiu value, preferably to the default which is 20470 bytes. [CSCdk71668]

The CMCC TCP/IP Offload feature fails during select() processing when more than 27 sockets are defined in a single select request. Failures include premature response to select requests, corrupt descriptor list in the select response, and intermittent fatal error (code=32). These failures should only occur in Transaction Processing Facility (TPF) Offload environments.

: The workaround is to limit the number of sockets selected in a single select request to 27 or less. [CSCdk86184]

Caveats for Version 25.9/Version 25.10 Modifications

This section describes possible unexpected behavior by Version 25.9. All the caveats listed in this section are resolved in Version 25.10. See Table 10 for the Cisco IOS software release that corresponds to the 25.10 microcode version.

LLC_DUP_CCB error messages appear on the router console. This problem occurs when multiple remote stations are configured with the same local MAC or SAP. The following is a sample configuration:

interface Channel2/2
no ip address
no keepalive
lan TokenRing 2
  source-bridge 102 1 400
  adapter 2 4000.8001.0102
tg PAN12    llc token-adapter 2  10 rmac 4000.9000.beef
tg PAN2     llc token-adapter 2  10 rmac 4000.8000.beef

: The error occurs if PAN2 is in the LocatingRemoteLinkStation state and the local SNA associated with PAN2 is deactivated then reactivated.
: Possible workarounds include reconfiguring the router not to use the same local MAC or SAP, or deactivating then reactivating all local SNA nodes associated with that local MAC or SAP. Another workaround is to reload the microcode on the CMCC having the problem. [CSCdk41506]

Certain ESCON conditions lead to LOGDATA error messages that result in a fatal error. The fatal error dump can cause the LOGDATA error messages to be lost. The lost LOGDATA messages contain critical information needed to determine the cause of the problems. The fatal error information usually contains secondary information about the problem.

: A workaround is to use the CIP core dump feature that is available in Cisco IOS Release 11.2BC and later. This feature saves all CIP memory to a file on an FTP server. The missing LOGDATA can be extracted from the core dump file. The workaround applies only for the CIP. [CSCdj61710]

A print job hangs when printing through the CMCC TN3270 Server. The Host application sends an exception response on the end bracket chain followed by a CHASE.

: There is no workaround. [CSCdk27199]

The AS/400 TN client attempts to establish an IBM-3180-2 terminal-type session with a TN5250 terminal. If a session is not available, the AS/400 TN client automatically switches to the TN3270 with a 3270 terminal type. The AS/400 TN client receives an ACK message from the 3180 terminal type when expecting a 5250 datastream. Instead, the TN3270 server sends it a 3270 datastream. Because the CMCC TN3270 Server accepts the IBM-3180-2 terminal-type the client does not switch to TN3270. [CSCdk37980]
The OFFL-3-NOMEM2 and OFFL-3-REJSOCK error messages indicate the same problem and should be combined into one message called OFFL-3-NOMEMSOCK. [CSCdk39425]
The CMCC adapter crashes with a fatal error code 35 when reconfiguring an offload statement using the same IP address that was used in a previously configured offload connection. This error occurs if the CMCC adapter has not completed deconfiguration cleanup of the previous offload statement before the new offload statement is configured using the same IP address. For example, the current configuration is as follows:

: offload e200 50 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: Reconfigure the offload statement as follows:
: no offload e200 50 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: offload e100 52 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: To workaround, after deconfiguring the offload statement, exit the configuration and issue the show extended channel slot/port ip-stack ip address command. When the offload deconfiguration is complete for the indicated offload statement IP address, the output should indicate "...No IP statistics found". At this point the new offload statement using the same IP address can be configured.
: The following is an example configuration:
: rispix#show ext ch 0/1 ip-stack
: IP Statistics for IP Address 80.11.198.2
: Forwarding : no DefaultTTL : 64 InReceives : 0
: InHdrErrors : 0 InAddrErrors : 0 ForwDatagrams: 0
: InUnknownProtos: 0 InDiscards : 0 InDelivers : 0
: OutRequests : 0 OutDiscards : 0 OutNoRoutes : 0
: ReasmTimeout : 60 ReasmReqds : 0 ReasmOKs : 0
: ReasmFails : 0 FragOKs : 0 FragFails : 0
: FragCreates : 0 RoutingDiscards: 0

: rispix#config t
: Enter configuration commands, one per line. End with CNTL/Z.
: rispix(config)#in ch 0/1
: rispix(config-if)#no offload e200 50
: rispix(config-if)#end
: rispix#
: 01:22:25: %SYS-5-CONFIG_I: Configured from console by console
: rispix#show ext ch 0/1 ip-stack
: ...No IP statistics found

: [CSCdk45042]

The TCP connection is closed (a FIN sent) before all data is sent. The remaining data (1 to 12 bytes) is sent after the connection is closed with another FIN. This problem occurs only with TCP connections that include TCP options in the TCP header and if the remaining data to be sent on the connection will fill up the packet before taking into account the length of the TCP options (12 bytes). This problem occurs when using the TCP large window support, which utilizes the TCP Timestamp option, implemented per RFC 1323.

: The workaround is to complete the following tasks:

Step 1 Log into the CMCC console:

if-con <CCMCC Slot> c

Step 2 Display the current state of this RFC:

ipconf <Offload IP Address> tcp_rfc1323

Step 3 Disable this RFC:

ipconf <Offload IP Address> tcp_rfc1323 off

Step 4 Verify the configuration change using Step 2. This RFC can be re-enabled, if necessary, using the same command but with the "on" option.

ipconf <Offload IP Address> tcp_rfc1323 on

Step 5 Exit the CMCC console:

quit (CIP21-x/CIP204-x releases)
if-quit or ^C^C^C (CIP22-x/CIP205-x and all later releases or XCPA26-x/XCPA214-x and all later releases)

: Unlike configuration commands issued from the router console, this CMCC configuration command is not retained if the CMCC or the router reloads or crashes and reloads. [CSCdk57139]

When running the CMCC TN3270 Server, LU 1 print jobs hang if the print application sends the RU chains as EXR (exception response) and the connection is running over a RFC1646-style TN3270 print connection.

: The workaround is to print the job using LU 3 printing or to reconfigure the print application to send the SNA RU chains with DR (definite response) requested. [CSCdk59063]

Caveats for Version 25.8/Version 25.9 Modifications

This section describes possible unexpected behavior by Version 25.8. All the caveats listed in this section are resolved in Version 25.9. See Table 10 for the Cisco IOS software release that corresponds to the 25.9 microcode version.

After shutting down the CMCC physical interface, the channel mib variables, cipCardDtrBrdStatus, cipCardDtrBrdSignal and cipCardDtrBrdOnline, show the values prior to shutting down the interface instead of the current values. The information displayed on a show ext ch x/y subchannel command does not reflect the current state of the CMCC card. [CSCdj78246]
When running the CMCC Offload feature, the WRONGDESC error message was displayed if the host application issues a socket purge request using the host descriptor instead of the offload box socket descriptor. Socket purge requests are normally issued by VM/MVS/TPF TCP/IP applications when closing a socket.

: The message is misleading because the host application must sometimes use the host descriptor if it has not been notified of the offload box socket descriptor. This occurs when an error is detected during socket connection establishment. The WRONGDESC error message has been removed. [CSCdj92653]

During a brief TCP connection, the CMCC TCP/IP Offload feature fails to return a response to a Read/Recv type socket request causing the connection's host application to hang while waiting for a response.

: A window exists for brief TCP connections when a connection is made with TCP/IP on the CMCC and then broken (FIN received) before Offload has received and processed an Accept socket request from the host. In this situation, Offload misses the notification from TCP/IP that the connection had been terminated.
: There is no workaround. [CSCdk12291]

CMCC TN3270 Server's session switch feature (DLUR End Node) does not support parallel transmission groups (TGs). Only one LLC link is permitted between the end node and each of its adjacent APPN nodes.

: Parallel TGs can be used to provide redundancy. [CSCdk15431]

An architectural constraint causes CMCC TN3270 Server's DLUR to report only approximately 20 of the links to DLUS. This prevents LU-LU sessions from being routed over the unreported links. The topology database update (TDU) message reporting the links is limited to 1024 bytes. In order to report more links, DLUR has to send multiple TDUs.

: The workaround is that once the DLUR-DLUS pipe is established additional links will be reported if they become active.[CSCdk15446]

After changing or removing a configured virtual routing node (VRN) on a CMCC TN3270 Server dlur lsap, VTAM still shows the VRN D NET,TOPO,ORIG=dlurname,DEST=vrnname as OPER. VTAM shows the resource sequence number (RSN) as odd, indicating some uncertainty. This uncertainty is because DLUR fails to increment the RSN when sending the TDU (topology database update) generated by the VRN name change.

: A workaround is to close and then reopen the DLUS-DLUR pipe by using the VTAM V NET,INACT,ID=dlurname command. This will not disrupt the LU-LU sessions if the dependent PUs are configured ANS=CONT. New sessions cannot be established while the pipe is down. [CSCdk21067]

BADTIMER messages appear when running TN3270 Server. In this case, the messages appear because a TN3270 session is being negotiated or recently has been negotiated. The messages do not impact normal TN3270 Server operations.

: There is no workaround. [CSCdk21633]

During connection, the CMCC TN3270 Server delays sending DEVTYPE IS to the client for up to one minute. The client shows a blank screen during the delay if the client requests connection to a specific LU, and that LU only became available within the last six seconds. The delay is generally much shorter than one minute. It is only that long if there are clients in the network taking 30 to 40 seconds to respond to the Timing Mark.

: The workaround is to delay reconnecting for six seconds or to disconnect and reconnect immediately upon noticing the delay. [CSCdk28081]

When using a logon manager through CMCC TN3270 DLUR, the logon manager queues a session for the SLU to recover the session after the user has finished an application. VTAM sends UNBIND 02 (bind forthcoming). The CMCC TN3270 Server LU sends an UNBIND +RSP and the DLUR sends SESSEND with code 0A (SSCP gone). This forces SSCP to clean up the queued session from the logon manager. The expected PREALC-P session from the logon manager no longer exists. Using CMCC TN3270 Server DLUR EN capability, connect to a logon manager such as NetView access or TPX. [CSCdk29362]

Caveats for Version 25.7/Version 25.8 Modifications

This section describes possible unexpected behavior by Version 25.7. All the caveats listed in this section are resolved in Version 25.8. See Table 10 for the Cisco IOS software release that corresponds to the 25.8 microcode version.

When running CMCC TN3270 Server, the CMCC adapter reports fatal error code 35 and reloads. This error occurs when the CMCC adapter is running low on memory and a packet arrives that is larger than the SNA inbound request/response unit (RU) size. Typically, this error occurs when the router is running transports such as FDDI between the CMCC adapter and the client.

: The workaround is to increase the inbound RU size defined in the host logmode tables. [CSCdj76007]

With Offload, a socket can be closed in a way that the control block lingers for 60 seconds. If an attempt is made to re-establish the same connection before the 60 second period has expired, connection failure may occur. [CSCdj80952]
Sometimes outbound data is randomly corrupted. This situation occurs with CMCC images in Cisco IOS Release 11.2(BC) if the TN3270 PUs are attached to VTAM by Token Ring (rather than channel attached) and some clients are running 3270 extended datastream. The problem usually occurs after file transfer of binary data.

: There is no workaround. [CSCdj90738]

When aborting and restarting a remote APPN mode while connectionless traffic is flowing, the following error messages are displayed:

%CMPCTG-3-LS_FSM_ERR: TG Name: CMPCTG -CnlsLs, Event ITestInd, State SCnlsConnected
%MBUF-0-MFREEx2: mfree: mbuf 845F0160 already free'ed from pc=8015D228 ra=80044040 @(pc=80057F20ra=80044040)


: This is a cosmetic problem. There is no workaround. [CSCdj91905]

The MSG_PEEK flag on the RECV, RECVwait, and RECVwaitFORfin socket requests was ignored (for example, RECV requests were treated like READ requests). This error causes transaction processing facility (TPF) offload applications to drop incoming data if MSG_PEEK was used with RECV requests.

: There is no workaround. [CSCdk00532]

An attempt to activate an SNA local node where CMCC statements define the subchannels but for which there is no corresponding transmission group (TG) statement results in an unexpected reload.

: The workaround is to make sure the TG statement is configured before the associated CMCC statements. [CSCdk01922]

The CMCC adapter fails because of corruption in SNA-related code. Very small timing windows, which occur in unreliable or high latency networks, can cause this failure. These networks create many asynchronous balanced mode extended (SABMEs), which can trigger this bug.

: The workaround is to tune the LLC timers to reflect true delays in the network. [CSCdk02032]

CMCC adapter crashes with fatal error 35. The CMCC adapter reports the following message:

bad LU on DISC...


: This error is caused by CSCdj81522. The crash may occur if a TN3270E client connects and does not negotiate bind-image.
: The workaround is to ensure that all clients support bind-image. [CSCdk02535]

An attempt to configure more than 32 transmission groups (TG) using the CMCC may cause the CMCC to reload.

: The workaround is to limit the number of TG statements to 32. The changes incorporated by this DDTS increase the TG limit to 64. [CSCdk03733]

Repeated inact/act of the XCA major node or the switched major node causes the TN3270 PUs to become stuck in a RESET/XID cycle.

: The workaround is to shut and then no shut the TN3270 Server. [CSCdk03985]

The CMCC TN3270 Server connects then disconnects a client. This occurs with LOGAPPL applications when the client sends data to the host application and the host's response to Notify reaches the server after the bind.

: The workaround is to reconnect. [CSCdk06887]

A connection can be terminated if the flowoff condition is reached. [CSCdk07022]
When the CMCC receives a corrupted XID3 message the CMCC adapter spontaneously reloads with the message:

%SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../mpc/mpcxid.C @ 66 - nextCv <= (Cv *) ((byte *) &fmtType + xidLength)

: The workaround is to fix the component that is generating the corrupted XID3 message. See CSCdk10071. [CSCdk08437]

During bulk transfer operations that move data to the host, throughput to the host is limited by overhead on the channel causing channel utilization to approach 100 percent. Use the show controller cbus command to determine the ECA utilization. The ECA statistic is updated once a minute.

: There is no workaround. [CSCdk08438]

The CMCC microcode reports a fatal error and reloads. This is an infrequent problem that occurs when there is a very small timing window. [CSCdk08533]
Client disconnected when the host sent dactlu followed by actlu. In VTAM through cross domain, the host can send dactlu followed by actlu to clean up the lu session, but not to disconnect the lu session. [CSCdk08642]
The CMCC microcode reports a fatal error and reloads. This occurs when unconnected PUs attempt to send XIDs and TEST frames to the host. The PU timer expires and corrupts the TN3270 Server timer-queue. This occurs either when the PU disconnects or when a NULL XID is about to be sent to the host.

: The workaround is to ensure that all PUs are either shutdown or connected. [CSCdk09978]

When the connection to a host from the CMCC TN3270 Server is not via the channel, data corruption may occur, resulting in bad XIDs or Binds being reported.

: There is no workaround. [CSCdk10071]

TN3270 user cannot log on because the keyboard is locked. The keyboard can lock if a TN3270 user presses an invalid AID key (such as PF or PA) before logging on to a host application. This does not occur with TN3270 clients or LOGAPPL'd LUs.

: The workaround is to locally clear the keyboard lock, if the client supports such a feature. Otherwise, the user must disconnect and reconnect. [CSCdk10200]

The TN3270 Server refuses new TCP connections. This lasts for 2 to 20 minutes depending on the number of TCP requests. This occurs when there is one-way network congestion between one or more clients and the server. The congestion direction must be from the server to the client. The congestion causes the client not to see the SYN/ACK coming from the server and the client resends the SYN.

: There is no workaround. [CSCdk11113]

When usingTN3270 Server to connect to NetView when the NetView type ahead feature is used the LU-LU session can be stuck with a PROG MSG. Customer needs to recycle LU to continue.

: The workaround is to recycle the LU in VTAM and restart the session.[CSCdk11361]

The CMCC adapter reports the IPC-NO-MEMD message and hangs. This occurs when CMCC adapter host communications have been cut off before a hierarchical reset. [CSCdk11787]
CMCC TN3270 Server's DLUR session is unbound by DLUS with sense 1002 (RU length error) soon after the DLUR-DLUS pipe is established. This occurs when 10 or more LLC links connected to DLUR generate a topology database update (TDU) to DLUS that exceeds the maximum RU size specified in the Bind. The CP-CP session can fail with the same sense code for the same reason. In this case, the RU that exceeds the maximum RU size is the one specified in the locate which DLUR sends to find the DLUS.

: The workaround is to reduce the number of LLC links available to DLUR until the DLUR-DLUS pipe is established. [CSCdk11790]

When the MSG_PEEK flag was set on a RECV, RECVwait, or RECVwaitFORfin socket request, only the Offload message header and response header were returned to the host. The buffer length field in the Offload message header indicated MSG_PEEK data was present in the message but no data was sent to the host. This problem causes TPF offload applications to collect invalid data when accessing the MSG_PEEK data.

: There is no workaround. [CSCdk14244]

An error in the channel connection causes incorrect channel events, sometimes accompanied by LOGDATA, resulting in an SSI_ASSERT in attn_state_fsm in cta/cta.c with the following message:

SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta/cta.c @ 350 - FALSE

: There is no workaround. The user must cycle the XCA node. [CSCdk14424]

Caveats for Version 25.6/Version 25.7 Modifications

This section describes possible unexpected behavior by Version 25.6. All the caveats listed in this section are resolved in Version 25.7. See Table 10 for the Cisco IOS software release that corresponds to the 25.7 microcode version.

If the channel transport adapter device registers after the LLC2, the LLC2 informs the channel transport adapter of the connection count. [CSCdj32856]
Under certain conditions during memory allocation, the CIP can encounter a fatal error upon completion of a direct memory access transfer from or to MEMD. The fatal error code is typically 35 and it can coincide with the following message:

"RSP-3-RESTART: Interface Channel4/x, output stuck

: This error can be triggered by all software features with the exception of CLAW (IP datagram). It is more likely to occur with features that use a lot of memory, like the TN3270 Server. [CSCdj52480]

The CMCC Adapter reports a BSQ-x-SCB_CHAIN error message indicating that the read SCB chain is out of sequence. The problem is caused by unusual conditions during status presentation such as ESCON link errors. There is no workaround. [CSCdj61319]
The CMCC TCP/IP stack uses path MTU discovery (RFC 1191) to select the size of an outgoing IP packet. The algorithm used does not work if the IP layer adds IP options to the packet. If this situation occurs, TCP connections will hang and eventually timeout as soon as they try to send a segment larger than the smallest MTU in the path. Of all the problems that could lead to dropped TCP connections because of path MTU discovery, this is probably the least likely to occur. It is much more common that the problem is caused by an improperly designed network (for instance, a configuration with a bridge connecting two networks with different MTUs) or a misconfigured router that does not send an ICMP type "Destination unreachable" with code "Fragmentation needed but DF bit set".

show extended channel slot/port ip-stack
show extended channel slot/port icmp-stack
show extended channel slot/port tcp-stack
show ip traffic

[CSCdj65774]

In networks with a high volume of type 1 traffic (typically XIDs) the VTAM may combine many type 1 messages in a block, mistakenly causing the frame to appear badly formed and resulting in the ASSERT message and an automatic reload of the CMCC image. This problem occurs only with cip21-19 images and earlier. It does not happen with cip22-xx and higher.

: The workaround is to artificially limit the rate at which remote stations can connect by adding delays to a startup script. [CSCdj69281]

The kernel timeout function hits a fatal error when called with a negative time value. For example, this will happen if the Offload code gets a connect request with a timeout value of 0x7fffffff seconds.

: The workaround for the offload problem is to reconfigure for IP datagram mode. There is no workaround available for the bug in the kernel timeout function. [CSCdj72646]

On a Cisco 7000 router with a CIP, if all interfaces on the CIP are shut down when the CIP is loaded then the interprocess communication (IPC) subfacility will not work on the CIP even after no shut commands are issued for the interfaces. [CSCdj74844]
CMCC TN3270 sessions can linger for up to 10 minutes after the PU that the sessions ran through is shut down. This situation causes subsequent activations of the XCA major node to fail at the host because the CMCC adapter/SAP is not ready to open.

: A workaround is to issue a shut and then a no shut command on the TN3270 Server, causing the connections to be brought down quickly. [CSCdj76280]

Following a reload, microcode reload, or after a no shutdown command is issued, IBM's MVS TCPIP could complain about channel status of x'06'. This problem occurs following a resetting event condition where MVS IOS expected to have cleared the resetting event condition prior to the event actually occurring. The recovery mechanism that is already in place should recover from this error. If the channel interface is always shut down prior to a reload or microcode reload and this fix is applied, the host should stop complaining about the channel status of x'06'. [CSCdj78947]
The CMCC Adapter reloads spontaneously after the following error message:

%CTA-0-UNEXP_LSI_CMD: PA1 CTA C020-56 received LSI command 0x4D11 at 0x8042CA8C

: An unrecognized command code was recognized during communication between the LLC2 and CSNA components on the CMCC Adapter. This problem has never been detected in customer use, and has only been seen during the debugging of a new feature. However, the problem could be caused by configuring High Performance Routing (HPR) in a remote device.
: The workaround is to reconfigure the remote device to not specify HPR. [CSCdj79403]

This problem results in the mainframe complaining about SIOCC2, which is a start I/O condition code 2. SIOCC2 is an indication that the device is busy for an extended period of time. Without this fix, the problem can be worked around by shutting down the CMCC interface and then bringing it up again. [CSCdj80886]
The CSNA responds to the TEST command when no SAP is active. This error may result in an end station trying to connect to a CMCC Adapter that has no connectivity to the host. This situation occurs when the CSNA interface is shut down manually or by other media problems (for example, a loose cable). [CSCdj80925]
The CMCC Offload code prints an OFFL-0-WRONGFREE error message and hits a fatal error. This problem occurs if the read channel program ends in the middle of a socket response that spans more than one CLAW buffer and a halt subchannel is issued before the read channel program resumes.

: There is no workaround. [CSCdj80990]

During the recovery from certain error conditions in the CMCC TN3270 Server, the CMCC Adapter may sometimes report a Fatal error message (code=35) and spontaneously reload. [CSCdj81522]
The CMCC microcode may log the message "Fatal Error 35" and spontaneously reload. This situation can happen if the CMCC TN3270 Server session switch (DLUR) feature is being used and either the DLUR component or TN3270 Server is shut down or deconfigured while there are configured DLUR links. The workaround is to remove the DLUR links first, using no link name. [CSCdj82232]
CSNA fails to send disconnect when indication buffer is in use. This causes the following results: the end-station is not able to connect back in and if the connection is flow-off, it will remain in flow-off state. [CSCdj82785]
With certain TN3270 client software, the user can successfully establish an LU-to-LU session, but when the user enters the first data after the bind, the CMCC TN3270 Server disconnects the client. The CMCC TN3270 Server logs the fact that it received invalid Telnet data from the client.

: The problem occurs only with certain clients (for example, PC3270 and Attachmate) and when the user enters data before the host application sends out its first screen (most applications send a screen of data immediately after the bind, start data traffic).
: Because the problem only occurs in TN3270E mode, and some clients have an option to disable TN3270E mode, it is possible to bypass this problem in situations where TN3270E mode is not required. The alternatives are to use a different client or change the host application. [CSCdj84064]

When a TN3270E client connects to a CMCC TN3270 Server and enters a log on request, the server sometimes discards the request and sends a "-B" message to the client. This message becomes appended, on the screen, to the log on request data. If the user now presses enter, the host replies with the following message:

"unsupported function".

: This problem occurs if the same LU can be used by TN3270 and TN3270E clients.
: The workaround is to retry the log on request. [CSCdj84122]

In some customer environments, LOGDATA records that consist of multiple error messages can result from the mainframe not responding to device level activity for longer the 500 ms. The ESCON architecture states that this timeout value can range from 400 ms to 850 ms. To avoid some of the occurrences of LOGDATA, adjust the timeout from 500 ms to 800 ms. [CSCdj84218]

Caveats for Version 25.5/Version 25.6 Modifications

This section describes possible unexpected behavior by Version 25.5. All the caveats listed in this section are resolved in Version 25.6. See Table 10 for the Cisco IOS software release that corresponds to the 25.6 microcode version.

For Offload and CLAW devices, if the write device (odd device number) on the mainframe is misconfigured to talk to the read subchannel (even device number), the CIP could crash with an SCBNRDY error message.

: The workaround is to properly configure the devices on the mainframe. The most likely cause of the problem is in the virtual machine (VM) if the write device is attached to the read subchannel. In this scenario, detach both devices (read and write) and reattach them to the correct subchannel. [CSCdj23802]

With a TN3270 Server, if a CIP application shuts down its own TCP connection, it sends out a FIN (finish) segment. If it never receives a FIN from the peer, the local side of the connection will stay in FIN_WAIT_2 state even after the application closes the socket completely. [CSCdj48609]
Memory is leaked by the CIP TCP/IP if a direct memory access (DMA) controller write operation detects an error. [CSCdj48929]
When a TN3270 client is powered down without terminating the TCP/IP session with the CIP, the TIMING-MARK and TCP retransmissions tear down the connection. If a client is unable to work with TIMING-MARK and uses a previously specified LU name then it will be unable to reconnect. [CSCdj51696]
Under certain conditions during memory allocation, the CIP can encounter a fatal error upon completion of a direct memory access transfer from or to MEMD. The fatal error code is typically 35 and it can coincide with the following message:

"RSP-3-RESTART: Interface Channel4/x, output stuck

: This error can be triggered by all software features with the exception of CLAW (IP datagram). It is more likely to occur with features that use a lot of memory, like the TN3270 Server. [CSCdj52480]

If several of the TN3270 Server PUs are configured under DLUR and are INACT or unknown at the host, then the process of stabilizing the DLUR-DLUS pipe can be prolonged thereby preventing PUs from activating.

: This situation occurs with certain patterns of "good" and "bad" PUs. For example, out of a total of six PUs, the first five could be INACT at the host and the sixth could be CONCT.
: The workaround is to shut down the PUs on the CIP or make them active at the host. [CSCdj54138]

When the customer attempts an initial program load (IPL) to a Hitachi mainframe running IBM VSE 1.4.1 with Connectivity Systems TCPIP stack for VSE, the system goes into a loop and the CIP appears to be in an offline state.

: After several attempts to trace the problem on the CIP, the following trace indicates the CIP failed to respond:

Channel (F7)             Cisco/CIP        Explanation
 
   ALA    ==================>         (CH sends Aquire Link Address) 
          
          <=================   ALA    (CU sends Aquire Link Address) 
 
   ACK    =================>          (CH acknowledges request from CU) 
 
           End of Communication       (CU never acknowledges request from CH)

: [CSCdj55448]

During peak times of logon-rate and network congestion, end users cannot access the CIP TN3270 Server for extended periods of time (5 to 15 minutes). Existing TN3270 sessions exhibit normal response times during these periods, but new connections are locked out. [CSCdj56273]
The SNA sense code 2003 is sent to the host that is causing the client to disconnect. If the host has the direction and the client sends data, the data will be queued. Later, when the host sends data with the EBI bit on, the client data will be sent. However, subsequent data from the host will get a negative response.

: The workaround is to reconnect the client. [CSCdj58664]

A TN3270E disconnects after the host sends an unbind message. When the user presses the F3 key to end the LU-LU session, the session is disconnected instead.

: The workaround is to reconnect the client. [CSCdj59985]

If CIP TN3270-Server DLUR is configured with a link to VTAM over a CMPC tg, the link will not activate and the XID negotiation will fail.

: With the DLUR EN active, inact force the vtam local node by issuing the /v net,inact,id=mvsln,f command. Then try to activate the local node by issuing the /v net,act,id=mvsln command
: The workaround is to issue a shut command then no shut command on the TN3270 Server DLUR. Alternately, do not configure the link from DLUR EN to VTAM. Configure it only from VTAM to DLUR EN. [CSCdj63054]

There is a CIP fatal error in the IP Input task when running Offload or TN3270 Server.

: This bug occurs only if a new IP fragment received by the TCP/IP stack completely overlaps a fragment that is already on the reassembly queue. As a result of the overlap, the fragment on the queue is freed. There is a bug in the code where the memory used to hold this IP fragment is accessed after it is freed. This access can lead to a fatal error if the IP Input task gets preempted at the right time.
: The workaround is to apply an outbound access list that denies IP fragments on the channel interface. This action may break UDP applications and TCP applications that do not use path MTU discovery. If an IP node generates them, it should be sufficient to block fragments from just that IP source address. [CSCdj63361]

While parsing messages, the offload code does not check each message for proper formatting. Corrupted blocks appear to contain a large number of Offload messages (up to 128 per 4 KB CLAW frame). Because there are not enough control blocks to handle this many messages, the CIP hits a fatal error. This problem should not occur if Offload messages are properly formatted.

: There is no workaround. [CSCdj64309]

In an environment where there are ESCON link-level errors occurring, the CIP may log the following message and reload:

%CIP25-0-MSG: %CCA-0-DEV_ERR2: Device error but no active defined device.

: The CIP's ESCON processor may lock up in the middle of connection recovery following link-level errors. The neighboring ESCON link-level facility (host or director) will report a sequence timeout followed by a not operational sequence (NOS) detected.
: There is no workaround. [CSCdj64563]

An RFC 1646 printer hangs when a client sends a negative response before it receives the whole frame and the negative response is not sent to the host.

: The workaround is to reconnect the printer. [CSCdj65302]

Any IP packet generated by the CIPs TCP/IP stack that contains IP options could contain an invalid TCP, UDP, or ICMP checksum. The destination host will discard these packets because the checksum does not match. [CSCdj65535]
The show extended channel slot/2 tg command always displays HPR = NO. There is no workaround. [CSCdj66635]
After a few thousand disconnects, the VTAM gets the following error message:

IST565I..<nocmdBold>

: When the VTAM receives a NMVT power-off PSID, it may lose buffers. The workaround is to enter opt70 nmvt_psid 0 at the console port to disable sending the PSID. [CSCdj66921]

If clients do not set the response sequence, the TN3270E printer hangs because the host does not get a response.

: The workaround is to change client software. [CSCdj66924]

When a PC tries to bring up a session, the VTAM rejects it with the following connection request denied error message:

IST381I  AM SC EXIT FOR ID = T7751    FAILED - CANNOT DEFINE NODE
IST680I  CONNECTION REQUEST DENIED - ID = T7751    INVALID NETWORK NAME
IST1394I  CPNAME = NETVGI.T7751       STATION ID = 020005D07751
IST081I  LINE NAME = L0750C93, LINE GROUP = GXCA750 , MAJNOD = XCA750
IST314I  END


: There is no workaround.
: When a large number of sessions are abnormally terminated because of an invalid configuration of LLC parameters, the CSNA terminates the connection, but fails to notify VTAM. This results in the VTAM continuing to hang on to the session and the end stations trying to reconnect to the host. [CSCdj68124]

CSNA has a restriction on the usage of SAP value 6, which is reserved for DODIP (Department of Defense IP). This restriction has been removed. [CSCdj68133]
A CSNA user can regulate new connections by lowering the connection threshold below the maximum LLC originally specified. This change results in the CSNA not responding to the test frame from an end-station when session counts exceed the connection threshold. No new connection is brought up through the CIP. [CSCdj68517]
In networks with a high volume of type 1 traffic (typically XIDs) the VTAM may combine many type 1 messages in a block, mistakenly causing the frame to appear badly formed and resulting in the ASSERT message and an automatic reload of the CMCC image. This problem occurs only with cip21-19 images and earlier. It does not happen with cip22-xx and higher.

: The workaround is to artificially limit the rate at which remote stations can connect by adding delays to a startup script. [CSCdj69281]

CIP microcode reloads occasionally when the user issues a shut command then a no shut command when in the CIP TN3270 Server command mode. This problem occurs only when there are active TN3270 sessions connected to the CIP.

: The workaround is to shut each of the PUs associated with the TN3270 Server and then issue a shut command and a no shut command on the TN3270 Server. Issue a no shut command on the PUs again. [CSCdj69368]

When the offload code on the CIP and the TCP/IP offload code on the mainframe begin to communicate, they exchange restart requests and responses. Under certain conditions, the restart requests and responses from the CIP could contain invalid data. The mainframe will react to this condition with the following error message:

Unexpected result from offload device ..

: The mainframe will dump the offending offload message that contains the text "Data runs off end of buffer". There is no functional impact. [CSCdj69527]

If the CIP runs low on memory while the CIP TN3270 Server DLUR (SNA session switch) function is in use, then the CIP may reload spontaneously. [CSCdj70138]
The kernel timeout function hits a fatal error when called with a negative time value. For example, this will happen if the Offload code gets a connect request with a timeout value of 0x7fffffff seconds.

: The workaround for the offload problem is to reconfigure for IP datagram mode. There is no workaround available for the bug in the kernel timeout function. [CSCdj72646]

If more than 64 channel commands are configured and a microcode reload command is issued, the following error message will appear for each configuration command and the configuration command will be dropped by the CIP:

CBUS-3-CFGCMDDROPPED: Config queue is full, command was dropped, slot 0
%CBUS-3-CIPCFGFAIL: Channel0/2: configuration command TN3270S_PU_LU_NAIL cmd 27 failed

: The workaround is to use cip24-4 or cip25-4 microcode. This microcode allows the user to configure 512 configuration commands. If more commands are required, upgrade to Cisco IOS Release 11.2BC. This release allows 1024 channel configuration commands. [CSCdj75050]

Caveats for Version 25.4/Version 25.5 Modifications

This section describes possible unexpected behavior by Version 25.4. All the caveats listed in this section are resolved in Version 25.5. See Table 10 for the Cisco IOS software release that corresponds to the 25.5 microcode version.

Despite "unbind-action keep" being configured, the TN3270 Server disconnects a TN3270/E client if Sysreq is followed by any key. This disconnection is not a problem if sysreq is not used to close an LU-LU session.

: The workaround is to either not use sysreq or to reconnect the client if an SSCP-LU session is required. [CSCdj21850]

Sending a ping greater than 4096 bytes in length to a CIP TN3270 Server IP address will cause the CIP to hang and consume all available CIP memory. [CSCdj39225]
Although an NMVT PSID was sent to VTAM during the connection state, a PSID was not sent to VTAM during disconnection. Sending both PSIDs allows network management to know the connection time of the clients. [CSCdj39365]
The following changes have been made to address some TEST command issues:
- Answer TEST CMD other than DSAP of 0x0 if it is activated.
- The TEST CMD is dropped if the adapter has not activated the SAP or if the maximum number of connections has been reached.
- The TEST CMD is dropped while the SAP is in the deactivation processing mode.

: [CSCdj41342]

When a TN3270E connects, a new LU is selected. This selection causes the LU to cycle once and likely cause a connection failure. [CSCdj43047]
When using the offload feature, if a Halt Subchannel is issued from the mainframe when the offload read subchannel is busy with more-to-come chains, the CIP could fail in many ways. The problem could result in a fatal-error as a result of freeing and invalid addresses (for example, 0 or a non-four-byte aligned address) to the global page queue. The problem could also result in a fatal error as a result of the ESCON processor (ESCP) locking. It is unlikely that this problem will occur because the mainframe rarely performs a Halt Subchannel on busy connections. [CSCdj43959]
When recycling a LOGAPPL application that is connected to a CIP TN3270 Server, one or more PUs can remain in flow-control state. This scenario can cause the PU to go into ACT/BUSY state and terminate all LU traffic going to users.

: The workaround is to recycle the PU. [CSCdj46065]

With a TN3270 Server, if a CIP application shuts down its own TCP connection, it sends out a FIN (finish) segment. If it never receives a FIN from the peer, the local side of the connection will stay in FIN_WAIT_2 state even after the application closes the socket completely. [CSCdj48609]
A TN3270 client, which is mapped to a specific LU, fails upon reconnection. Although the first connection is successful, when the client disconnects and then tries to reconnect, the connection attempt will fail. [CSCdj48876]
DLUR PUs can stick in PAPU2 state. Recycling (by issuing a shut command and then a no shut command) the DLUR does not help. This condition occurs if all of the DLUR PUs are made inactive at the host, but the DLUR EN PU is active. The repeated attempts of DLUR to activate the PUs result in buffer loss in the CIP. Eventually a pool of buffers becomes empty and no ACTPUs are processed.

: The workaround is to recycle the TN3270. [CSCdj50517]

The actual amount of supported max-llc2-sessions is one less than what is configured. The workaround is to ensure adequate margin in the max-llc2-sessions specification. [CSCdj51067]
For CSNA devices, multiple LOGDATA records can occur as a result of the corruption of the count in the data request frame. Usually when multiple LOGDATA records occur, it is for some other reason (for example, a bad fiber connection). The way to verify that it is this problem, is to put an ESCON analyzer on the ESCON connection and trigger the beginning of connection recovery (UD sequence).

: There is no workaround. [CSCdj51076]

The host XCA node goes down or an attached PU or LU goes into the INOP state after installing a CIP image.

: The workaround is to revert to a previous CIP microcode version or install the next release, which does not contain this problem. [CSCdj51725]

The SNA sense code 2003 is sent to the host that is causing the client to disconnect. If the host has the direction and the client sends data, the data will be queued. Later, when the host sends data with the EBI bit on, the client data will be sent. However, subsequent data from the host will get a negative response.

: The workaround is to reconnect the client. [CSCdj58664]

The offload code can hit a fatal error after an OFFL-3-ILLEN or OFFL-3-ILLALH error message. There is no workaround for this problem; however, the error conditions leading to those error messages are rare.

: Another problem that was fixed was an OFFL-6-WRCHAIN error message when running TPF Offload. [CSCdj59133]

There exists a small timing window that may cause the LLC2 connections to hang when the connection enters the ERROR state. This problem prevents the user from being able to change to XCA major node. [CSCdj59231]
During high traffic and usage of varying frame sizes, the following error message may occur:

SSI_ASSERT crash in ssi_msg_offset function.

: The workaround is to reduce the PIU size. [CSCdj61634]

If CIP TN3270-Server DLUR is configured with a link to VTAM over a CMPC tg, the link will not activate and the XID negotiation will fail.

: With the DLUR EN active, inact force the vtam local node by issuing the /v net,inact,id=mvsln,f command. Then try to activate the local node by issuing the /v net,act,id=mvsln command
: The workaround is to issue a shut command then no shut command on the TN3270 Server DLUR. Alternately, do not configure the link from DLUR EN to VTAM. Configure it only from VTAM to DLUR EN. [CSCdj63054]

The show extended channel slot/port cmpc command displays the buffer values received from the host for both the read and write subchannels. The buffer values for write subchannels should always be 16. Also, inactive subchannels will sometimes display a non-zero buffers value.

: There is no workaround. [CSCdj63802]

CIP configuration statements are lost with associated CIPCFGFAIL and CIPCMDDROPPED messages. This problem occurs only with large configurations that have approximately 64 channel configuration statements.

: The workaround is to reenter the dropped statements manually. This workaround increases the number of CIP configuration statements that can be handled to 128, and is a temporary fix until CSCdj44143 is implemented. [CSCdj63815]

Caveats for Version 25.3/Version 25.4 Modifications

This section describes possible unexpected behavior by Version 25.3. The caveat listed in this section is resolved in Version 25.4. See Table 10 for the Cisco IOS software release that corresponds to the 25.4 microcode version.

The host XCA node goes down or an attached PU or LU goes into the INOP state after installing a CIP image.

: The workaround is to revert to a previous CIP microcode version or install the next release, which does not contain this problem. [CSCdj51725]

Caveats for Version 25.2/Version 25.3 Modifications

This section describes possible unexpected behavior by Version 25.2. CIP Microcode Version 25.3 is the initial release for support in Cisco IOS Release 11.3(1). All the caveats listed in this section are resolved in Version 25.3. See Table 10 for the Cisco IOS software release that corresponds to the 25.3 microcode version.

If a CIP TN3270 PU is configured to connect from the host to the CIP via NCP, the link may fail.

: The workaround is to configure the CIP TN3270 PUs connecting at the host. [CSCdj07152]

The output of the show extended channel slot/port tn3270-server dlur command has been modified to show more information. The following additional information is displayed:
- Current network node server
- Status of the CP-CP session

: The following is an example of the show extended channel slot/port tn3270-server dlur command output:

lorikeet#sh ext ch 2/2 tn dlur
 dlur MPX.LORICP                                 
 preferred dlus MPX.NGMVMPC             dlur-dlus status ACTIVE  
 current server MPX.NGMVMPC              cp-cp status ACTIVE
 backup dlus <not configured> 
 preferred server <not configured> 
  
 lsap token-adap  0 C0     vrn <not configured>      status ACTIVE           
 link TRP390               remote 4000.7470.00e7 08  status ACTIVE

: [CSCdj19544]

The CIP TN3270 Server should stop listening on the relevant IP port if it cannot accept any more TN3270 or TN3270E connections. This action ensures that the device driver makes correct decisions. [CSCdj24385]
Following a channel error or host initial program load (IPL), the VTAM is unable to activate the XCA major node. The router log shows the following message at each attempted activation of the XCA major node:

Jul  4 00:10:28: %CIP25-6-MSG: %MSG802-6-LLC_DUP_SAP: LLC Duplicat SAP on interface 546 : SAP=4.

: Issuing the llc show all command on the CIP indicates that CSNA has failed to clear up one remaining session.

CIP-Slot5#llc show all
--- AdapNo 02, LanType Token     , SAP 04 ---
pcep=0860 rmac=4000.0000.7190 lmac=C000.0115.6500 rsap=04 lsap=04 this=8120EDA8
pcep=0860 state=ADM rbusy=no  lbusy=no  flow=on  pflag=1 dflag=0 v_r=0    v_s=0    last_nr=0    flag=60264282

: The workaround is to issue a microcode reload command to clear the hanging session. [CSCdj26081]

A TN3270 Server, when operating with RFC1646-compliant printers, may send the wrong sense-code to the host when presented with a printer 'InterventionRequired' condition. The sensecode actually provided to VTAM is 0x1003000; correct operation might result in a sensecode of 0x08020000 or similar. [CSCdj36856]
The TN3270 Server may drop an unbind image from a job entry subsystem to a TN3270E client. The client (for example, a PC3270) may send a disconnect after receiving a bind image without receiving an unbind image. [CSCdj36868]
The Offload write task does not terminate after deconfiguring the offload if the host has sent frames on the write subchannel IP link. The only known side effect is that this task will take up an entry in the task table and some memory. [CSCdj37835]
If VTAM is shut down while traffic is flowing, an external communication adapter (XCA) node may not start when the VTAM is restarted.

: The workaround is to issue the no csna command on the nonfunctioning subchannel, the no shutdown command on the physical interface, or the microcode reload command. [CSCdj38712]

The following changes have been made to address some TEST command issues:
- Answer TEST CMD other than DSAP of 0x0 if it is activated.
- The TEST CMD is dropped if the adapter has not activated the SAP or if the maximum number of connections has been reached.
- The TEST CMD is dropped while the SAP is in the deactivation processing mode.

: [CSCdj41342]

When using a CIP TN3270 Server with the SNA session switch feature (DLUR), PUs that have a fully qualified name length of 17 characters cannot be activated. Activation fails with the SNA sensecode 0x10060000.

: The workaround is to use PU names that are less than eight characters. [CSCdj39358]

When hosts send a null response unit with begin chain (BC), the server will not send a TN3270E header to the printer client. The client then sends a disconnect to terminate the session. A typical host application is a job entry subsystem. [CSCdj39359]
The shutdown process never completes, and a microcode reload is required when a shutdown command is issued on the virtual interface. This condition occurs when a connection is configured between a CIP multipath channel transmission group and an APPN node and the TRL and SNA local nodes are activated.

: The workaround is to inactivate the SNA local node before shutting down the virtual interface. [CSCdj43833]

The SNA Local node must be recycled after cycling the virtual interface. This condition occurs when a pair of CMPC subchannels, a transmission group (TG), and an APPN node are configured on the router and a session is brought up by activating the host TRL and SNA local nodes. When a no shutdown command is issued, the SNA local node does not recover.

: The workaround is to either inactivate the local node first, or inactivate and then reactivate node when the problem occurs. [CSCdj46294]

The actual amount of supported max-llc2-sessions is one less than what is configured. The workaround is to ensure adequate margin in the max-llc2-sessions specification. [CSCdj51067]

Caveats for Version 25.1/Version 25.2 Modifications

This section describes possible unexpected behavior by Version 25.1. All the caveats listed in this section are resolved in Version 25.2.

When using DDDLU (LUGROUP) in conjunction with DLUR (for example, a CIP TN3270 as SNA Session Switch), the host's session awareness does not recover after a DLUS outage. This error occurs because DLUR provides the session awareness on the required space character for the ACTLU, but for DDDLU LUs there will be no ACTLU. [CSCdj15193]
When the CIP TN3270 servers only active DLUR links are configured from the host end and not from the CIP end, no attempt is made to find a network node server. [CSCdj18737]
CIP1 with 8 MB DRAM cannot be configured for 10 LLC sessions when using CSNA and cip22-19 microcode. The CIP will run if the max-llc2-sessions configured is 1. The CIP reloads continuously if the max-llc2-sessions is 10. [CSCdj19012]
When the CIP TN3270 Server disconnects a TN3270 client session, it sends out Telnet commands and an ASCII message describing its reason for the disconnect. The TCP session closes shortly after the message. Some clients do not like the Telnet command; others do not like TCP close coming after the data. The clients may behave unusually by giving an error message or locking up. These clients do not have the problem with servers that do not send Telnet commands and the ASCII message before the TCP closes. This message may cause the TN3270 client to freeze. If the TN3270 client freezes, reboot the operating system. This situation has not been reported with other TN3270 servers.

This malfunction could be caused by the following situations:

TN3270 clients do not follow the RFC, which allows network virtual terminal messages to be sent at disconnection time to inform the client of reason for disconnection
Client TCPIP stack reorders the data and finish packets causing an error on client

The workaround is to upgrade to a client TCPIP stack and application that conform to RFCs.

This error disables the capabilities of the Telnet option, which stops TN3270 mode (IAC DONT BINARY IAC WONT BINARY) and the network virtual terminal messages at disconnect time in CIPTN3270 server. [CSCdj19545]

If clients disconnect from a CIP TN3270 Server in a short period of time, the server loses buffers and the PUs stay in the ACT/BUSY state. [CSCdj20423]
The commands that begin with show extended channel slot/port can fail to display all expected data because of a bug in the inter-process communications function used by Cisco IOS software to communicate with the CIP. [CSCdj21544]
LU-LU sessions are not preserved and the links are disconnected when an SSCP takeover or giveback occurs. [CSCdj22128]
A client can hang when a TN3270E client sends data before it sends a response. This error causes the data to be sent to the host before the response and causes the bracket state to be incorrect. This problem occurs using Personal COMMunication (PCOMM) 4.1 when the PA1 key on the TN3270 terminal is pressed while data is sent to the client. [CSCdj22926]
A CIP TN3270 Server PU stays in ACTIVE state after removing the internal adapter from the router configuration that the PU was using to connect to the host over the physical channel on the CIP. [CSCdj23224]
When the CIP is not channel attached, the CIP crashes with the following SSI_ASSERT message:

%CIP0-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../ssi/ssi_buff.c @ 158 - (msg) && ((( msg)->m_flags & ( M_PK
%CIP0-3-MSG: THDR | M_EXT)) == ( M_PKTHDR | M_EXT))

: [CSCdj23424]

In a CIP TN3270 Server using TN3270E client, multiple chain messages do not use TN3270E responses when the first in chain has the Exception-response (EXR) flag set. The definite-response (DR) actually comes on last in the chain, but by that time it is too late.

: The workaround is to handle multiple chain messages as if they are definite responses from the host while generating TN3270E header. This workaround will ensure that the definite-response from the host can be used to guarantee an end-to-end response. [CSCdj24073]

The CIP TN3270 Server should stop listening on the relevant IP port if it cannot accept any more TN3270 or TN3270E connections. This action ensures that the device driver makes correct decisions. [CSCdj24385]
If a PU is remaining in the busy state, a new session may connect to the PU despite the availability of other PUs. The original connection will fail and there will be no warning message to indicate the connection failed.

: For the TN3270E client, there is no warning message if the host does not send a start data traffic (SDT) message. If a Telnet instead of a TN3270 client connects in the connection will fail, but an LU may be permanently assigned and not be reused again. If the host sends a DACTPU message, the statistics of the LU connections and disconnections may be wrong.
: Some hosts may send system services control points (SSCP) LU data before they send notify-response data. Also, a "no bind" warning message may be sent. [CSCdj24694]

The SNA session switch (DLUR) support in the CIP TN3270 Server is limited to 16384 concurrent sessions per CIP. Attempts to activate more LUs are rejected with sense code 0812 0007. [CSCdj24704]
The CIP crashes with a fatal error code 35 because the global queue of 4 KB buffers contains 0x00000100 instead of a valid address. The fatal error output contains the following line:

%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF BE810000 00000000 00000100  ...

: If the second double word on this line contains 00000000 00000100 it is likely that the crash was caused by this bug. [CSCdj25062]

During link inactivation, a message from downstream through a CIP TN3270 Server could cause the CIP to reload spontaneously. [CSCdj25255]
If the host sends SSCP LU data before a notify response and the client sends data before a notify response, the client is disconnected. This bug should happen only on a busy host with an application software sending data as soon as it receives data. [CSCdj27305]
If the host sends consecutive exceptional response frames, the TN3270 Server will send these frames before any responses come back from the RFC 1646 printer client. Some clients (for example, Attachmate Extra 4.3) may drop the data. [CSCdj28167]
The LUs are allocated from a PU so that no more LUs leave from the PU. If the PU become inoperative (INOP), then typically 255 sessions are lost. However, if the LUs are PUs evenly allocated, then fewer users are affected upon PU INOP. [CSCdj28852]
A CIP configured with CSNA and TN3270 Server may crash with the following message:

SSI_ASSERT failure in ../cta802/ccb802.c @ 3044 - LOOPBACK_FLOW_RECEIVED
Fatal error (code=09)

: [CSCdj29175]

When a DLUR link becomes inactive, the TN3270 Server reports the link outage with the wrong transmission group number. If the transmission group number is zero, then there is no problem. If the transmission group number is not zero, then DLUS may attempt to route dependent LU sessions over the link and the session setup will fail. [CSCdj29401]
When a DACTPU Giveback is sent to a TN3270 Server DLUR PU, no response is sent to the VTAM. After V INACT,ID=pu,TYPE=G, the PU is left in the state physical device address control point. [CSCdj29413]
The CIP crashes with a fatal error code 35 because the global queue of 4 KB buffers contains 0x00010001 instead of a valid address. The fatal error output contains the following line:

%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF 803F0010 00000000 00010001  ...

: If the second double word on this line contains 00000000 00010001 it is likely that the crash was caused by this bug. [CSCdj30387]

Each time a client connects and selects a static LU, the client is delayed for 3 seconds before the host connection is made. [CSCdj30652]
An extra end of job message (EOJ) may be sent to the printer after the last message, but before the client response. This may cause the printer drop the last messages.

: This bug is a regression caused by CSCdj28167. It occurs if the last message the host sends does not have end bracket (EB) bit on it. [CSCdj30937]

A CIP may crash with the following message after many errors are received over an ESCON Channel Adapter (ECA):

Jul 30 00:53:29: %CIP3-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta/cta.c @ 345 - FALSE
Jul 30 00:53:29: %CIP3-0-MSG: %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: [CSCdj30949]

Under rare circumstances (for example, during power outages or when a TN3270 client disconnects suddenly in middle of normal traffic) the CIP microcode may reload spontaneously with error 35.

: There is no guaranteed workaround other than to avoid random disconnection from the client in the middle of transactions. [CSCdj31131]

When the offload code on the CIP gets a duplicate send request because of the IBM bug known as APAR PQ02051, it responds with an EINVAL error code to the second request. The mainframe reacts to this error by dropping the session.

: The workaround is to drop the duplicate request. [CSCdj31238]

This fix corrects the CSNA problem of handling invalid channel blocks from host. [CSCdj31253]
Performing a no shutdown command on a CIP virtual interface where the llc2-max-connections command is greater than 5000, can result in excessive memory consumption. This problem exists in versions up to cip22-21.

: For example, the interface works well if it is brought up with 6000 sessions. However, when the interface is issued a shutdown command and no shutdown command, an additional 64 K 160-byte buffers is added to one of the channel transport adapter buffer pools, consuming about 10 MB of memory. This excessive memory consumption causes various problems depending on the size of the CIP memory. The size of the buffer pool can be corrected by issuing a microcode reload command. [CSCdj31884]

The show controller cbus command could indicate that the channel utilization is 100 percent busy, despite no device-level traffic. This situation most likely occurs with a Parallel Channel Adapter (PCA), and less likely with an ECA. Without this fix, any start subchannel connected to one of the devices should cause the utilization to start reporting correctly. [CSCdj32046]
This bug fixes and deprecates an unimplemented trap (cipCardLinkFailure) and implements a new trap (cipCardDtrBrdLinkFailure). Also, a new snmp-server enable traps channel-failures command was added to the parser. This command enables and disables the new trap (cipCardDtrBrdLinkFailure). [CSCdj32297]

CIP Microcode Release cip24 Caveats and Modifications

The following sections describe the caveats to current CIP microcode versions and the modifications made in current CIP microcode versions for cip24 microcode. The caveats listed apply to only the most serious problems. See Table 10 for the Cisco IOS software releases supported by cip24 microcode.

Caveats for Version 24.18/Version 24.19 Modifications

This section describes possible unexpected behavior by Version 24.18. All the caveats listed in this section are resolved in Version 24.19. See Table 10 for the Cisco IOS software release that corresponds to the 24.19 microcode version.

A BADTIMER message appears when starting the TN3270 server. The messages do not impact normal TN3270 server operations.

: There is no workaround. [CSCdr11353]

The available LU count displayed in the show extended channel tn3270 command output is incorrect. This problem occurs when the same static LU receives an ACTPU message within 3 seconds of receiving a DACTPU message. This problem occurs after configuring a "Z NET,CANCEL" VTAM command or after the initial program loading (IPL) of the LPAR.

: There is no workaround. [CSCdr40633]

The TN3270 server times out and the client hangs. The following example illustrates this problem:

 tn3270-server 
   pu pu1 91903315 172.18.4.18 tok 16 08 
     client ip 10.2.20.20 lu 10 
   pu pu2 91913315 172.18.4.18 tok 16 0C

This problem occurs in the following circumstances:

A client with the IP address 10.2.20.20 activates two PUs and gets LU 10. PU1 is not active. PU2 is active and the listen-point with the address 172.18.4.18 is active. The auto-reconnect function activates and the client attempts to connect. The connection is rejected because PU1 is not active.
PU1 is activated. The client auto-reconnect should succeed but does not.
The product-set identification (PSID) reply message on NMVT does not go inbound, but the server still waits for the PSID response. The TN3270 server then times out and the client hangs.

The workaround is to disable the auto-reconnect feature on the TN3270 client. [CSCdr50907]

An AS/400 TN3270 client negotiates a termtype of IBM-3486-BA with the CIP TN3270 server. IBM-3486-BA is an invalid 3270 termtype and will not handle 3270 data streams correctly.

: This fix adds IBM-3486-BA to the list of known invalid termtypes in the CIP TN3270 server. The CIP will send a WONT TERMTYPE message and allow the client to negotiate a valid termtype.
: There is no workaround. [CSCdr65906]

Caveats for Version 24.17/Version 24.18 Modifications

This section describes possible unexpected behavior by Version 24.17. All the caveats listed in this section are resolved in Version 24.18. See Table 10 for the Cisco IOS software release that corresponds to the 24.18 microcode version.

Users are unable to start new CMCC sessions. The results of a show extended channel x/2 tn command show that some PUs are in an ACT/Busy state. The results of a VTAM display of the PU show that the PU is in an active state.

: The workaround is to reload the microcode. [CSCdm44279]

The CMCC adapter fails with fatal error message number 35. This problem occurs when the no client ip ipaddr [ipmask] pool poolname command is configured when using LU pooling. The command configuration causes memory corruption and the CMCC failure. The failure usually occurs because the TN3270 server attempts to access ODD addresses when EVEN addresses are expected.

: There is no workaround. [CSCdp18803]

The printer emulators receive an -RSP sense 2005 message. The problem is caused by an emulator that sends data to the host after the BIND, but before the Start Data Traffic (SDT) processing is complete. This data is rejected from the host and the following -RSP sense 2005 message appears:

J+FKP4390E UNEXPECTED DATA RECEIVED.QUE.HELD.LU="LUname"

: There is no workaround. [CSCdp30854]

The CMCC Adapter fails with error message 35. This problem occurs when adding a second TN3270 Server PU under the DLUR and when the CMCC Adapter is offline.

: There is no workaround. [CSCdp43223]

The CMCC Adapter calculates a set buffer address (SBA) that is above the screen size. This problem occurs when connecting a 327802 client using a 3270 datastream. This causes the connected session to hang on the MSG0 screen.

: The workaround is to code the LUGROUP parameter with one of the following values: SSCPFM=USS3270 or SSCPFM=USS3270. [CSCdp46564]

The TN3270 server show pu command output is missing LU states. The missing states are displayed as P-RESET. This applies also to the LU state objects in the TN3270 server MIB.

: There is no workaround. [CSCdp51038]

The CMCC adapter fails with a fatal error message number 9.

CIP2-3-MSG: slot0 %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../ssi/ssi_buff.c @ 1035 - msgP->m_next
Jan 31 15:40:12: %CIP2-0-MSG: slot0 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: There is no workaround. [CSCdp84989]

There is a 10-second delay from the time that the host application sends a SHUTDOWN message until the TN3270 server responds with the SHUTC RU message. This delay applies to printer emulators and should not apply to screen devices.

: There is no workaround. [CSCdp90214]

The TN3270 server allows a client to access LUs which are nailed to another subnet.

: There is no workaround. [CSCdr12567]

The TN3270 server improperly releases nodes which had not been deleted from the resource AVL tree. This problem occurs when the TN3270 server is restarted by configuring the shutdown and no shutdown TN3270 commands.

: A workaround is to avoid restarting the TN3270 server when there is a heavy processing load. [CSCdr18250]

The CMCC adapter fails with fatal error message number 35. This problem occurs when the no listen-point TN3270 server command is configured.

: There is no workaround. [CSCdr19257]

When using the TN3270 server monitor or a similar product such as SOLVE:Netmaster for TCP/IP, the length of the message fragment field is reported incorrectly. The field length is reported as "18". It should be reported as "20". The message fragment field is defined as follows:

  struct {short PACKED(pktLength); short PACKED(len); 
          unsigned char PACKED(bytes[16]);}

: This is a cosmetic failure and is present in all CIP and CPA microcode releases.
: There is no workaround. [CSCdr24412]

VTAM issues a V NET,INACT,TYPE=GIVEBACK message. The control point-to-control point session moves to the other DLUS, but the DLUR pipe stops and restarts on the same host.

: There is no workaround. [CSCdr28173]

The last logical PU in an IP pool of listen points is placed into the WAIT state. This problem occurs when changing the TCP-port while PUs are in an ACTIVE state.

: The workaround is to shutdown and restart the TN3270 server using the shutdown command. [CSCdr30174]

TN3270 server LUs can not be used. This problem occurs when the TN3270 server does not clear the indication that LUs were nailed during processing and delete the nailing definition.

: The workaround is to avoid manipulating nailing definitions without issuing the microcode reload command. [CSCdr32205]

Caveats for Version 24.16/Version 24.17 Modifications

This section describes possible unexpected behavior by Version 24.16. All the caveats listed in this section are resolved in Version 24.17. See Table 10 for the Cisco IOS software release that corresponds to the 24.17 microcode version.

At show ext cn/2 pu/lu, some DDDLU LU names appear blank if Host applications send NULL SLU data in the bind.

: There is no workaround. [CSCdj90734]

The TN3270 server loses pool-based LU nailing information. This problem occurs when the no shutdown command is configured multiple times on the same PU.

: The workaround for customers who are using pool-based LU nailing is to avoid configuring the no shut command multiple times on the same PU. [CSCdm24372]

A user receives another user's session when both users are logged into the same applications owning region (AOR) in the Customer Information Control System and that AOR is manually cancelled.

: The workaround is to not disconnect a client during the logon process; that is, after requesting an application from the SSCP screen, but before establishing the LU-LU session with that application. [CSCdm51110]

The following message appears on the CMCC console:

: bad error-code 12 given
: This valid error code indicates a missing TERMSELF response. The code to log and format this specific error into a console message is missing.
: There is no workaround. [CSCdm55961]

The CMCC adapter fails with error message number 32. This problem occurs when the TN3270 server is configured and is using, or has used, the TN3270 monitor or a similar product.

: The workaround is to not configure the TN3270 monitor or a similar product. [CSCdp16086]

The CMCC adapter fails with fatal error message number 32. This problem occurs when approximately 25 or more DLUR links are configured. The reply buffer is too small to contain all of the Cross Domain Init vectors and the positive locate reply.

: The workaround is to configure fewer DLUR links. [CSCdp79125]

The snaLuAdminTerm and snaLuOperTerm objects in the SNA-NAU-MIB always appear as "unbind" even if "termself" is configured.

: There is no workaround. [CSCdp88662]

The CMCC adapter may fail when the shutdown command is configured in TN3270 sub-mode.

: There is no workaround. [CSCdp99538]

The CMCC adapter configured for CSNA may not respond to a test poll. This problem occurs because there is a miscount of the available IBM VTAM External Communications Adapter (XCA) resources. Typically an XCA autogen parameter is configured to automatically generate lines and PUs. This is not required for PU5-to-PU4 or PU5-to-PU5 communications.

: The workaround is to recycle the XCA major node. [CSCdr03103]

The LU number in the show extended channel tn3270-server command output decreases every time a client fails to telnet. Once the LU number reaches zero, clients cannot telnet to the TN3270 server although LUs are available.

: There is no workaround. [CSCdr09662]

The CMCC adapter fails with the following error message:

%ECPA-4-MSG: slotx %TN3270S-4-NO_LU_SESSIONS
: No LU sessions left in :GENERIC for PUs at IP addr xxx.xxx.xxx.xxx, port 23

: The TN3270 server PU output displays skipped LUs. The TN3270 server does not select these LUs. All other LUs are set to ACT/SESS. Note that there is no LU display for lu4 and lu9.

lu    name   client-ip:tcp       nail   state    model frames in out   idle for
1   ABCD2001 xxx.xxx.xxx.x:1042    N   ACT/SESS 3278S5E  38418   19615   0:6:6
2   ABCD2002 xxx.xxx.xxx.xxx:1043  N   ACT/SESS 3278S2E  21473   14085   0:18:11
3   ABCD2003 xxx.xxx.xxx.xx:1665   N   ACT/SESS 3278S5E  9992    6147    0:0:6
5   ABCD2005 xxx.xxx.xxx.x:1046    N   ACT/SESS 3278S5E  12731   8074    10:33:7
6   ABCD2006 xxx.xxx.xxx.x:4033    N   ACT/SESS 3278S2E  31367   18838   2:0:51
7   ABCD2007 xxx.xxx.xxx.x:1045    N   ACT/SESS 3278S5E  8184    4413    2:55:4
8   ABCD2008 xxx.xxx.xxx.xx:1323   N   ACT/SESS 3278S2E  16274   7580    4:28:19
10  ABCD200A xxx.xxx.xxx.xxx:1205  N   ACT/SESS 3278S2E  7752    4175    1:3:39

: The workaround is to add more PUs to the TN3270 server and VTAM configuration. [CSCdr13016]

The CMCC adapter fails with the following fatal error message number 35:

%CTA-0-INACTIVE: PA1 CTA 7C00-50 reset after being inactive for 180 seconds

: The workaround is to shutdown the CSNA subchannel before shutting down VTAM. [CSCdr13804]

The LU-available number in the show extended channel tn3270 command output is incremented on inactive PUs when adding nailing configuration commands.

: The workaround is to ignore or activate the PU to correct the lu-available number. [CSCdr17334]

The CMCC adapter fails with fatal error message number 7. This problem occurs when the client disconnects after the response time group is removed from the configuration. This occurs when the response time group and the subnet are configured.

: The workaround is to remove the response time group configuration. [CSCdr20842]

Caveats for Version 24.15/Version 24.16 Modifications

This section describes possible unexpected behavior by Version 24.15. All the caveats listed in this section are resolved in Version 24.16. See Table 10 for the Cisco IOS software release that corresponds to the 24.16 microcode version.

BADTIMER messages appear when running TN3270 Server. In this case, the messages appear because a TN3270 session is being negotiated or recently has been negotiated. The messages do not impact normal TN3270 Server operations.

: There is no workaround. [CSCdk21633]

The CMCC Adapter fails with error message 37. The following error messages appear:

%CONFIG-3-WORKLEFT:Work pending on work queue when device terminated 
%DEBUGGER-0-FATAL_ERROR:Fatal error (code=37)

: There is no workaround. [CSCp54593]

The CIP configured for CSNA crashes with the following error message:

: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ./cta802/dlu.c Fatal error (09).
: [CSCdm22660]

The CMCC adapter fails with the following message:

%CIP2-3-MSG: slot0 %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta802/ciptask.c @ 322 - !mxcb->mx_next
%CIP2-0-MSG: slot0 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: The assertion is intended to detect messages with 15 or more memory buffers (mbufs). There is no workaround. [CSCdp13245]

A print server with 10 LUs fails to get 10 TNET connections with the TN3270 Server. The tenth LU client receives a FIN message from the TN3270 Server. The TN3270 Server rejects the TNET message indicating Listen Closed on the PU. Additional attempts to connect to the tenth LU fail until the LU is reactivated or another LU is disconnected. The problem only occurs when the last ACTLU static LU is obtained by a client. It is standard practice for the TN3270 Server to close the listen vector at this time; however, it should not close any connections that are being negotiated and have obtained LUs.

: The workaround is to add an additional 3 LUs to the VTAM switched major node, leaving the print server to request only 10 TNET connections. [CSCdp43253]

The CMCC Adapter deletes all the PUs associated with IP pool and fails with error message 35. This problem occurs when a listen-point PU and another non-listen-point PU are configured with the same IP address and TCP port pair and the no listen command is issued. PUs that are not configured under the listen-point are deleted.

: The workaround is to not configure a listen-point PU and another PU with the same IP address and TCP port pair. [CSCdp45166]

The CMCC Adapter configured for TCP/IP Offload fails with a error message 35. This problem occurs after a %MBUF-0-MFREEx2 message error. The problem occurs in rare circumstances when a socket request close() is issued on a TCP/IP server socket which has an outstanding accept() socket response on a BLOCKING socket. This problem also occurs in the same circumstances on a CMCC Adapter configured for TPF Offload.

: There is no workaround. [CSCdp47885]

The CMCC Adapter fails with error message 35. This problem occurs when the no client ip command is issued in listen point submode.

: There is no workaround. [CSCdp55519]

CMCC Adapter configuration errors occur when the CIP microcode is upgraded from version cip24-14 to cip24-15. The following error message occurs when attempting to delete an allocate LU pool statement:

dec 20 05:48:57 UTC: %CBUS-3-CIPCFGFAIL: Channel0/2: configuration command TN3270S_LISTEN_POINT_PU_LU_POOL  cmd 40 failed

: There is no workaround. [CSCdp56576]

The CMCC Adapter fails with error message 35 when the TN3270 Server is shut down. This problem occurs when using CIP microcode version cip24-15 or later.

: There is no workaround. [CSCdp58083]

When the TN3270 Server statistics are displayed, a negative LU IN USE message appears. This is a cosmetic problem. LUs are still available to the clients as needed.

: There is no workaround. [CSCdp69064]

Caveats for Version 24.14/Version 24.15 Modifications

This section describes possible unexpected behavior by Version 24.14. All the caveats listed in this section are resolved in Version 24.15. See Table 10 for the Cisco IOS software release that corresponds to the 24.15 microcode version.

In a duplicate MAC environment, the CIP will continue to respond to a TEST command when the lines configured for the XCA are in use. This problem prevents other duplicate MAC adapters from responding to new requests.

: The workaround is to configure the maximum LLC or threshold to equal the number of XCA lines configured. [CSCdm29597]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The CMCC displays a RSP sense 089F0004 message when processing a REQACTPU message. The problem occurs when the VARY command is entered for DLUR PUs that have multiple PATH statements. The problem occurs because the DLUR sends a message to the DLUS containing an FQPCID value which DLUS created on an earlier acquisition of the PU. The host processes the FQPCID message as invalid.

: The workaround is to remove the PATH statements. [CSCdm42103]

The DLUR pipe between VTAM and the CMCC adapter hangs. This problem occurs when a large number of TN3270 Server TCP/IP requests (1000 per CMCC Adapter) arrive at the same time.

: The workaround is to space out the TCP/IP requests. [CSCdm75120]

CSNA devices fail with INOP messages during Interface Control Check (IFCC) status. This problem occurs when CLAW and CSNA are operating in high traffic conditions. It can occur in CMPC and CSNA, also.

: The workaround is to upgrade the CMCC microcode or to restart the external communication adapter (XCA) nodes. [CSCdm88239]

A CMCC file transfer hangs or the keyboard stops working. The problem occurs when the IND$FILE uses structured fields and buffers that are 2000 bytes or greater. The keyboard is restored using the TN3270 write command instead of the structured field.

: The workaround is to use buffers that are 2000 bytes or less or non-structured fields (presentation space transfer. To enable the fix in CMCC releases cip27-4 and greater and xcpa27-4 and greater, you must configure the TN3270 tn-parameter code codevalue command with a code value of 7. [CSCdm93990]

A BIND REQUEST or SSCP-LU message is expected but not received from the host within 30 seconds from the start of an SSCP-LU session for the CMCC Adapter TN3270 server session. If the condition continues for another 2 minutes, the LU is declared bad and the following error message appears:

%TN3270S-1-NO_BIND_REQ_RCVD: No BIND REQ received on LU [chars].[dec], 120*ONESEC

: This error and several others are logged as priority 1 (alert) messages in error reports. The priority level of the following error messages is now priority level 3:

NO_PSID_RSP_RCVD
NO_NTFY_AV_RSP_RCVD
NO_BIND_REQ_RCVD
NO_SDT_REQ_RCVD
NO_SDT_TMARK_RCVD
NO_UNBIND_TMARK_RCVD
NO_NTFY_UA_RSP_RCVD
NO_DYN_ACTLU_REQ_RCVD
NO_UNBIND_RSP_RCVD 
NO_TERMSELF_RSP_RCVD

: [CSCdm94788]

The VTAM to VTAM communication for APPN and FID2 hangs. The non-LLC2 HPR traffic does not hang. This problem occurs when both VTAMs are attached to the CIP running the CMPC feature.

: There is no workaround. [CSCdp00921]

The TN3270 Server client fails when configuring printer LUs. This problem occurs when the two LU definitions required to configure the printer are set. One LU is nailed with the client IP address and the other is nailed with the client IP address of the printer. The TN2370 Server allocates the video client to the printer LU and then neither client works. This problem occurs in CIP microcode versions cip24-10 through cip24-13 and later.

: There is no workaround. [CSCdp06760]

A 4-to-5 second delay occurs between the CMCC connection to the server and the USSMSG10 screen display. This problem occurs only in CMCC trains cip24-x, cip27-x, and xcpa27-x.

: There is no workaround. [CSCdp06877]

The CMCC fails with error message 35. The problem occurs when the TN3270 Server is using the LU Nailing feature with the older PU definition for the nailed LUs instead of the LU Pooling definition in CMCC branches cip24-x, cip27-x, and xcpa27-x. The following example shows the old PU without the LU Pooling definition:

pu CISCO    04921002 157.2.196.101   token-adapter 31 24 rmac 4000.7206.0001
client ip 157.2.0.0 255.255.255.0 lu 4 20

: The problem occurs when the client ip or no tn3270 server command is entered. The problem also can occur when the interface is shut down.
: There is no workaround. [CSCdp07729]

A TCP/IP Offload select() for readability message indicates that there are no readable sockets in the descriptor list when in fact there are readable sockets available. This problem occurs when the TCP/IP connection fails while a select() for readability message is outstanding on the socket.

: There is no workaround. [CSCdp08103]

In duplicate MAC environments, idle Systems Application Architecture (SAA) gateway sessions terminate. SAA gateways time out the route to the CMCC MAC address and send receive ready poll (RR(P)) single route explorer (SRE) messages to rediscover the route. The CMCC Adapter is not in session and responds to the RR(P) messages with a disconnect mode final (DM(F)) message. The SAA gateway then disconnects the session. The RR(P) SRE is contrary to the LLC2 specifications.

: The workaround is to specify XTX=7 on the route.nlm. [CSCdp09295]

The TN3270 Server or TN3270E client fails when it connects to the server, but does not specify the name of an LU to be obtained. This problem occurs in CIP microcode version cip24-14 and later when a combination of DDDLU and nailed LUs are used.

: The workaround is to code an lu-seed in the router on the PU, then connect to a TN3270E client configured with the correct LU name. [CSCdp09708]

The CMCC adapter with TN3270 Server configured fails with fatal error message 35. This problem occurs when attempting to clear the TN3270 configuration from the router. After entering the no tn3270-server command while in configuration mode on the virtual channel interface, the microcode reloads and all the interfaces flap. The CSNA devices are removed from the running configuration and must be reconfigured.

: There is no workaround. [CSCdp24670]

The CMCC Adapter fails when running CSNA. This problem occurs while processing the detection of idle subchannel conditions.

: The workaround is to avoid creating idle subchannel conditions by not using the Z NET cancel command. Other possible workarounds include shutting down the router channel interface or removing the CSNA configuration statement before issuing the Z NET cancel command. [CSCdp31175]

The CLAW control link does not establish. This problem most likely occurs on a TPF system or on an IBM TCP/IP system. The problem occurs because the timing of the Halt Subchannel message related to the Start Subchannel message is off.

: The workaround is to stop and restart the CLAW driver causing the CLAW control link to synchronize again. [CSCdp32675]

Caveats for Version 24.13/Version 24.14 Modifications

This section describes possible unexpected behavior by Version 24.13. All the caveats listed in this section are resolved in Version 24.14. See Table 10 for the Cisco IOS software release that corresponds to the 24.14 microcode version.

OpenConnect has an informal extension to the Termtype in TN3270. When connecting through an OpenConnect TN3270 gateway, the client IP address is concatenated on the end with a percent (%) symbol.

: The CMCC TN3270 Server does not use this client IP address for matching on LU nailing statements in the configuration. [CSCdj44584]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

MSG10 data from one LU might be seen on an LU already in session. This problem occurs when the TN3270 server remote MAC address resides on a different physical adapter or in a different physical machine, such as a front-end processor (FEP).

: The workaround is to make sure that the RMAC TN3270 server PU resides on the same CMCC adapter as the TN3270 Server. [CSCdm01837]

A user receives another user's session when both users are logged into the same applications owning region (AOR) in the Customer Information Control System and that AOR is manually cancelled.

: The workaround is to not disconnect a client during the logon process; that is, after requesting an application from the SSCP screen, but before establishing the LU-LU session with that application. [CSCdm51110]

Every other CIP TN3270 Server client connection fails. This problem occurs when clients are trying to connect at a slow rate and the TN3270 Server is operating with a light traffic load.

: There is no workaround. [CSCdm55234]

The following message appears on the CMCC console:

: bad error-code 12 given
: This valid error code indicates a missing TERMSELF response. The code to log and format this specific error into a console message is missing.
: There is no workaround. [CSCdm55961]

Attachmate clients loop when attempting to connect to the server. This problem occurs when the client is running Attachmate software version 6.2, the auto-reconnect feature is enabled, and invalid client names are configured.

: The workaround is to upgrade to Attachmate software release 6.3. [CSCdm58334]

The CMCC adapter fails with fatal error code 35 during the TN3270 Server shutdown. This problem occurs because the TN3270 Server PUs are not communicating with the host.

: A workaround is available. Contact the Cisco TN3270 Server development engineers for the interim fix. [CSCdm61159]

The CMCC TCP/IP Offload server socket application hangs. This problem occurs because an accept() socket request blocks after the select() indicated that the server socket was READABLE. The accept() socket request should have returned a so_error condition or the socket ID of a new client socket. In TPF Offload environments, where a single select() may monitor multiple sockets, this problem can cause the application to hang on multiple server sockets if an accept() is issued from the same thread that processes the select() response.

: The workaround is to close and re-open the server socket by restarting the server application on the host. [CSCdm63283]

The TN3270 Server running DLUR/DLUS fails with fatal error message code 35. This problem occurs because the TN3270 Server tries to invoke a SendACTLURSP using a NULL object reference.

: This fix adds a debug message to the log and marks the ACTLU as not processed.
: There is no workaround. [CSCdm69186]

The CMCC TN3270 server fails with fatal error code 35. This error occurs if the fix in CSCdm58334 has been applied.

: There is no workaround. [CSCdm69837]

The TN3270 server sends an LIC message to the DLUS on a +RSP. This message causes the DLUS to send an unbind message with sense data 400B0000 and to shut down the DLUR/DLUS pipe. The DLUR/DLUS pipe will re-establish and the user LU-LU sessions will not be affected.

This problem occurs when the TN3270 server DLUR component improperly saves RU chain bits from the original request to create a response message. This generates the +RSP sense data 400B0000.

The workaround is to increase the RU sizes on the DLUR/DLUS sessions. To increase the RU sizes on the DLUR/DLUS sessions, the user must do the following:

Create a new member called ISTINCLM in the customizable datasets ahead of SYS1.VTAMLIB in the concatenation sequence for DD name VTAMLIB.
Copy the ISTINCLM member from SYS1.SAMPLIB.
Change the RU sizes in member CPSVRMGR from 0x9797 to 0xC8C8 and assemble and link.
Issue the VTAM command FNET,TABLE,TYPE=MODETAB,OPTION=LOAD,NEWTAB=ISTINCLM
Restart the TN3270 server DLUR end node. [CSCdm70432]

The user is unable to acquire specific LUs when using TN3270E clients. This error occurs intermittently on one of the several configured PUs. This error occurs when the customer is running direct-connect PUs (no DLUR) and does not have the INCLUD0E=YES parameter set on the switched major node. This error occurs in CIP microcode version cip210-140, but the affected PUs do not have LU pools defined.

: There is no workaround. [CSCdm73361]

When the CMCC adapter is configured with a large number of offload sessions, the following error message occurs:

%CIP2-3-MSG: slot0 %OFFL-3-NOMEM2: Not enough memory to process socket requests,              0 open, 0 in holddown

: The workaround is to increase memory. [CSCdm76552]

The TN3270 Server fails with the following error message:

%DEBUGGER-0-FATAL_ERROR: Fatal error (code=35)

: This error occurs when the TN3270 Server is shut down while traffic is still transmitting. [CSCdm78261]

Data is lost on printer emulators. This problem occurs when the user is running TN3270 Server in an environment with small (768) RU sizes and low pacing values. The printer receives the first RU of data, but intermittently fails to receive the second. The TN3270 Server received an EXPEDITED SHUTD command prior to receiving the last-in-chain RU. The shutdown process causes loss of data.

: This fix adds a 10 second delay between receiving the shutdown command and responding to the shutdown command. This time window will allow any data that is in queue to transmit before the shutdown procedure.
: There is no workaround. [CSCdm80945]

The unbind/bind sequence in the response time logic during a transaction does not reset the sample. This error causes an invalid response time which might be extremely large, depending upon the timing of the transaction. This problem occurs when the unbind keep is configured when the next transaction completes.

: There is no workaround. [CSCdm82521]

The TN3270 IND$FILE file transfer performs poorly if the RU size is smaller than the maximum transmission unit (MTU). This problem occurs because the Cisco TN3270 Server uses the Nagle algorithm by default.

: The workaround is to set the RU size so that it is at least as big as the MTU on the file transfer path. [CSCdm86734]

The TN3270 Server overwrites 1 byte of a Read Partition Query (RPQ) response. The overwrite occurs because of a logic that was entered to capture a non-standard SYSREQ key sequence for non-TN3270E emulators.

: There is no workaround. [CSCdm88195]

Caveats for Version 24.11/Version 24.13 Modifications

This section describes possible unexpected behavior by Version 24.11. All the caveats listed in this section are resolved in Version 24.13. See Table 10 for the Cisco IOS software release that corresponds to the 24.13 microcode version.

If a CIP2 PCA (Bus and Tag) has an Altera FLEX chip (the large chip on the PCA daughter card) with a date code of 9601 or greater, the CIP will fail with parity errors shortly after the card is first installed. The date code on the PCA can be found only by looking for a code on the edge of the chip or the top heat sink area.

: The workaround is to upgrade to the recommended CIP microcode version which corresponds to your Cisco IOS software. [CSCdm28629]

During a brief TCP connection, the CMCC TCP/IP Offload feature fails to return a response to a Read/Recv type socket request causing the connection's host application to hang while waiting for a response.

: A window exists for brief TCP connections when a connection is made with TCP/IP on the CMCC and then broken (FIN received) before Offload has received and processed an Accept socket request from the host. In this situation, Offload misses the notification from TCP/IP that the connection had been terminated.
: There is no workaround. [CSCdk12291]

The TN3270 Server session fails with the following error message:

INOP STATUS

: The workaround is to reactivate the external communication adapter (XCA) major node. [CSCdk36329]

If a user disconnects without properly logging off the mainframe, a new user can connect to those existing sessions. This problem occurs when accessing Customer Information Control System (CICS) applications through the TN3270 Server. [CSCdk48736]
Sometimes TN3270 client disconnections are counted twice. This miscount results in an incorrect TN3270 active session count. The dynamic LU count for that PU becomes one less than the actual number. This is not a problem until the actual count reaches zero and the dynamic LU count cycles to 255. When this miscount occurs, if you enter the show extended ch4/2 tn command, (which shows how many LUs are in use) the result is inflated by 255.

: The workaround is to shut down and restart the PU or to cycle the PU in VTAM. [CSCdk57112]

The TN3270 Server session disconnects after 150 seconds when the LOGON APPLID is not entered. In this case, there is no unformatted system services table (USSTAB).

: There is no workaround. [CSCdk83774]

Adding and removing PUs configured in TN3270 DLUR causes the CIP to reload with fatal error message 32. This failure occurs when a shutdown command is issued during high traffic periods on the server. The following messages appear immediately before the error:

: %CIP2-1-MSG: slot1 %TN3270S-1-RP_PU_CONFLICT:RP & CIP hold conflicting PU name(xxxxxxxx) or index(92)
: Where "xxxxxxxx" is the PU name.
: %CBUS-3-CIPCFGFAIL: Channel1/2: configuration command TN3270S_DLUR_PU_NEW cmd 18 failed
: %CIP2-0-MSG: slot1 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=32)
: The workaround is to perform the shutdown when the server load is light. [CSCdk83807]

The CIP running TN3270 fails with fatal error number 35 when a shut command is issued to the TN3270 server. This problem occurs when the shut command is issued and the TN3270 Server is operating at high capacity.

: The workaround is to issue the shut command only after the client traffic terminates. [CSCdk87658]

A query on the snaLuOperSnaName field in the SNA-NAU MIB returns an unexpected value. The MIB query returns the administrative name instead of the SNA name. This problem occurs if a direct PU, not a DLUR, has an LUSEED defined. Direct PUs do not support DDDLU. Also, this problem occurs when the INCLUD0E = YES field is not specified on the switched major node (SWM).

: The workaround is to use DLUR or DDDLU, or to specify the INCLUD0E = YES field on the SWM. [CSCdm13637]

The TN3270 Server session disconnects and brings up the Sign On menu. This problem occurs when a user has entered an AID command that it is queued in the server and then is scrolling through the session window. The server sends the AID to the host before receiving the end bracket specifying the direction.

The following trace scenario illustrates the problem:

The BID command is received from the host:

: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=10,2C003601 00AE4B81 00C8
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8501,lu-flags=0D24D204
: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=10,2C000136 00AECB81 00C8

An AID command is received before the host has a chance to send the BB command. Since the BID command was already received the server queues the AID frame:

: *Apr 26 13:36:24: %CIP: slot0 In Tnet 212: len=13,00000100 42F7D7F5 11D7F5FF EF
: *Apr 26 13:36:24: slot0 Out Lu 5.54: sna-state=8D01,lu-flags=0D24D204

The host sends the next write with the BB/keyboard restored (note that there is no EB command):

: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=1484,2C003601 00AF0381 80F10611 5D611DE8
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8D01,lu-flags=0D24D204
: *Apr 26 13:36:24: %CIP: slot0 Out Tnet 212: len=1482,00000200 6C010411 5D611DE8 40404040

The client sends the response to the frame:

: *Apr 26 13:36:24: %CIP: slot0 In Tnet 212: len=8,02000000 6C00FFEF
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8509,lu-flags=0B24D204
: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=9,2C000136 00AF8381 00

The BUG-inbound queued data was sent inbound before the EB command was received from the host:

: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=15,2C000136 00200392 20F7D7F5 11D7F5
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=9,2C003601 00B00391 40

There is no workaround. [CSCdm31347]

The TN3270 server LUs using LU Nailing fail. If a client IP address is nailed to an LU or range of LUs then it cannot connect to the host. This problem occurs whether or not an LU name is supplied.

: The following messages appear on the TN3270 console:
: %CMCC: slot4 [bad telnet connect]13[ipAddrClient]172.16.25.255:[tcpPortCl
: %CMCC: slot4 ----ient]0x40C:[connectReasonCode]0xE:[tn3270eDeviceType]IBM
: %CMCC: slot4 -----3278-5-E:[tn3270eDeviceName]:[tn3270eSubErr]no-naill:
: The workaround is to remove LU Nailing and restart the TN3270 server. Removing the LU Nailing command is not sufficient. Another workaround is to use a dynamic LU build. This build works with LU Nailing. [CSCdm36117]

The CIP running TN3270 Server receives DSI562I error messages on the NetView console. The messages indicate that in the activate physical unit (ACTPU) control vector 80, unsolicited network management vector transport (NMVT) request units are not allowed. The CIP TN3270 Server still sends product-set identification (PSID) NMVT messages for VTAM PUs with only LUs.

: There is no workaround.
: To enable the fix in the cip24-13 microcode, the maximum-lu command must be added to the TN3270 Server configuration file. [CSCdm36152]

The CIP VTAM session hangs at the VTAM message10 menu. This problem occurs when the user is at the VTAM message10 menu and hits multiple blank Enter keys and when the inbound request unit on the SSCP-LU session is 256 bytes or greater.

: There is no workaround. [CSCdm37663]

The CIP fails and causes a CBUS restart. Activating the VTAM external communication adapter (XCA) causes the CIP to fail with fatal error number 35. Repeated restarts and reactivation of the XCA produces the same results. This problem occurs when running Cisco IOS Release 11.2(18)BC and CIP microcode version cip24-11.

: The workaround is to use Cisco IOS Release 11.2(16)BC and CIP microcode version cip24-10. [CSCdm53220]

Every other CIP TN3270 Server client connection fails. This problem occurs when clients are trying to connect at a slow rate and the TN3270 Server is operating with a light traffic load.

: There is no workaround. [CSCdm55234]

Caveats for Version 24.10/Version 24.11 Modifications

This section describes possible unexpected behavior by Version 24.10. All the caveats listed in this section are resolved in Version 24.11. See Table 10 for the Cisco IOS software release that corresponds to the 24.11 microcode version.

The TN3270 Server crashes with fatal error code 35. See caveat CSCdk02535. [CSCdk11968]
A VTAM connect out completion time greater than 20 seconds causes unexpected connection failures and XCA major node failures. This failure occurs because VTAM overloads the PORT TIMER and, if the PORT TIMER is set too low, the LSA commands start to time out.

: VTAM version 4.3 introduced restrictions for the PORT TIMER value. The TIMER value cannot be less than the CMCC's T1 * N2. VTAM uses a hard-coded N2 value of 2. Before this fix, the CMCC reported a T1 value of 10. The VTAM documentation indicates that the T1 value is measured in tenths of a second. Therefore, a T1 value of 10 should equal 1 second. However, VTAM interprets the T1 value in seconds so a T1 value of 10 equals 10 seconds, not 1 second. VTAM then multiplies the value by 2 to get a minimum TIMER value of 20 seconds.
: The CMCC's reported T1 value is not the CMCC LLC T1 value. Because VTAM overloads the use of the PORT TIMER, do not adjust the CMCC's real LLC T1 value to alter the PORT TIMER. These adjustments can cause severe LLC2 problems.
: VTAM overloads the use of PORT TIMER. TIMER is used to set TEST request interval on connect outs. After each TEST request is sent, VTAM sets a timer equal to the PORT TIMER number of seconds and waits for a TEST response. If the TEST response is not received by VTAM before the timer expires, the next TEST request is sent. In CMCC scenarios, the first TEST request is a TEST local, the second is a spanning-route explorer.
: For the CMCC, most VTAM initiated LLC connections will not complete before the PORT TIMER seconds expire because the local TEST does not leave the CMCC's internal LAN. LLC connection setup requires a minimum of 20 seconds. VTAM will timeout on LSA commands if a response is not received within the set PORT TIMER value. For example, when VTAM sends a CONNECT request the CONNECT CONFIRM must be received before the PORT TIMER expires. The SABME and UA must be exchanged within the value set in PORT TIMER. If the SABME must be retried, the PORT ITMER might expire before the CONNECT CONFIRM is returned to VTAM.
: The workaround is to set the PORT TIMER value to 20 seconds or more unless the user is confident that the LSA commands will not timeout. [CSCdj45782]

An error occurs when using the TN3270 Server to establish a connection to an application residing on a Migration Data Host (MDH) using a virtual routing node connection network.

: If a prior connection to the MDH from the server does not exist, it might take several attempts to make a connection. Once the initial connection is made, all subsequent connections will work.

Note IBM VTAM has opened an APAR for the 8002 sense portion of this problem. Users must get the APAR PTF from IBM to get MDH to work with the virtual routing node on the CMCC.

: [CSCdk37107]

If a user disconnects without properly logging off the mainframe, a new user can connect to those existing sessions. This problem occurs when accessing Customer Information Control System (CICS) applications through the TN3270 Server. [CSCdk48736]
Inconsistent keepalives occur when multiple TN3270 sessions are configured to the same server. When the sessions are idle for an hour or more, keepalives are not sent even though the keepalive value is set to 300 (5 minutes).

: The workaround is to restart the session. [CSCdk57453]

Dynamic LUs remain in a P-NFT/UA state when the TN3270 Server is configured. The LUs cannot be used again when in this state.

: The workaround is to deactivate the LU or the owning PU in VTAM. [CSCdk60263]

The TN3270 session between the client and TN3270 server is disconnected when the client issues the logoff command at the VTAM MSG10 screen. [CSCdk80609]
When the TN3270 server is configured, entering the SYSREQ key followed by the logoff command does not return the user to the queued session. Instead, the VTAM MSG1 warning is displayed.

Other SYSREQ key errors that occur when the TN3270 server is configured include:

Pressing the SYSREQ key twice does not return the user to the LU-LU session. An LUSTAT is sent inbound on the second SYSREQ key entry.
Entering the logoff command incorrectly locks the session. SSCP-LU does not recognize the change direction in a sense data frame. This problem might occur in other remote cases.
LU-LU data shows up on an SSCP-LU session.
When responding to DACTLU in LU-LU or bound states, an inbound unbind should be sent. This inbound unbind was not working, but it was not evident because the client is normally disconnected which causes a SESSEND.

The workaround is to not use the SYSREQ key. [CSCdk83960]

CMCC devices with Bus and Tag connections do not activate properly when connected to an Amdahl 857 running the UTS operating system.

: There is no workaround. [CSCdk91964]

For extended periods of time, the write device for a CLAW connection experiences the same number of command retries and connects. Data throughput decreases significantly during these periods, but the connection is not lost. The connections and the command retries are displayed with the show extended channel slot/port command. This situation occurs when the channel operates at 95 percent or greater capacity for many hours.

: A workaround is to distribute the traffic to multiple boxes to avoid a channel capacity of 95 percent or greater. [CSCdk92004]

The CMCC TCP/IP Offload feature fails during select() processing when 28 or more sockets are defined in a single select request. If a select() request contains 28 or more socket descriptors in the descriptor list, the select() response is truncated after the offload message header. If the mainframe offload application does not validate the offload message header buffer_length field and detect the ZERO length response data, it may process random data in the memory which follows the offload message header as the start of response data and incorrectly interprets the select() response results.

: This problem does not occur when using select() under VM or MVS because select() is issued for one socket at a time. This problem occurs when using TPF if the select() request contains 28 or more socket descriptors.
: There is no workaround for this problem. This DDTS is a continuation of CSCdk86184. [CSCdm02126]

Caveats for Version 24.9/Version 24.10 Modifications

This section describes possible unexpected behavior by Version 24.9. All the caveats listed in this section are resolved in Version 24.10. See Table 10 for the Cisco IOS software release that corresponds to the 24.10 microcode version.

Certain ESCON conditions lead to LOGDATA error messages that result in a fatal error. The fatal error dump can cause the LOGDATA error messages to be lost. The lost LOGDATA messages contain critical information needed to determine the cause of the problems. The fatal error information usually contains secondary information about the problem.

: A workaround is to use the CIP core dump feature that is available in Cisco IOS Release 11.2BC and later. This feature saves all CIP memory to a file on an FTP server. The missing LOGDATA can be extracted from the core dump file. The workaround applies only for the CIP. [CSCdj61710]

A print job hangs when printing through the CMCC TN3270 Server. The Host application sends an exception response on the end bracket chain followed by a CHASE.

: There is no workaround. [CSCdk27199]

The TCP connection is closed (a FIN sent) before all data is sent. The remaining data (1 to 12 bytes) is sent after the connection is closed with another FIN. This problem occurs only with TCP connections that include TCP options in the TCP header and if the remaining data to be sent on the connection will fill up the packet before taking into account the length of the TCP options (12 bytes). This problem occurs when using the TCP large window support, which utilizes the TCP Timestamp option, implemented per RFC 1323.

: The workaround is to complete the following tasks:

Step 1 Log into the CMCC console:

if-con <CCMCC Slot> c

Step 2 Display the current state of this RFC:

ipconf <Offload IP Address> tcp_rfc1323

Step 3 Disable this RFC:

ipconf <Offload IP Address> tcp_rfc1323 off

Step 4 Verify the configuration change using Step 2. This RFC can be re-enabled, if necessary, using the same command but with the "on" option.

ipconf <Offload IP Address> tcp_rfc1323 on

Step 5 Exit the CMCC console:

quit (CIP21-x/CIP204-x releases)
if-quit or ^C^C^C (CIP22-x/CIP205-x and all later releases or XCPA26-x/XCPA214-x and all later releases)

: Unlike configuration commands issued from the router console, this CMCC configuration command is not retained if the CMCC or the router reloads or crashes and reloads. [CSCdk57139]

When running the CMCC TN3270 Server, LU 1 print jobs hang if the print application sends the RU chains as EXR (exception response) and the connection is running over a RFC1646-style TN3270 print connection.

: The workaround is to print the job using LU 3 printing or to reconfigure the print application to send the SNA RU chains with DR (definite response) requested. [CSCdk59063]

The CMCC TCP/IP Offload feature fails during select() processing when more than 27 sockets are defined in a single select request. Failures include premature response to select requests, corrupt descriptor list in the select response, and intermittent fatal error (code=32). These failures should only occur in Transaction Processing Facility (TPF) Offload environments.

: The workaround is to limit the number of sockets selected in a single select request to 27 or less. [CSCdk86184]

Caveats for Version 24.8/Version 24.9 Modifications

This section describes possible unexpected behavior by Version 24.8. All the caveats listed in this section are resolved in Version 24.9. See Table 10 for the Cisco IOS software release that corresponds to the 24.9 microcode version.

During connection, the CMCC TN3270 Server delays sending DEVTYPE IS to the client for up to one minute. The client shows a blank screen during the delay if the client requests connection to a specific LU, and that LU only became available within the last six seconds. The delay is generally much shorter than one minute. It is only that long if there are clients in the network taking 30 to 40 seconds to respond to the Timing Mark.

: The workaround is to delay reconnecting for six seconds or to disconnect and reconnect immediately upon noticing the delay. [CSCdk28081]

The AS/400 TN client attempts to establish an IBM-3180-2 terminal-type session with a TN5250 terminal. If a session is not available, the AS/400 TN client automatically switches to the TN3270 with a 3270 terminal type. The AS/400 TN client receives an ACK message from the 3180 terminal type when expecting a 5250 datastream. Instead, the TN3270 server sends it a 3270 datastream. Because the CMCC TN3270 Server accepts the IBM-3180-2 terminal-type the client does not switch to TN3270. [CSCdk37980]
The OFFL-3-NOMEM2 and OFFL-3-REJSOCK error messages indicate the same problem and should be combined into one message called OFFL-3-NOMEMSOCK. [CSCdk39425]
The CMCC adapter crashes with a fatal error code 35 when reconfiguring an offload statement using the same IP address that was used in a previously configured offload connection. This error occurs if the CMCC adapter has not completed deconfiguration cleanup of the previous offload statement before the new offload statement is configured using the same IP address. For example, the current configuration is as follows:

: offload e200 50 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: Reconfigure the offload statement as follows:
: no offload e200 50 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: offload e100 52 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: To workaround, after deconfiguring the offload statement, exit the configuration and issue the show extended channel slot/port ip-stack ip address command. When the offload deconfiguration is complete for the indicated offload statement IP address, the output should indicate "...No IP statistics found". At this point the new offload statement using the same IP address can be configured.
: The following is an example configuration:
: rispix#show ext ch 0/1 ip-stack
: IP Statistics for IP Address 80.11.198.2
: Forwarding : no DefaultTTL : 64 InReceives : 0
: InHdrErrors : 0 InAddrErrors : 0 ForwDatagrams: 0
: InUnknownProtos: 0 InDiscards : 0 InDelivers : 0
: OutRequests : 0 OutDiscards : 0 OutNoRoutes : 0
: ReasmTimeout : 60 ReasmReqds : 0 ReasmOKs : 0
: ReasmFails : 0 FragOKs : 0 FragFails : 0
: FragCreates : 0 RoutingDiscards: 0

: rispix#config t
: Enter configuration commands, one per line. End with CNTL/Z.
: rispix(config)#in ch 0/1
: rispix(config-if)#no offload e200 50
: rispix(config-if)#end
: rispix#
: 01:22:25: %SYS-5-CONFIG_I: Configured from console by console
: rispix#show ext ch 0/1 ip-stack
: ...No IP statistics found

: [CSCdk45042]

Caveats for Version 24.7/Version 24.8 Modifications

This section describes possible unexpected behavior by Version 24.7. All the caveats listed in this section are resolved in Version 24.8. See Table 10 for the Cisco IOS software release that corresponds to the 24.8 microcode version.

When running the CMCC Offload feature, the WRONGDESC error message was displayed if the host application issues a socket purge request using the host descriptor instead of the offload box socket descriptor. Socket purge requests are normally issued by VM/MVS/TPF TCP/IP applications when closing a socket.

: The message is misleading because the host application must sometimes use the host descriptor if it has not been notified of the offload box socket descriptor. This occurs when an error is detected during socket connection establishment. The WRONGDESC error message has been removed. [CSCdj92653]

When using TN3270 Server to connect to NetView when the NetView type ahead feature is used the LU-LU session can be stuck with a PROG MSG. Customer needs to recycle LU to continue.

: The workaround is to recycle the LU in VTAM and restart the session.[CSCdk11361]

CMCC TN3270 Server's DLUR session is unbound by DLUS with sense 1002 (RU length error) soon after the DLUR-DLUS pipe is established. This occurs when 10 or more LLC links connected to DLUR generate a topology database update (TDU) to DLUS that exceeds the maximum RU size specified in the Bind. The CP-CP session can fail with the same sense code for the same reason. In this case, the RU that exceeds the maximum RU size is the one specified in the locate which DLUR sends to find the DLUS.

: The workaround is to reduce the number of LLC links available to DLUR until the DLUR-DLUS pipe is established. [CSCdk11790]

During a brief TCP connection, the CMCC TCP/IP Offload feature fails to return a response to a Read/Recv type socket request causing the connection's host application to hang while waiting for a response.

: A window exists for brief TCP connections when a connection is made with TCP/IP on the CMCC and then broken (FIN received) before Offload has received and processed an Accept socket request from the host. In this situation, Offload misses the notification from TCP/IP that the connection had been terminated.
: There is no workaround. [CSCdk12291]

When the MSG_PEEK flag was set on a RECV, RECVwait, or RECVwaitFORfin socket request, only the Offload message header and response header were returned to the host. The buffer length field in the Offload message header indicated MSG_PEEK data was present in the message but no data was sent to the host. This problem causes TPF offload applications to collect invalid data when accessing the MSG_PEEK data.

: There is no workaround. [CSCdk14244]

An error in the channel connection causes incorrect channel events, sometimes accompanied by LOGDATA, resulting in an SSI_ASSERT in attn_state_fsm in cta/cta.c with the following message:

SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta/cta.c @ 350 - FALSE

: There is no workaround. The user must cycle the XCA node. [CSCdk14424]

CMCC TN3270 Server's session switch feature (DLUR End Node) does not support parallel transmission groups (TGs). Only one LLC link is permitted between the end node and each of its adjacent APPN nodes.

: Parallel TGs can be used to provide redundancy. [CSCdk15431]

An architectural constraint causes CMCC TN3270 Server's DLUR to report only approximately 20 of the links to DLUS. This prevents LU-LU sessions from being routed over the unreported links. The topology database update (TDU) message reporting the links is limited to 1024 bytes. In order to report more links, DLUR has to send multiple TDUs.

: The workaround is that once the DLUR-DLUS pipe is established additional links will be reported if they become active.[CSCdk15446]

After changing or removing a configured virtual routing node (VRN) on a CMCC TN3270 Server dlur lsap, VTAM still shows the VRN D NET,TOPO,ORIG=dlurname,DEST=vrnname as OPER. VTAM shows the resource sequence number (RSN) as odd, indicating some uncertainty. This uncertainty is because DLUR fails to increment the RSN when sending the TDU (topology database update) generated by the VRN name change.

: A workaround is to close and then reopen the DLUS-DLUR pipe by using the VTAM V NET,INACT,ID=dlurname command. This will not disrupt the LU-LU sessions if the dependent PUs are configured ANS=CONT. New sessions cannot be established while the pipe is down. [CSCdk21067]

BADTIMER messages appear when running TN3270 Server. In this case, the messages appear because a TN3270 session is being negotiated or recently has been negotiated. The messages do not impact normal TN3270 Server operations.

: There is no workaround. [CSCdk21633]

When using a logon manager through CMCC TN3270 DLUR, the logon manager queues a session for the SLU to recover the session after the user has finished an application. VTAM sends UNBIND 02 (bind forthcoming). The CMCC TN3270 Server LU sends an UNBIND +RSP and the DLUR sends SESSEND with code 0A (SSCP gone). This forces SSCP to clean up the queued session from the logon manager. The expected PREALC-P session from the logon manager no longer exists. Using CMCC TN3270 Server DLUR EN capability, connect to a logon manager such as NetView access or TPX. [CSCdk29362]

Caveats for Version 24.6/Version 24.7 Modifications

This section describes possible unexpected behavior by Version 24.6. All the caveats listed in this section are resolved in Version 24.7. See Table 10 for the Cisco IOS software release that corresponds to the 24.7 microcode version.

OpenConnect has an informal extension to the Termtype in TN3270. When connecting through an OpenConnect TN3270 gateway, the client IP address is concatenated on the end with a percent (%) symbol.

: The CMCC TN3270 Server does not use this client IP address for matching on LU nailing statements in the configuration. [CSCdj44584]

When running CMCC TN3270 Server, the CMCC adapter reports fatal error code 35 and reloads. This error occurs when the CMCC adapter is running low on memory and a packet arrives that is larger than the SNA inbound request/response unit (RU) size. Typically, this error occurs when the router is running transports such as FDDI between the CMCC adapter and the client.

: The workaround is to increase the inbound RU size defined in the host logmode tables. [CSCdj76007]

With Offload, a socket can be closed in a way that the control block lingers for 60 seconds. If an attempt is made to re-establish the same connection before the 60 second period has expired, connection failure may occur. [CSCdj80952]
The MSG_PEEK flag on the RECV, RECVwait, and RECVwaitFORfin socket requests was ignored (for example, RECV requests were treated like READ requests). This error causes transaction processing facility (TPF) offload applications to drop incoming data if MSG_PEEK was used with RECV requests.

: There is no workaround. [CSCdk00532]

The CMCC adapter fails because of corruption in SNA-related code. Very small timing windows, which occur in unreliable or high latency networks, can cause this failure. These networks create many asynchronous balanced mode extended (SABMEs), which can trigger this bug.

: The workaround is to tune the LLC timers to reflect true delays in the network. [CSCdk02032]

CMCC adapter crashes with fatal error 35. The CMCC adapter reports the following message:

bad LU on DISC...


: This error is caused by CSCdj81522. The crash may occur if a TN3270E client connects and does not negotiate bind-image.
: The workaround is to ensure that all clients support bind-image. [CSCdk02535]

Repeated inact/act of the XCA major node or the switched major node causes the TN3270 PUs to become stuck in a RESET/XID cycle.

: The workaround is to shut and then no shut the TN3270 Server. [CSCdk03985]

The CMCC TN3270 Server connects then disconnects a client. This occurs with LOGAPPL applications when the client sends data to the host application and the host's response to Notify reaches the server after the bind.

: The workaround is to reconnect. [CSCdk06887]

A connection can be terminated if the flowoff condition is reached. [CSCdk07022]
During bulk transfer operations that move data to the host, throughput to the host is limited by overhead on the channel causing channel utilization to approach 100 percent. Use the show controller cbus command to determine the ECA utilization. The ECA statistic is updated once a minute.

: There is no workaround. [CSCdk08438]

The CMCC microcode reports a fatal error and reloads. This is an infrequent problem that occurs when there is a very small timing window. [CSCdk08533]
Client disconnected when the host sent dactlu followed by actlu. In VTAM through cross domain, the host can send dactlu followed by actlu to clean up the lu session, but not to disconnect the lu session. [CSCdk08642]
The CMCC microcode reports a fatal error and reloads. This occurs when unconnected PUs attempt to send XIDs and TEST frames to the host. The PU timer expires and corrupts the TN3270 Server timer-queue. This occurs either when the PU disconnects or when a NULL XID is about to be sent to the host.

: The workaround is to ensure that all PUs are either shutdown or connected. [CSCdk09978]

When the connection to a host from the CMCC TN3270 Server is not via the channel, data corruption may occur, resulting in bad XIDs or Binds being reported.

: There is no workaround. [CSCdk10071]

TN3270 user cannot log on because the keyboard is locked. The keyboard can lock if a TN3270 user presses an invalid AID key (such as PF or PA) before logging on to a host application. This does not occur with TN3270 clients or LOGAPPL'd LUs.

: The workaround is to locally clear the keyboard lock, if the client supports such a feature. Otherwise, the user must disconnect and reconnect. [CSCdk10200]

The TN3270 Server refuses new TCP connections. This lasts for 2 to 20 minutes depending on the number of TCP requests. This occurs when there is one-way network congestion between one or more clients and the server. The congestion direction must be from the server to the client. The congestion causes the client not to see the SYN/ACK coming from the server and the client resends the SYN.

: There is no workaround. [CSCdk11113]

The CMCC adapter reports the IPC-NO-MEMD message and hangs. This occurs when CMCC adapter host communications have been cut off before a hierarchical reset. [CSCdk11787]
When the MSG_PEEK flag was set on a RECV, RECVwait, or RECVwaitFORfin socket request, only the Offload message header and response header were returned to the host. The buffer length field in the Offload message header indicated MSG_PEEK data was present in the message but no data was sent to the host. This problem causes TPF offload applications to collect invalid data when accessing the MSG_PEEK data.

: There is no workaround. [CSCdk14244]

Caveats for Version 24.5/Version 24.6 Modifications

This section describes possible unexpected behavior by Version 24.5. All the caveats listed in this section are resolved in Version 24.6. See Table 10 for the Cisco IOS software release that corresponds to the 24.6 microcode version.

Support for the IP Host Backup and CLAW Packing features has been added to CMCC microcode for Cisco IOS Release 12.0. [CSCdk03281]
The CMCC adapter reports fatal error code 35 when running TN3270. Before the fatal error, the CMCC adapter reports the following error message:

%CIP24-4-MSG: %TN3270S-4-NO_LU_SESSIONS: No LU sessions left for PUs at IP addr a.b.c.d, port x

: The problem may occur when the maximum-lu limit has been reached or when no more LUs are available at a given TN3270 Server listening point.
: The workaround is to increase the maximum-lu limit to a level that will not be reached during operation of the server. Also, the user should increase the number of PUs (really LUs) on each listening point. [CSCdj80602]

With Offload, a socket can be closed in a way that the control block lingers for 60 seconds. If an attempt is made to re-establish the same connection before the 60 second period has expired, connection failure may occur. [CSCdj80952]
Additional information was added to the CMCC fatal error output report.This will help identify the events leading up to the failure. [CSCdj85568]
The channel transport architecture device is informed of the connection count irrespective of the order in which the channel transport adapter and LLC2 register. [CSCdj87846]
The CMCC DLUR repeatedly tries to establish CP-CP sessions with an incompatible NN server and fails to try other links for a NN server in the following conditions:
- When using CMCC TN3270 Server DLUR/DLUS with preferred-NNserver configured, when the DLUR is varied inactive by lu/cpname on the primary host and is defined statically on the primary, as cross-domain resource (CDRSC) or LU, but the link between the primary and the CMCC adapter is left active. This situation makes controlled SSCP takeover difficult.

: The workaround is to not configure preferred-NNserver. [CSCdj87854]

When running fast mainframe processors in offload mode, 10-20 percent of the channel bandwidth can be wasted by improperly handling the more-to-come processing within the CLAW protocol.

: There is no workaround. [CSCdj88636]

If a DMA write error occurs on the CIP in the process of sending a packet to the Cisco IOS software, the CIP could go into an infinite loop when the CIP interface the DMA error occurred on is shut down or the router performs a cbus complex restart. [CSCdj90280]
At show ext cn/2 pu/lu, some dddlu LU names appear blank if Host applications send NULL slu data in the bind.

: There is no workaround. [CSCdj90734]

Sometimes outbound data is randomly corrupted. This situation occurs with CMCC images in Cisco IOS Release 11.2(BC) if the TN3270 PUs are attached to VTAM by Token Ring (rather than channel attached) and some clients are running 3270 extended datastream. The problem usually occurs after file transfer of binary data.

: There is no workaround. [CSCdj90738]

A reset of the CIP virtual interface configured with LLC2 can cause MEMD buffer errors resulting in a cbus complex restart. [CSCdj90822]
The CMCC TN3270 Server command show extended ch x/2 tn3270 pu lu history may cause the router to reload. This situation happens if the LU's history buffer contains an event indicating that it received data from the client after it sent unbind to the client.

: The workaround is to not use the show lu history command. [CSCdj91756]

When the maximum-lu is reached, clients cannot connect for a few minutes. Usually only one listening point is affected.

: The workaround is to increase the maximum-lu in the configuration so that the maximum-lu will not be reached. [CSCdj92158]

The CMCC adapter returned User Datagram Protocol (UDP) data with 32 bytes less than expected to the host application under transaction processing facility (TPF). TCP/IP running Offload is not affected by this problem.

: There is no workaround. [CSCdj93915]

The CMCC adapter fails because of corruption in SNA-related code. Very small timing windows, which occur in unreliable or high latency networks, can cause this failure. These networks create many asynchronous balanced mode extended (SABMEs), which can trigger this bug.

: The workaround is to tune the LLC timers to reflect true delays in the network. [CSCdk02032]

CMCC adapter crashes with fatal error 35. The CMCC adapter reports the following message:

bad LU on DISC...


: This error is caused by CSCdj81522. The crash may occur if a TN3270E client connects and does not negotiate bind-image.
: The workaround is to ensure that all clients support bind-image. [CSCdk02535]

Caveats for Version 24.4/Version 24.5 Modifications

This section describes possible unexpected behavior by Version 24.4. All the caveats listed in this section are resolved in Version 24.5. See Table 10 for the Cisco IOS software release that corresponds to the 24.5 microcode version.

If the channel transport adapter device registers after the LLC2, the LLC2 informs the channel transport adapter of the connection count. [CSCdj32856]
Under certain conditions during memory allocation, the CIP can encounter a fatal error upon completion of a direct memory access transfer from or to MEMD. The fatal error code is typically 35 and it can coincide with the following message:

"RSP-3-RESTART: Interface Channel4/x, output stuck

: This error can be triggered by all software features with the exception of CLAW (IP datagram). It is more likely to occur with features that use a lot of memory, like the TN3270 Server. [CSCdj52480]

The CMCC Adapter reports a BSQ-x-SCB_CHAIN error message indicating that the read SCB chain is out of sequence. The problem is caused by unusual conditions during status presentation such as ESCON link errors. There is no workaround. [CSCdj61319]
The CMCC TCP/IP stack uses path MTU discovery (RFC 1191) to select the size of an outgoing IP packet. The algorithm used does not work if the IP layer adds IP options to the packet. If this situation occurs, TCP connections will hang and eventually timeout as soon as they try to send a segment larger than the smallest MTU in the path. Of all the problems that could lead to dropped TCP connections because of path MTU discovery, this is probably the least likely to occur. It is much more common that the problem is caused by an improperly designed network (for instance, a configuration with a bridge connecting two networks with different MTUs) or a misconfigured router that does not send an ICMP type "Destination unreachable" with code "Fragmentation needed but DF bit set".

show extended channel slot/port ip-stack
show extended channel slot/port icmp-stack
show extended channel slot/port tcp-stack
show ip traffic

[CSCdj65774]

In networks with a high volume of type 1 traffic (typically XIDs) the VTAM may combine many type 1 messages in a block, mistakenly causing the frame to appear badly formed and resulting in the ASSERT message and an automatic reload of the CMCC image. This problem occurs only with cip21-19 images and earlier. It does not happen with cip22-xx and higher.

: The workaround is to artificially limit the rate at which remote stations can connect by adding delays to a startup script. [CSCdj69281]

The kernel timeout function hits a fatal error when called with a negative time value. For example, this will happen if the Offload code gets a connect request with a timeout value of 0x7fffffff seconds.

: The workaround for the offload problem is to reconfigure for IP datagram mode. There is no workaround available for the bug in the kernel timeout function. [CSCdj72646]

On a Cisco 7000 router with a CIP, if all interfaces on the CIP are shut down when the CIP is loaded then the interprocess communication (IPC) subfacility will not work on the CIP even after no shut commands are issued for the interfaces. [CSCdj74844]
CMCC TN3270 sessions can linger for up to 10 minutes after the PU that the sessions ran through is shut down. This situation causes subsequent activations of the XCA major node to fail at the host because the CMCC adapter/SAP is not ready to open.

: A workaround is to issue a shut and then a no shut command on the TN3270 Server, causing the connections to be brought down quickly. [CSCdj76280]

Following a reload, microcode reload, or after a no shutdown command is issued, IBM's MVS TCPIP could complain about channel status of x'06'. This problem occurs following a resetting event condition where MVS IOS expected to have cleared the resetting event condition prior to the event actually occurring. The recovery mechanism that is already in place should recover from this error. If the channel interface is always shut down prior to a reload or microcode reload and this fix is applied, the host should stop complaining about the channel status of x'06'. [CSCdj78947]
The CMCC Adapter reloads spontaneously after the following error message:

%CTA-0-UNEXP_LSI_CMD: PA1 CTA C020-56 received LSI command 0x4D11 at 0x8042CA8C

: An unrecognized command code was recognized during communication between the LLC2 and CSNA components on the CMCC Adapter. This problem has never been detected in customer use, and has only been seen during the debugging of a new feature. However, the problem could be caused by configuring High Performance Routing (HPR) in a remote device.
: The workaround is to reconfigure the remote device to not specify HPR. [CSCdj79403]

This problem results in the mainframe complaining about SIOCC2, which is a start I/O condition code 2. SIOCC2 is an indication that the device is busy for an extended period of time. Without this fix, the problem can be worked around by shutting down the CMCC interface and then bringing it up again. [CSCdj80886]
The CSNA responds to the TEST command when no SAP is active. This error may result in an end station trying to connect to a CMCC Adapter that has no connectivity to the host. This situation occurs when the CSNA interface is shut down manually or by other media problems (for example, a loose cable). [CSCdj80925]
The CMCC Offload code prints an OFFL-0-WRONGFREE error message and hits a fatal error. This problem occurs if the read channel program ends in the middle of a socket response that spans more than one CLAW buffer and a halt subchannel is issued before the read channel program resumes.

: There is no workaround. [CSCdj80990]

During the recovery from certain error conditions in the CMCC TN3270 Server, the CMCC Adapter may sometimes report a Fatal error message (code=35) and spontaneously reload. [CSCdj81522]
The CMCC microcode may log the message "Fatal Error 35" and spontaneously reload. This situation can happen if the CMCC TN3270 Server session switch (DLUR) feature is being used and either the DLUR component or TN3270 Server is shut down or deconfigured while there are configured DLUR links. The workaround is to remove the DLUR links first, using no link name. [CSCdj82232]
CSNA fails to send disconnect when indication buffer is in use. This causes the following results: the end-station is not able to connect back in and if the connection is flow-off, it will remain in flow-off state. [CSCdj82785]
With certain TN3270 client software, the user can successfully establish an LU-to-LU session, but when the user enters the first data after the bind, the CMCC TN3270 Server disconnects the client. The CMCC TN3270 Server logs the fact that it received invalid Telnet data from the client.

: The problem occurs only with certain clients (for example, PC3270 and Attachmate) and when the user enters data before the host application sends out its first screen (most applications send a screen of data immediately after the bind, start data traffic).
: Because the problem only occurs in TN3270E mode, and some clients have an option to disable TN3270E mode, it is possible to bypass this problem in situations where TN3270E mode is not required. The alternatives are to use a different client or change the host application. [CSCdj84064]

When a TN3270E client connects to a CMCC TN3270 Server and enters a log on request, the server sometimes discards the request and sends a "-B" message to the client. This message becomes appended, on the screen, to the log on request data. If the user now presses enter, the host replies with the following message:

"unsupported function".

: This problem occurs if the same LU can be used by TN3270 and TN3270E clients.
: The workaround is to retry the log on request. [CSCdj84122]

In some customer environments, LOGDATA records that consist of multiple error messages can result from the mainframe not responding to device level activity for longer the 500 ms. The ESCON architecture states that this timeout value can range from 400 ms to 850 ms. To avoid some of the occurrences of LOGDATA, adjust the timeout from 500 ms to 800 ms. [CSCdj84218]
Sometimes outbound data is randomly corrupted. This situation occurs with CMCC images in Cisco IOS Release 11.2(BC) if the TN3270 PUs are attached to VTAM by Token Ring (rather than channel attached) and some clients are running 3270 extended datastream. The problem usually occurs after file transfer of binary data.

: There is no workaround. [CSCdj90738]

Caveats for Version 24.3/Version 24.4 Modifications

This section describes possible unexpected behavior by Version 24.3. All the caveats listed in this section are resolved in Version 24.4. See Table 10 for the Cisco IOS software release that corresponds to the 24.4 microcode version.

For Offload and CLAW devices, if the write device (odd device number) on the mainframe is misconfigured to talk to the read subchannel (even device number), the CIP could crash with an SCBNRDY error message.

: The workaround is to properly configure the devices on the mainframe. The most likely cause of the problem is in the virtual machine (VM) if the write device is attached to the read subchannel. In this scenario, detach both devices (read and write) and reattach them to the correct subchannel. [CSCdj23802]

With a TN3270 Server, if a CIP application shuts down its own TCP connection, it sends out a FIN (finish) segment. If it never receives a FIN from the peer, the local side of the connection will stay in FIN_WAIT_2 state even after the application closes the socket completely. [CSCdj48609]
Memory is leaked by the CIP TCP/IP if a direct memory access (DMA) controller write operation detects an error. [CSCdj48929]
When a TN3270 client is powered down without terminating the TCP/IP session with the CIP, the TIMING-MARK and TCP retransmissions tear down the connection. If a client is unable to work with TIMING-MARK and uses a previously specified LU name then it will be unable to reconnect. [CSCdj51696]
Under certain conditions during memory allocation, the CIP can encounter a fatal error upon completion of a direct memory access transfer from or to MEMD. The fatal error code is typically 35 and it can coincide with the following message:

"RSP-3-RESTART: Interface Channel4/x, output stuck

: This error can be triggered by all software features with the exception of CLAW (IP datagram). It is more likely to occur with features that use a lot of memory, like the TN3270 Server. [CSCdj52480]

If several of the TN3270 Server PUs are configured under DLUR and are INACT or unknown at the host, then the process of stabilizing the DLUR-DLUS pipe can be prolonged thereby preventing PUs from activating.

: This situation occurs with certain patterns of "good" and "bad" PUs. For example, out of a total of six PUs, the first five could be INACT at the host and the sixth could be CONCT.
: The workaround is to shut down the PUs on the CIP or make them active at the host. [CSCdj54138]

When the customer attempts an initial program load (IPL) to a Hitachi mainframe running IBM VSE 1.4.1 with Connectivity Systems TCPIP stack for VSE, the system goes into a loop and the CIP appears to be in an offline state. After several attempts to trace the problem on the CIP, the following trace indicates the CIP failed to respond:

Channel (F7)             Cisco/CIP        Explanation
 
   ALA    ==================>         (CH sends Aquire Link Address) 
          
          <=================   ALA    (CU sends Aquire Link Address) 
 
   ACK    =================>          (CH acknowledges request from CU) 
 
           End of Communication       (CU never acknowledges request from CH)

: [CSCdj55448]

During peak times of logon-rate and network congestion, end users cannot access the CIP TN3270 Server for extended periods of time (5 to 15 minutes). Existing TN3270 sessions exhibit normal response times during these periods, but new connections are locked out. [CSCdj56273]
This problem introduces a feature called "IP Host Backup". With this feature, CLAW and OFFLOAD configuration commands can be defined in "backup groups". Every command belonging to a particular backup group uses the same IP address. For a complete description of this feature see the Cisco IOS 11.2BC Feature Guide which is updated with every interim release of Cisco IOS 11.2BC. [CSCdj58396]
The SNA sense code 2003 is sent to the host that is causing the client to disconnect. If the host has the direction and the client sends data, the data will be queued. Later, when the host sends data with the EBI bit on, the client data will be sent. However, subsequent data from the host will get a negative response.

: The workaround is to reconnect the client. [CSCdj58664]

A TN3270E disconnects after the host sends an unbind message. When the user presses the F3 key to end the LU-to-LU session, the session is disconnected instead.

: The workaround is to reconnect the client. [CSCdj59985]

If CIP TN3270-Server DLUR is configured with a link to VTAM over a CMPC tg, the link will not activate and the XID negotiation will fail.

: With the DLUR EN active, inact force the vtam local node by issuing the /v net,inact,id=mvsln,f command. Then try to activate the local node by issuing the /v net,act,id=mvsln command
: The workaround is to issue a shut command then no shut command on the TN3270 Server DLUR. Alternately, do not configure the link from DLUR EN to VTAM. Configure it only from VTAM to DLUR EN. [CSCdj63054]

There is a CIP fatal error in the IP Input task when running Offload or TN3270 Server.

: This bug occurs only if a new IP fragment received by the TCP/IP stack completely overlaps a fragment that is already on the reassembly queue. As a result of the overlap, the fragment on the queue is freed. There is a bug in the code where the memory used to hold this IP fragment is accessed after it is freed. This access can lead to a fatal error if the IP Input task gets preempted at the right time.
: The workaround is to apply an outbound access list that denies IP fragments on the channel interface. This action may break UDP applications and TCP applications that do not use path MTU discovery. If an IP node generates them, it should be sufficient to block fragments from just that IP source address. [CSCdj63361]

CIP configuration statements are lost with associated CIPCFGFAIL and CIPCMDDROPPED messages. This problem occurs only with large configurations that have approximately 64 channel configuration statements.

: The workaround is to reenter the dropped statements manually. This workaround increases the number of CIP configuration statements that can be handled to 128, and is a temporary fix until CSCdj44143 is implemented. [CSCdj63815]

While parsing messages, the offload code does not check each message for proper formatting. Corrupted blocks appear to contain a large number of Offload messages (up to 128 per 4 KB CLAW frame). Because there are not enough control blocks to handle this many messages, the CIP hits a fatal error. This problem should not occur if Offload messages are properly formatted.

: There is no workaround. [CSCdj64309]

In an environment where there are ESCON link-level errors occurring, the CIP may log the following message and reload:

%CIP25-0-MSG: %CCA-0-DEV_ERR2: Device error but no active defined device.

: The CIP's ESCON processor may lock up in the middle of connection recovery following link-level errors. The neighboring ESCON link-level facility (host or director) will report a sequence timeout followed by a not operational sequence (NOS) detected.
: There is no workaround. [CSCdj64563]

An RFC 1646 printer hangs when a client sends a negative response before it receives the whole frame and the negative response is not sent to the host.

: The workaround is to reconnect the printer. [CSCdj65302]

Any IP packet generated by the CIP's TCP/IP stack which contains IP options could contain an invalid TCP, UDP or ICMP checksum. The destination host will discard any such packet because the checksum does not match. [CSCdj65535]
After a few thousand disconnects, the VTAM gets the following error message:

IST565I..<nocmdBold>

: When the VTAM receives a NMVT power-off PSID, it may lose buffers. The workaround is to enter opt70 nmvt_psid 0 at the console port to disable sending the PSID. [CSCdj66921]

When a PC tries to bring up a session, the VTAM rejects it with the following connection request denied error message:

IST381I  AM SC EXIT FOR ID = T7751    FAILED - CANNOT DEFINE NODE
IST680I  CONNECTION REQUEST DENIED - ID = T7751    INVALID NETWORK NAME
IST1394I  CPNAME = NETVGI.T7751       STATION ID = 020005D07751
IST081I  LINE NAME = L0750C93, LINE GROUP = GXCA750 , MAJNOD = XCA750
IST314I  END


: There is no workaround.
: When a large number of sessions are abnormally terminated because of an invalid configuration of LLC parameters, the CSNA terminates the connection, but fails to notify VTAM. This results in the VTAM continuing to hang on to the session and the end stations trying to reconnect to the host. [CSCdj68124]

CSNA has a restriction on the usage of SAP value 6, which is reserved for DODIP (Department of Defense IP). This restriction has been removed. [CSCdj68133]
A CSNA user can regulate new connections by lowering the connection threshold below the maximum LLC originally specified. This change results in the CSNA not responding to the test frame from an end-station when session counts exceed the connection threshold. No new connection is brought up through the CIP. [CSCdj68517]
CIP microcode reloads occasionally when the user issues a shut command then a no shut command when in the CIP TN3270 Server command mode. This problem occurs only when there are active TN3270 sessions connected to the CIP.

: The workaround is to shut each of the PUs associated with the TN3270 Server and then issue a shut command and a no shut command on the TN3270 Server. Issue a no shut command on the PUs again. [CSCdj69368]

When the offload code on the CIP and the TCP/IP offload code on the mainframe begin to communicate, they exchange restart requests and responses. Under certain conditions, the restart requests and responses from the CIP could contain invalid data. The mainframe will react to this condition with the following error message:

Unexpected result from offload device ..

: The mainframe will dump the offending offload message that contains the text "Data runs off end of buffer".
: There is no functional impact. [CSCdj69527]

If the CIP runs low on memory while the CIP TN3270 Server DLUR (SNA session switch) function is in use, then the CIP may reload spontaneously. [CSCdj70138]
The kernel timeout function hits a fatal error when called with a negative time value. For example, this will happen if the Offload code gets a connect request with a timeout value of 0x7fffffff seconds.

: The workaround for the offload problem is to reconfigure for IP datagram mode. There is no workaround available for the bug in the kernel timeout function. [CSCdj72646]

If more than 64 channel commands are configured and a microcode reload command is issued, the following error message will appear for each configuration command and the configuration command will be dropped by the CIP:

CBUS-3-CFGCMDDROPPED: Config queue is full, command was dropped, slot 0
%CBUS-3-CIPCFGFAIL: Channel0/2: configuration command TN3270S_PU_LU_NAIL cmd 27 failed

: The workaround is to use cip24-4 or cip25-4 microcode. This microcode allows the user to configure 512 configuration commands. If more commands are required, upgrade to Cisco IOS Release 11.2BC. This release allows 1024 channel configuration commands. [CSCdj75050]

Caveats for Version 24.2/Version 24.3 Modifications

This section describes possible unexpected behavior by Version 24.2. All the caveats listed in this section are resolved in Version 24.3. See Table 10 for the Cisco IOS software release that corresponds to the 24.3 microcode version.

Despite "unbind-action keep" being configured, the TN3270 Server disconnects a TN3270/E client if Sysreq is followed by any key. This disconnection is not a problem if sysreq is not used to close an LU-LU session.

: The workaround is to either not use sysreq or to reconnect the client if an SSCP-LU session is required. [CSCdj21850]

Sending a ping greater than 4096 bytes in length to a CIP TN3270 Server IP address will cause the CIP to hang and consume all available CIP memory. [CSCdj39225]
Although an NMVT PSID was sent to VTAM during the connection state, a PSID was not sent to VTAM during disconnection. Sending both PSIDs allows network management to know the connection time of the clients. [CSCdj39365]
The following changes have been made to address some TEST command issues:
- Answer TEST CMD other than DSAP of 0x0 if it is activated.
- The TEST CMD is dropped if the adapter has not activated the SAP or if the maximum number of connections has been reached.
- The TEST CMD is dropped while the SAP is in the deactivation processing mode. [CSCdj41342]
When a TN3270E connects, a new LU is selected. This selection causes the LU to cycle once and likely cause a connection failure. [CSCdj43047]
When using the offload feature, if a Halt Subchannel is issued from the mainframe when the offload read subchannel is busy with more-to-come chains, the CIP could fail in many ways. The problem could result in a fatal-error as a result of freeing and invalid addresses (for example, 0 or a non-four-byte aligned address) to the global page queue. The problem could also result in a fatal error as a result of the ESCON processor (ESCP) locking. It is unlikely that this problem will occur because the mainframe rarely performs a Halt Subchannel on busy connections. [CSCdj43959]
When recycling a LOGAPPL application that is connected to a CIP TN3270 Server, one or more PUs can remain in flow-control state. This scenario can cause the PU to go into ACT/BUSY state and terminate all LU traffic going to users.

: The workaround is to recycle the PU. [CSCdj46065]

With a TN3270 Server, if a CIP application shuts down its own TCP connection, it sends out a FIN (finish) segment. If it never receives a FIN from the peer, the local side of the connection will stay in FIN_WAIT_2 state even after the application closes the socket completely. [CSCdj48609]
A TN3270 client, which is mapped to a specific LU, fails upon reconnection. Although the first connection is successful, when the client disconnects and then tries to reconnect, the connection attempt will fail. [CSCdj48876]
DLUR PUs can stick in PAPU2 state. Recycling (by issuing a shut command and then a no shut command) the DLUR does not help. This condition occurs if all of the DLUR PUs are made inactive at the host, but the DLUR EN PU is active. The repeated attempts of DLUR to activate the PUs result in buffer loss in the CIP. Eventually a pool of buffers becomes empty and no ACTPUs are processed.

: The workaround is to recycle the TN3270. [CSCdj50517]

The actual amount of supported max-llc2-sessions is one less than what is configured. The workaround is to ensure adequate margin in the max-llc2-sessions specification. [CSCdj51067]
For CSNA devices, multiple LOGDATA records can occur as a result of the corruption of the count in the data request frame. Usually when multiple LOGDATA records occur, it is for some other reason (for example, a bad fiber connection). The way to verify that it is this problem, is to put an ESCON analyzer on the ESCON connection and trigger the beginning of connection recovery (UD sequence).

: There is no workaround. [CSCdj51076]

The host XCA node goes down or an attached PU or LU goes into the INOP state after installing a CIP image.

: The workaround is to revert to a previous CIP microcode version or install the next release, which does not contain this problem. [CSCdj51725]

The SNA sense code 2003 is sent to the host that is causing the client to disconnect. If the host has the direction and the client sends data, the data will be queued. Later, when the host sends data with the EBI bit on, the client data will be sent. However, subsequent data from the host will get a negative response.

: The workaround is to reconnect the client. [CSCdj58664]

The offload code can hit a fatal error after an OFFL-3-ILLEN or OFFL-3-ILLALH error message. There is no workaround for this problem; however, the error conditions leading to those error messages are rare.

: Another problem that was fixed was an OFFL-6-WRCHAIN error message when running TPF Offload. [CSCdj59133]

There exists a small timing window that may cause the LLC2 connections to hang when the connection enters the ERROR state. This problem prevents the user from being able to change to XCA mode. [CSCdj59231]
During high traffic and usage of varying frame sizes, the following error message may occur:

SSI_ASSERT crash in ssi_msg_offset function.

: The workaround is to reduce the PIU size. [CSCdj61634]

While parsing messages, the offload code does not check each message for proper formatting. Corrupted blocks appear to contain a large number of Offload messages (up to 128 per 4 KB CLAW frame). Because there are not enough control blocks to handle this many messages, the CIP hits a fatal error. This problem should not occur if Offload messages are properly formatted.

: There is no workaround. [CSCdj64309]

Caveats for Version 24.1/Version 24.2 Modifications

This section describes possible unexpected behavior by Version 24.1. All the caveats listed in this section are resolved in Version 24.2. See Table 10 for the Cisco IOS software release that corresponds to the 24.2 microcode version.

The Offload write task does not terminate after deconfiguring the offload if the host has sent frames on the write subchannel IP link. The only known side effect is that this task will take up an entry in the task table and some memory. [CSCdj37835]
The shutdown process never completes, and a microcode reload is required when a shutdown command is issued on the virtual interface. This condition occurs when a connection is configured between a CIP multipath channel transmission group and an APPN node and the TRL and SNA local nodes are activated.

: The workaround is to inactivate the SNA local node before shutting down the virtual interface. [CSCdj43833]

A TN3270 client, which is mapped to a specific LU, fails upon reconnection. Although the first connection is successful, when the client disconnects and then tries to reconnect, the connection attempt will fail. [CSCdj48876]
The host XCA node goes down or an attached PU or LU goes into the INOP state after installing a CIP image.

: The workaround is to revert to a previous CIP microcode version or install the next release, which does not contain this problem. [CSCdj51725]

Caveats for Version 24.0/Version 24.1 Modifications

This section describes possible unexpected behavior by Version 24.0. All the caveats listed in this section are resolved in Version 24.1. See Table 10 for the Cisco IOS software release that corresponds to the 24.1 microcode version.

If a CIP TN3270 PU is configured to connect from the host to the CIP via NCP, the link may fail.

: The workaround is to configure the CIP TN3270 PUs as connecting at the host. [CSCdj07152]

When the CIP TN3270 servers only active DLUR links are configured from the host end and not from the CIP end, no attempt is made to find a network node server. [CSCdj18737]
CIP1 with 8 MB DRAM cannot be configured for 10 LLC sessions when using CSNA and cip22-19 microcode. The CIP will run if the max-llc2-sessions configured is 1. The CIP reloads continuously if the max-llc2-sessions is 10. [CSCdj19012]
When the CIP TN3270 Server disconnects a TN3270 client session, it sends out Telnet commands and an ASCII message describing its reason for the disconnect. The TCP session closes shortly after the message. Some clients do not like the Telnet command; others do not like TCP close coming after the data. The clients may behave unusually by giving an error message or locking up. These clients do not have the problem with servers that do not send Telnet commands and the ASCII message before the TCP closes. This message may cause the TN3270 client to freeze. If the TN3270 client freezes, reboot the operating system. This situation has not been reported with other TN3270 servers.

This malfunction could be caused by the following situations:

TN3270 clients do not follow the RFC, which allows network virtual terminal messages to be sent at disconnection time to inform the client of reason for disconnection
Client TCPIP stack reorders the data and finish packets causing an error on client

The workaround is to upgrade to a client TCPIP stack and application that conform to RFCs.

If clients disconnect from a CIP TN3270 Server in a short period of time, the server loses buffers and the PUs stay in the ACT/BUSY state. [CSCdj20423]
The commands that begin with show extended channel slot/port can fail to display all expected data because of a bug in the inter-process communications function used by Cisco IOS software to communicate with the CIP. [CSCdj21544]
LU-LU sessions are not preserved and the links are disconnected when an SSCP takeover or giveback occurs. [CSCdj22128]
A client can hang when a TN3270E client sends data before it sends a response. This error causes the data to be sent to the host before the response and causes the bracket state to be incorrect. This problem occurs using Personal COMMunication (PCOMM) 4.1 when the PA1 key on the TN3270 terminal is pressed while data is sent to the client. [CSCdj22926]
A CIP TN3270 Server PU stays in ACTIVE state after removing the internal adapter from the router configuration that the PU was using to connect to the host over the physical channel on the CIP. [CSCdj23224]
When the CIP is not channel attached, the CIP crashes with the following SSI_ASSERT message:

%CIP0-3-MSG:%SSI802-3-FATAL_ERROR: SSI_ASSERT failure in../ssi/ssi_buff.c @ 158 - (msg) && ((( msg)->m_flags & ( M_PK
%CIP0-3-MSG: THDR | M_EXT)) == ( M_PKTHDR | M_EXT))

: [CSCdj23424]

In a CIP TN3270 Server using TN3270E client, multiple chain messages do not use TN3270E responses when the first in chain has the Exception-response (EXR) flag set. The definite-response (DR) actually comes on last in the chain, but by that time it is too late.

: The workaround is to handle multiple chain messages as if they are definite responses from the host while generating TN3270E header. This workaround will ensure that the definite-response from the host can be used to guarantee an end-to-end response. [CSCdj24073]

The CIP TN3270 Server should stop listening on the relevant IP port if it cannot accept any more TN3270 or TN3270E connections. This action ensures that the device driver makes correct decisions. [CSCdj24385]
If a PU is remaining in the busy state, a new session may connect to the PU despite the availability of other PUs. The original connection will fail and there will be no warning message to indicate the connection failed.

: For the TN3270E client, there is no warning message if the host does not send a start data traffic (SDT) message. If a Telnet instead of a TN3270 client connects in the connection will fail, but an LU may be permanently assigned and not be reused again. If the host sends a DACTPU message, the statistics of the LU connections and disconnections may be wrong.
: Some hosts may send system services control points (SSCP) LU data before they send notify-response data. Also, a "no bind" warning message may be sent. [CSCdj24694]

The SNA session switch (DLUR) support in the CIP TN3270 Server is limited to 16384 concurrent sessions per CIP. Attempts to activate more LUs are rejected with sense code 0812 0007. [CSCdj24704]
The CIP crashes with a fatal error code 35 because the global queue of 4 KB buffers contains 0x00000100 instead of a valid address. The fatal error output contains the following line:

%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF BE810000 00000000 00000100  ...

: If the second double word on this line contains 00000000 00000100 it is likely that the crash was caused by this bug. [CSCdj25062]

During link inactivation, a message from downstream through a CIP TN3270 Server could cause the CIP to reload spontaneously. [CSCdj25255]
Following a channel error or host initial program load (IPL), the VTAM is unable to activate the XCA major node. The router log shows the following message at each attempted activation of the XCA major node:

Jul  4 00:10:28: %CIP25-6-MSG: %MSG802-6-LLC_DUP_SAP: LLC Duplicat SAP on interface 546 : SAP=4.

: Issuing the llc show all command on the CIP indicates that CSNA has failed to clear up one remaining session.

CIP-Slot5#llc show all
--- AdapNo 02, LanType Token     , SAP 04 ---
pcep=0860 rmac=4000.0000.7190 lmac=C000.0115.6500 rsap=04 lsap=04 this=8120EDA8
pcep=0860 state=ADM rbusy=no  lbusy=no  flow=on  pflag=1 dflag=0 v_r=0    v_s=0    last_nr=0    flag=60264282

: The workaround is to issue a microcode reload command to clear the hanging session. [CSCdj26081]

If the host sends SSCP LU data before a notify response and the client sends data before a notify response, the client is disconnected. This bug should happen only on a busy host with an application software sending data as soon as it receives data. [CSCdj27305]
If the host sends consecutive exceptional response frames, the TN3270 Server will send these frames before any responses come back from the RFC 1646 printer client. Some clients (for example, Attachmate Extra 4.3) may drop the data. [CSCdj28167]
The LUs are allocated from a PU so that no more LUs leave from the PU. If the PU become inoperative (INOP), then typically 255 sessions are lost. However, if the LUs are PUs evenly allocated, then fewer users are affected upon PU INOP. [CSCdj28852]
A CIP configured with CSNA and TN3270 Server may crash with the following message:

SSI_ASSERT failure in ../cta802/ccb802.c @ 3044 - LOOPBACK_FLOW_RECEIVED
Fatal error (code=09)

: [CSCdj29175]

When a DLUR link becomes inactive, the TN3270 Server reports the link outage with the wrong transmission group number. If the transmission group number is zero, then there is no problem. If the transmission group number is not zero, then DLUS may attempt to route dependent LU sessions over the link and the session setup will fail. [CSCdj29401]
When a DACTPU Giveback is sent to a TN3270 Server DLUR PU, no response is sent to the VTAM. After V INACT,ID=pu,TYPE=G, the PU is left in the state physical device address control point. [CSCdj29413]
The CIP crashes with a fatal error code 35 because the global queue of 4 KB buffers contains 0x00010001 instead of a valid address. The fatal error output contains the following line:

%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF 803F0010 00000000 00010001  ...

: If the second double word on this line contains 00000000 00010001 it is likely that the crash was caused by this bug. [CSCdj30387]

Each time a client connects and selects a static LU, the client is delayed for 3 seconds before the host connection is made. [CSCdj30652]
An extra end of job message (EOJ) may be sent to the printer after the last message, but before the client response. This may cause the printer drop the last messages.

: This bug is a regression caused by CSCdj28167. It occurs if the last message the host sends does not have end bracket (EB) bit on it. [CSCdj30937]

A CIP may crash with the following message after many errors are received over an ESCON Channel Adapter (ECA):

Jul 30 00:53:29: %CIP3-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta/cta.c @ 345 - FALSE
Jul 30 00:53:29: %CIP3-0-MSG: %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: [CSCdj30949]

Under rare circumstances (for example, during power outages or when a TN3270 client disconnects suddenly in middle of normal traffic) the CIP microcode may reload spontaneously with error 35.

: There is no guaranteed workaround other than to avoid random disconnection from the client in the middle of transactions. [CSCdj31131]

This fix corrects the CSNA problem of handling invalid channel blocks from host. [CSCdj31253]
Performing a no shutdown command on a CIP virtual interface where the llc2-max-connections command is greater than 5000, can result in excessive memory consumption. This problem exists in versions up to cip22-21.

: For example, the interface works well if it is brought up with 6000 sessions. However, when the interface is issued a shutdown command and no shutdown command, an additional 64 K 160-byte buffers is added to one of the channel transport adapter buffer pools, consuming about 10 MB of memory. This excessive memory consumption causes various problems depending on the size of the CIP memory. The size of the buffer pool can be corrected by issuing a microcode reload command. [CSCdj31884]

The show controller cbus command could indicate that the channel utilization is 100 percent busy, despite no device-level traffic. This situation most likely occurs with a Parallel Channel Adapter (PCA), and less likely with an ECA. Without this fix, any start subchannel connected to one of the devices should cause the utilization to start reporting correctly. [CSCdj32046]
This bug fixes and deprecates an unimplemented trap (cipCardLinkFailure) and implements a new trap (cipCardDtrBrdLinkFailure). Also, a new snmp-server enable traps channel-failures command was added to the parser. This command enables and disables the new trap (cipCardDtrBrdLinkFailure). [CSCdj32297]
A TN3270 Server, when operating with RFC1646-compliant printers, may send the wrong sense-code to the host when presented with a printer 'InterventionRequired' condition. The sensecode actually provided to VTAM is 0x1003000; correct operation might result in a sensecode of 0x08020000 or similar. [CSCdj36856]
The TN3270 Server may drop an unbind image from a job entry subsystem to a TN3270E client. The client (for example, a PC3270) may send a disconnect after receiving a bind image without receiving an unbind image. [CSCdj36868]
If VTAM is shut down while traffic is flowing, an external communication adapter (XCA) node may not start when the VTAM is restarted.

: The workaround is to issue the no csna command on the nonfunctioning subchannel, the no shutdown command on the physical interface, or the microcode reload command. [CSCdj38712]

When using a CIP TN3270 Server with the SNA session switch feature (DLUR), PUs that have a fully qualified name length of 17 characters cannot be activated. Activation fails with the SNA sensecode 0x10060000.

: The workaround is to use PU names that are less than eight characters. [CSCdj39358]

When hosts send a null response unit with begin chain (BC), the server will not send a TN3270E header to the printer client. The client then sends a disconnect to terminate the session. A typical host application is a job entry subsystem. [CSCdj39359]

Caveats for Version 23.2/Version 24.0 Modifications

This section describes possible unexpected behavior by Version 23.2. CIP Microcode Version 24.0 is the initial release for support under Cisco IOS Release 11.2(8)BC. All the caveats listed in this section are resolved in Version 24.0. See Table 10 for the Cisco IOS software release that corresponds to the 24.0 microcode version.

The Product Set ID (PSID) vector that is sent by CIP TN3270 Server in XIDs lacks a vendor ID. [CSCdi49621]
Reply PSID responses coming from the host do not show in the output of the show extended channel slot/port tn3270-server pu foo lu luLocaddr history command.

: A workaround is to examine the event log (located above the SNA traces). The event log shows whether the reply PSID response was received from the host. [CSCdi89304]

The CIP1 in the RSP crashes with an error 35 after loading the router. [CSCdj09542]
This fix addresses the CIP failure caused by the CIP LLC2 timer services malfunctioning. [CSCdj11140]
Issuing a shut or no shut command when using the Cisco IOS for S/390 TCP/IP stack and the Parallel Channel Adapter (PCA) can cause incorrect data transfer lengths and data corruption. [CSCdj13880]
If an inactive CIP TN3270 link is deleted with the no link command and is then added again, the CIP microcode may spontaneously reload. [CSCdj14956]
If the mainframe issues two close requests for the same socket, the second close request will cause an OFFL-4-BADDESC message to be displayed followed by a printout of the context necessary to troubleshoot the problem. This is a cosmetic bug caused by an unusual timing condition. This bug will not affect normal operations and does not indicate any session failures. [CSCdj15521]
The CIP may occasionally reload spontaneously with a traceback and the following error message:

%DEBUGGER-0-FATAL_ERROR: Fatal error (code=32)

: This failure has only been observed at sites running the CIP across an SRB network to a host (instead of the normal channel attachment). [CSCdj17365]

Configuration of CIP-CSNA appears to intermittently cause blocked virtual routes across VTAM-to-VTAM connections. [CSCdj17412]
If the mainframe offload code sends a socket request with a bad length field, the CIP may print an error message indicating that the length is bad. During the processing of this error message, the code can cause an alignment exception. The result is a fatal error with code 35. [CSCdj17843]
CIP1 with 8 MB DRAM cannot be configured for 10 LLC sessions when using CSNA and cip22-19 microcode. The CIP will run if the max-llc2-sessions configured is 1. The CIP reloads continuously if the max-llc2-sessions is 10. [CSCdj19012]
If a CIP TN3270 DLUR link is deleted with the no link command and is then added again, the link sticks in WAIT state. [CSCdj19069]
When the CIP TN3270 Server disconnects a TN3270 client session, it sends Telnet commands and an ASCII message describing its reason for the disconnect. The TCP session closes shortly after the message. Some clients will freeze or send an application error after these sequence of events.

This malfunction could be caused by the following:

TN3270 clients not following the RFC allow network virtual terminal (NVT) messages to be sent at disconnection time to inform the client of reason for disconnection.
Client TCPIP stack reorders the data and FIN (finish) packets causing an error on the client.

The workaround is to upgrade to a client TCPIP stack and application that conform to RFCs.

This error disables the capabilities of the Telnet option, which stops TN3270 mode (IAC DONT BINARY IAC WONT BINARY) and the NVT messages at disconnect time in CIPTN3270 server.

If a CIP TN3270 DLUR (SNA session switch) link fails or is taken down remotely, DLUR incorrectly reports that the link state is up. This can lead to session start attempts failing with sense 80140003.

: The workaround is to take down the DLUR-DLUS session. [CSCdj19817]

A TN3270 Server on a CIP with a PU goes into ACT/BSY state, which prevents new users from connecting and stops existing users sessions.

: This problem only affects customers using TN3270E.
: The buffers are lost only if BIND is followed immediately by unbind without SDT. This is small window of time, but some host applications might amplify it and should be avoided.
: To keep the PU from locking if the TN3270E and special host application are being used periodically reload the CIP microcode. Although PU re-activation is also a way to recover, it does not guarantee recovery. [CSCdj20210]

The CIP can spontaneously reload during operation if the host applications attempt to rebind immediately after a client disconnects. This problem did not exist in versions prior to cip22-20.

: A possible workaround is to ensure that the client always goes back to SSCP-LU after being in session, which means not using LOGAPPL or session-queuing. [CSCdj20596]

The CIP TN3270 Server records the rejection of received binds and the rejection of sent binds as the following message: "Rejecting rcvd Bind". [CSCdj20719]
The following error messages may appear when issuing a DACTPU or removing a PU:

May 27 18:26:37: %CIP1-1-MSG: %TN3270S-1-LU_ERROR: lu error lu not in hash
table: :36 pu:80A78998, tnet:0 May 27 18:26:37: %CIP1-1-MSG:
%TN3270S-1-LU_ERROR_INFO: LU info: Event 0 0 0 0 0 0 0 0 0 0 0 0 0 3 6 14 ,
state = A, snaState = 0, flag = May 27 18:26:37: %CIP1-1-MSG:  1

: This error message is caused by fixing CSCdj15559. These error messages should not hurt network operations. [CSCdj21011]

During the recovery of certain ESCON link errors, the CIP could crash with a fatal error after the ESCON adapter reports a device-level error when there is no active device. When this problem occurs, the fatal error is preceded by the following error message:

CCA-0-DEV_ERR2: Device error but no active defined device

: The workaround is to determine and resolve the reason for the ESCON link error. [CSCdj21031]

CIP Microcode Release cip22 Caveats and Modifications

The following sections describe the caveats to current CIP microcode versions and the modifications made in current CIP microcode versions for cip22 microcode. The caveats listed apply to only the most serious problems. See Table 10 for the Cisco IOS software releases supported by cip22 microcode.

Caveats for Version 22.43/Version 22.44 Modifications

This section describes possible unexpected behavior by Version 22.43. All the caveats listed in this section are resolved in Version 22.44. See Table 10 for the Cisco IOS software release that corresponds to the 22.44 microcode version.

An AS/400 TN3270 client negotiates a termtype of IBM-3486-BA with the CIP TN3270 server. IBM-3486-BA is an invalid 3270 termtype and will not handle 3270 data streams correctly.

: This fix adds IBM-3486-BA to the list of known invalid termtypes in the CIP TN3270 server. The CIP will send a WONT TERMTYPE message and allow the client to negotiate a valid termtype.
: There is no workaround. [CSCdr65906]

Caveats for Version 22.42/Version 22.43 Modifications

This section describes possible unexpected behavior by Version 22.42. All the caveats listed in this section are resolved in Version 22.43. See Table 10 for the Cisco IOS software release that corresponds to the 22.43 microcode version.

The TN3270 server show pu command output is missing LU states. The missing states are displayed as P-RESET. This applies also to the LU state objects in the TN3270 server MIB.

: There is no workaround. [CSCdp51038]

The CMCC adapter configured for CSNA may not respond to a test poll. This problem occurs because there is a miscount of the available IBM VTAM External Communications Adapter (XCA) resources. Typically an XCA autogen parameter is configured to automatically generate lines and PUs. This is not required for PU5-to-PU4 or PU5-to-PU5 communications.

: The workaround is to recycle the XCA major node. [CSCdr03103]

The CMCC adapter fails with the following fatal error message number 35:

%CTA-0-INACTIVE: PA1 CTA 7C00-50 reset after being inactive for 180 seconds

: The workaround is to shutdown the CSNA subchannel before shutting down VTAM. [CSCdr13804]

When using the TN3270 server monitor or a similar product such as SOLVE:Netmaster for TCP/IP, the length of the message fragment field is reported incorrectly. The field length is reported as "18". It should be reported as "20". The message fragment field is defined as follows:

  struct {short PACKED(pktLength); short PACKED(len); 
          unsigned char PACKED(bytes[16]);}

: This is a cosmetic failure and is present in all CIP and CPA microcode releases.
: There is no workaround. [CSCdr24412]

Caveats for Version 22.41/Version 22.42 Modifications

This section describes possible unexpected behavior by Version 22.41. All the caveats listed in this section are resolved in Version 22.42. See Table 10 for the Cisco IOS software release that corresponds to the 22.42 microcode version.

When an online insertion and removal (OIR) of an IP card is performed on a Cisco 7500 series router with a CIP, the CIP processor utilization reaches maximum capacity (99 to 100 percent). This occurs when any IP card besides the CIP is inserted and removed online. If there are two CIPs in the router, an OIR of one CIP can effect the other.

: The workaround is to not OIR IP cards in a Cisco 7500 series router when the CIP is running. [CSCdj90287]

The following message appears on the CMCC console:

: bad error-code 12 given
: This valid error code indicates a missing TERMSELF response. The code to log and format this specific error into a console message is missing.
: There is no workaround. [CSCdm55961]

A host receives an INOP 01 code message when a logical link control (LLC) session disconnects. This problem occurs when two VTAM systems are connected via an APPN network and an operation such as a normal disconnected mode (NDM) file transfer is processed. One end of the connection terminates the operation normally. The other end detects the LLC session disconnection and forwards a close_station_indication message with a code 7657 to VTAM. The code 7657 is translated as an abnormal disconnection sequence and causes VTAM to issue a IST1412I message with a return code 7657 and an INOP code 01.

: The CIP should send a normal LLC disconnection sequence indication with a code 7656 instead. This is illustrated in the following example:

Hosta--cip/csna-------dlsw------cip/csna----Hostb
  <----------------appn----------------------->

: There is no workaround. [CSCdp12204]

The CMCC adapter fails with error message number 32. This problem occurs when the TN3270 server is configured and is using, or has used, the TN3270 monitor or a similar product.

: The workaround is to not configure the TN3270 monitor or a similar product. [CSCdp16086]

The CMCC adapter fails with fatal error message number 32. This problem occurs when approximately 25 or more DLUR links are configured. The reply buffer is too small to contain all of the Cross Domain Init vectors and the positive locate reply.

: The workaround is to configure fewer DLUR links. [CSCdp79125]

The CMCC adapter may fail when the shutdown command is configured in TN3270 sub-mode.

: There is no workaround. [CSCdp99538]

Caveats for Version 22.40/Version 22.41 Modifications

This section describes possible unexpected behavior by Version 22.40. All the caveats listed in this section are resolved in Version 22.41. See Table 10 for the Cisco IOS software release that corresponds to the 22.41 microcode version.

A user receives another user's session when both users are logged into the same applications owning region (AOR) in the Customer Information Control System and that AOR is manually cancelled.

: The workaround is to not disconnect a client during the logon process; that is, after requesting an application from the SSCP screen, but before establishing the LU-LU session with that application. [CSCdm51110]

A print server with 10 LUs fails to get 10 TNET connections with the TN3270 Server. The tenth LU client receives a FIN message from the TN3270 Server. The TN3270 Server rejects the TNET message indicating Listen Closed on the PU. Additional attempts to connect to the tenth LU fail until the LU is reactivated or another LU is disconnected. The problem only occurs when the last ACTLU static LU is obtained by a client. It is standard practice for the TN3270 Server to close the listen vector at this time; however, it should not close any connections that are being negotiated and have obtained LUs.

: The workaround is to add an additional 3 LUs to the VTAM switched major node, leaving the print server to request only 10 TNET connections. [CSCdp43253]

BADTIMER messages appear when running TN3270 Server. In this case, the messages appear because a TN3270 session is being negotiated or recently has been negotiated. The messages do not impact normal TN3270 Server operations.

: There is no workaround. [CSCdk21633]

Caveats for Version 22.39/Version 22.40 Modifications

This section describes possible unexpected behavior by Version 22.39. All the caveats listed in this section are resolved in Version 22.40. See Table 10 for the Cisco IOS software release that corresponds to the 22.40 microcode version.

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The CMCC displays a RSP sense 089F0004 message when processing a REQACTPU message. The problem occurs when the VARY command is entered for DLUR PUs that have multiple PATH statements. The problem occurs because the DLUR sends a message to the DLUS containing an FQPCID value which DLUS created on an earlier acquisition of the PU. The host processes the FQPCID message as invalid.

: The workaround is to remove the PATH statements. [CSCdm42103]

The following message appears on the CMCC console:

: bad error-code 12 given
: This valid error code indicates a missing TERMSELF response. The code to log and format this specific error into a console message is missing.
: There is no workaround. [CSCdm55961]

The TN3270 server sends an LIC message to the DLUS on a +RSP. This message causes the DLUS to send an unbind message with sense data 400B0000 and to shut down the DLUR/DLUS pipe. The DLUR/DLUS pipe will re-establish and the user LU-LU sessions will not be affected.

This problem occurs when the TN3270 server DLUR component improperly saves RU chain bits from the original request to create a response message. This generates the +RSP sense data 400B0000.

The workaround is to increase the RU sizes on the DLUR/DLUS sessions. To increase the RU sizes on the DLUR/DLUS sessions, the user must do the following:

Create a new member called ISTINCLM in the customizable datasets ahead of SYS1.VTAMLIB in the concatenation sequence for DD name VTAMLIB.
Copy the ISTINCLM member from SYS1.SAMPLIB.
Change the RU sizes in member CPSVRMGR from 0x9797 to 0xC8C8 and assemble and link.
Issue the VTAM command FNET,TABLE,TYPE=MODETAB,OPTION=LOAD,NEWTAB=ISTINCLM
Restart the TN3270 server DLUR end node. [CSCdm70432]

The TN3270 IND$FILE file transfer performs poorly if the RU size is smaller than the maximum transmission unit (MTU). This problem occurs because the Cisco TN3270 Server uses the Nagle algorithm by default.

: The workaround is to set the RU size so that it is at least as big as the MTU on the file transfer path. [CSCdm86734]

CSNA devices fail with INOP messages during Interface Control Check (IFCC) status. This problem occurs when CLAW and CSNA are operating in high traffic conditions. It can occur in CMPC and CSNA, also.

: The workaround is to upgrade the CMCC microcode or to restart the external communication adapter (XCA) nodes. [CSCdm88239]

A CMCC file transfer hangs or the keyboard stops working. The problem occurs when the IND$FILE uses structured fields and buffers that are 2000 bytes or greater. The keyboard is restored using the TN3270 write command instead of the structured field.

: The workaround is to use buffers that are 2000 bytes or less or non-structured fields (presentation space transfer. To enable the fix in CMCC releases cip27-4 and greater and xcpa27-4 and greater, you must configure the TN3270 tn-parameter code codevalue command with a code value of 7. [CSCdm93990]

A BIND REQUEST or SSCP-LU message is expected but not received from the host within 30 seconds from the start of an SSCP-LU session for the CMCC Adapter TN3270 server session. If the condition continues for another 2 minutes, the LU is declared bad and the following error message appears:

%TN3270S-1-NO_BIND_REQ_RCVD: No BIND REQ received on LU [chars].[dec], 120*ONESEC

: This error and several others are logged as priority 1 (alert) messages in error reports. The priority level of the following error messages is now priority level 3:

NO_PSID_RSP_RCVD
NO_NTFY_AV_RSP_RCVD
NO_BIND_REQ_RCVD
NO_SDT_REQ_RCVD
NO_SDT_TMARK_RCVD
NO_UNBIND_TMARK_RCVD
NO_NTFY_UA_RSP_RCVD
NO_DYN_ACTLU_REQ_RCVD
NO_UNBIND_RSP_RCVD 
NO_TERMSELF_RSP_RCVD

: [CSCdm94788]

The CMCC adapter fails with the following message:

%CIP2-3-MSG: slot0 %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta802/ciptask.c @ 322 - !mxcb->mx_next
%CIP2-0-MSG: slot0 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: The assertion is intended to detect messages with 15 or more memory buffers (mbufs). There is no workaround. [CSCdp13245]

The CMCC adapter with TN3270 Server configured fails with fatal error message 35. This problem occurs when attempting to clear the TN3270 configuration from the router. After entering the no tn3270-server command while in configuration mode on the virtual channel interface, the microcode reloads and all the interfaces flap. The CSNA devices are removed from the running configuration and must be reconfigured.

: There is no workaround. [CSCdp24670]

The CMCC Adapter fails when running CSNA. This problem occurs while processing the detection of idle subchannel conditions.

: The workaround is to avoid creating idle subchannel conditions by not using the Z NET cancel command. Other possible workarounds include shutting down the router channel interface or removing the CSNA configuration statement before issuing the Z NET cancel command. [CSCdp31175]

Caveats for Version 22.38/Version 22.39 Modifications

This section describes possible unexpected behavior by Version 22.38. All the caveats listed in this section are resolved in Version 22.39. See Table 10 for the Cisco IOS software release that corresponds to the 22.39 microcode version.

The AS/400 TN client attempts to establish an IBM-3180-2 terminal-type session with a TN5250 terminal. If a session is not available, the AS/400 TN client automatically switches to the TN3270 with a 3270 terminal type. The AS/400 TN client receives an ACK message from the 3180 terminal type when expecting a 5250 datastream. Instead, the TN3270 server sends it a 3270 datastream. Because the CMCC TN3270 Server accepts the IBM-3180-2 terminal-type the client does not switch to TN3270. [CSCdk37980]
MSG10 data from one LU might be seen on an LU already in session. This problem occurs when the TN3270 server remote MAC address resides on a different physical adapter or in a different physical machine, such as a front-end processor (FEP).

: The workaround is to make sure that the RMAC TN3270 server PU resides on the same CMCC adapter as the TN3270 Server. [CSCdm01837]

If a CIP2 PCA (Bus and Tag) has an Altera FLEX chip (the large chip on the PCA daughter card) with a date code of 9601 or greater, the CIP will fail with parity errors shortly after the card is first installed. The date code on the PCA can be found only by looking for a code on the edge of the chip or the top heat sink area.

: The workaround is to upgrade to the recommended CIP microcode version which corresponds to your Cisco IOS software. [CSCdm28629]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

A user receives another user's session when both users are logged into the same applications owning region (AOR) in the Customer Information Control System and that AOR is manually cancelled.

: The workaround is to not disconnect a client during the logon process; that is, after requesting an application from the SSCP screen, but before establishing the LU-LU session with that application. [CSCdm51110]

Every other CIP TN3270 Server client connection fails. This problem occurs when clients are trying to connect at a slow rate and the TN3270 Server is operating with a light traffic load.

: There is no workaround. [CSCdm55234]

The CMCC adapter fails with fatal error code 35 during the TN3270 Server shutdown. This problem occurs because the TN3270 Server PUs are not communicating with the host.

: A workaround is available. Contact the Cisco TN3270 Server development engineers for the interim fix. [CSCdm61159]

The TN3270 Server response time to the clients is slow (2 to 90 seconds). This problem occurs only if the clients are on a Token Ring or FDDI network and the server is on an Ethernet network. The problem occurs when there is a moderate to heavy load on the network.

: The problem occurs because the client network maximum segment size (MSS) is set to 4000 and the server network MSS is set to 1500. The CMCC TCP stack attempts to increase the maximum transmission unit (MTU) from 1500 to 4000 every 10 minutes for each TCP connection. The Cisco IOS software sends only one or two ICMP messages per second, therefore some TCP packets are dropped and must be retransmitted. The retransmission intervals increase exponentially and these intervals appear to the user as a delay in response time.
: To enable this fix in microcode version cip22-39 and later, you must configure the TN3270 server keepalive seconds command with a value of 14444. To enable this fix in microcode version cip27-3, xcpa27-3 and later, you must configure the TN3270 server tn-parameter code codevalue value minutes command with a code value of 5. Value is the number of minutes between path MTU discovery retries. The default is 10 minutes. A value of 0 implies an infinite timer value.
: There is no workaround for other microcode versions. [CSCdm61803]

The TN3270 Server running DLUR/DLUS fails with fatal error message code 35. This problem occurs because the TN3270 Server tries to invoke a SendACTLURSP using a NULL object reference.

: This fix adds a debug message to the log and marks the ACTLU as not processed.
: There is no workaround. [CSCdm69186]

The DLUR pipe between VTAM and the CMCC adapter hangs. This problem occurs when a large number of TN3270 Server TCP/IP requests (1000 per CMCC Adapter) arrive at the same time.

: The workaround is to space out the TCP/IP requests. [CSCdm75120]

The TN3270 Server fails with the following error message:

%DEBUGGER-0-FATAL_ERROR: Fatal error (code=35)

: This error occurs when the TN3270 Server is shut down while traffic is still transmitting. [CSCdm78261]

The unbind/bind sequence in the response time logic during a transaction does not reset the sample. This error causes an invalid response time which might be extremely large, depending upon the timing of the transaction. This problem occurs when the unbind keep is configured when the next transaction completes.

: There is no workaround. [CSCdm82521]

Caveats for Version 22.37/Version 22.38 Modifications

This section describes possible unexpected behavior by Version 22.37. All the caveats listed in this section are resolved in Version 22.38. See Table 10 for the Cisco IOS software release that corresponds to the 22.38 microcode version.

The TN3270 Server session fails with the following error message:

INOP STATUS

: The workaround is to reactivate the external communication adapter (XCA) major node. [CSCdk36329]

An error occurs when using the TN3270 Server to establish a connection to an application residing on a Migration Data Host (MDH) using a virtual routing node connection network.

: If a prior connection to the MDH from the server does not exist, it might take several attempts to make a connection. Once the initial connection is made, all subsequent connections will work.

Note IBM VTAM has opened an APAR for the 8002 sense portion of this problem. Users must get the APAR PTF from IBM to get MDH to work with the virtual routing node on the CMCC.

: [CSCdk37107]

Sometimes TN3270 client disconnections are counted twice. This miscount results in an incorrect TN3270 active session count. The dynamic LU count for that PU becomes one less than the actual number. This is not a problem until the actual count reaches zero and the dynamic LU count cycles to 255. When this miscount occurs, if you enter the show extended ch4/2 tn command, (which shows how many LUs are in use) the result is inflated by 255.

: The workaround is to shut down and restart the PU or to cycle the PU in VTAM. [CSCdk57112]

The TN3270 Server session disconnects after 150 seconds when the LOGON APPLID is not entered. In this case, there is no unformatted system services table (USSTAB).

: There is no workaround. [CSCdk83774]

A query on the snaLuOperSnaName field in the SNA-NAU MIB returns an unexpected value. The MIB query returns the administrative name instead of the SNA name. This problem occurs if a direct PU, not a DLUR, has an LUSEED defined. Direct PUs do not support DDDLU. Also, this problem occurs when the INCLUD0E = YES field is not specified on the switched major node (SWM).

: The workaround is to use DLUR or DDDLU, or to specify the INCLUD0E = YES field on the SWM. [CSCdm13637]

The CIP configured for CSNA crashes with the following error message:

: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ./cta802/dlu.c Fatal error (09).
: [CSCdm22660]

CIP response times and utilization increase when a large number of TN3270 Server connection attempts are made to the same source IP address. A large number of TCP no-op (NOP) messages are sent by the TN3270 Server to the clients.

: The fix limits the number of NOP messages sent to the clients. No configuration is required to enable the fix.
: There is no workaround. [CSCdm23252]

If a CIP2 PCA (Bus and Tag) has an Altera FLEX chip (the large chip on the PCA daughter card) with a date code of 9601 or greater, the CIP will fail with parity errors shortly after the card is first installed. The date code on the PCA can be found only by looking for a code on the edge of the chip or the top heat sink area.

: The workaround is to upgrade to the recommended CIP microcode version which corresponds to your Cisco IOS software. [CSCdm28629]

In a duplicate MAC environment, the CIP will continue to respond to a TEST command when the lines configured for the XCA are in use. This problem prevents other duplicate MAC adapters from responding to new requests.

: The workaround is to configure the maximum LLC or threshold to equal the number of XCA lines configured. [CSCdm29597]

The TN3270 Server session disconnects and brings up the Sign On menu. This problem occurs when a user has entered an AID command that it is queued in the server and then is scrolling through the session window. The server sends the AID to the host before receiving the end bracket specifying the direction.

The following trace scenario illustrates the problem:

The BID command is received from the host:

: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=10,2C003601 00AE4B81 00C8
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8501,lu-flags=0D24D204
: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=10,2C000136 00AECB81 00C8

An AID command is received before the host has a chance to send the BB command. Since the BID command was already received the server queues the AID frame:

: *Apr 26 13:36:24: %CIP: slot0 In Tnet 212: len=13,00000100 42F7D7F5 11D7F5FF EF
: *Apr 26 13:36:24: slot0 Out Lu 5.54: sna-state=8D01,lu-flags=0D24D204

The host sends the next write with the BB/keyboard restored (note that there is no EB command):

: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=1484,2C003601 00AF0381 80F10611 5D611DE8
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8D01,lu-flags=0D24D204
: *Apr 26 13:36:24: %CIP: slot0 Out Tnet 212: len=1482,00000200 6C010411 5D611DE8 40404040

The client sends the response to the frame:

: *Apr 26 13:36:24: %CIP: slot0 In Tnet 212: len=8,02000000 6C00FFEF
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: sna-state=8509,lu-flags=0B24D204
: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=9,2C000136 00AF8381 00

The BUG-inbound queued data was sent inbound before the EB command was received from the host:

: *Apr 26 13:36:24: %CIP: slot0 In Lu 5.54: len=15,2C000136 00200392 20F7D7F5 11D7F5
: *Apr 26 13:36:24: %CIP: slot0 Out Lu 5.54: len=9,2C003601 00B00391 40

There is no workaround. [CSCdm31347]

The TN3270 Server fails intermittently during the shutdown procedure. This failure occurs when the shutdown procedure is performed and TN3270 Server sessions are receiving client data. TheTN3270 Server shutdown procedure sequence shuts down the TCP/IP stack prematurely. The failure is intermittent depending upon the timing between receiving data from the client and the shutdown sequence.

: This problem occurs in CMCC microcode releases cip22-35, cip24-10, cip25-10, cip26-5, xcpa 26-5, cip27-0, xcpa27-0, and later.
: The workaround is to perform the shutdown procedure when there is no activity on the TN3270 sessions. [CSCdm35562]

The CIP running TN3270 Server receives DSI562I error messages on the NetView console. The messages indicate that in the activate physical unit (ACTPU) control vector 80, unsolicited network management vector transport (NMVT) request units are not allowed. The CIP TN3270 Server still sends product-set identification (PSID) NMVT messages for VTAM PUs with only LUs.

: There is no workaround.
: To enable the fix in the cip24-13 microcode, the maximum-lu command must be added to the TN3270 Server configuration file. [CSCdm36152]

The CIP VTAM session hangs at the VTAM message10 menu. This problem occurs when the user is at the VTAM message10 menu and hits multiple blank Enter keys and when the inbound request unit on the SSCP-LU session is 256 bytes or greater.

: There is no workaround. [CSCdm37663]

Caveats for Version 22.36/Version 22.37 Modifications

This section describes possible unexpected behavior by Version 22.36. All the caveats listed in this section are resolved in Version 22.37. See Table 10 for the Cisco IOS software release that corresponds to the 22.37 microcode version.

If a CIP2 PCA (Bus and Tag) has an Altera FLEX chip (the large chip on the PCA daughter card) with a date code of 9601 or greater, the CIP will fail with parity errors shortly after the card is first installed. The date code on the PCA can be found only by looking for a code on the edge of the chip or the top heat sink area.

: The workaround is to upgrade to the recommended CIP microcode version which corresponds to your Cisco IOS software. [CSCdm28629]

Caveats for Version 22.35/Version 22.36 Modifications

This section describes possible unexpected behavior by Version 22.35. All the caveats listed in this section are resolved in Version 22.36. See Table 10 for the Cisco IOS software release that corresponds to the 22.36 microcode version.

If a user disconnects without properly logging off the mainframe, a new user can connect to those existing sessions. This problem occurs when accessing Customer Information Control System (CICS) applications through the TN3270 Server. [CSCdk48736]
Inconsistent keepalives occur when multiple TN3270 sessions are configured to the same server. When the sessions are idle for an hour or more, keepalives are not sent even though the keepalive value is set to 300 (5 minutes).

: The workaround is to restart the session. [CSCdk57453]

Dynamic LUs remain in a P-NFT/UA state when the TN3270 Server is configured. The LUs cannot be used again when in this state.

: The workaround is to deactivate the LU or the owning PU in VTAM. [CSCdk60263]

The TN3270 session between the client and TN3270 server is disconnected when the client issues the logoff command at the VTAM MSG10 screen. [CSCdk80609]
The TN3270 Server session disconnects after 150 seconds when the LOGON APPLID is not entered. In this case, there is no unformatted system services table (USSTAB).

: There is no workaround. [CSCdk83774]

Adding and removing PUs configured in TN3270 DLUR causes the CIP to reload with fatal error message 32. This failure occurs when a shutdown command is issued during high traffic periods on the server. The following messages appear immediately before the error:

: %CIP2-1-MSG: slot1 %TN3270S-1-RP_PU_CONFLICT:RP & CIP hold conflicting PU name(xxxxxxxx) or index(92)
: Where "xxxxxxxx" is the PU name.
: %CBUS-3-CIPCFGFAIL: Channel1/2: configuration command TN3270S_DLUR_PU_NEW cmd 18 failed
: %CIP2-0-MSG: slot1 %DEBUGGER-0-FATAL_ERROR: Fatal error (code=32)
: The workaround is to perform the shutdown when the server load is light. [CSCdk83807]

When the TN3270 server is configured, entering the SYSREQ key followed by the logoff command does not return the user to the queued session. Instead, the VTAM MSG1 warning is displayed.

Other SYSREQ key errors that occur when the TN3270 server is configured include:

Pressing the SYSREQ key twice does not return the user to the LU-LU session. An LUSTAT is sent inbound on the second SYSREQ key entry.
Entering the logoff command incorrectly locks the session. SSCP-LU does not recognize the change direction in a sense data frame. This problem might occur in other remote cases.
LU-LU data shows up on an SSCP-LU session.
When responding to DACTLU in LU-LU or bound states, an inbound unbind should be sent. This inbound unbind was not working, but it was not evident because the client is normally disconnected which causes a SESSEND.

The workaround is to not use the SYSREQ key. [CSCdk83960]

The CIP running TN3270 fails with fatal error number 35 when a shut command is issued to the TN3270 server. This problem occurs when the shut command is issued and the TN3270 Server is operating at high capacity.

: The workaround is to issue the shut command only after the client traffic terminates. [CSCdk87658]

CMCC devices with Bus and Tag connections do not activate properly when connected to an Amdahl 857 running the UTS operating system.

: There is no workaround. [CSCdk91964]

For extended periods of time, the write device for a CLAW connection experiences the same number of command retries and connects. Data throughput decreases significantly during these periods, but the connection is not lost. The connections and the command retries are displayed with the show extended channel slot/port command. This situation occurs when the channel operates at 95 percent or greater capacity for many hours.

: A workaround is to distribute the traffic to multiple boxes to avoid a channel capacity of 95 percent or greater. [CSCdk92004]

If IP fragments that are 21 to 23 bytes long are sent to the CLAW of an OFFLOAD connection to a mainframe the packet is dropped and the following error message is sent:

: CLAW-6-TOOSMALL: xx byte IP datagram is to small, device x/yyyy/zz
: The workaround is to modify the network so that IP fragments do not occur. [CSCdm11522]

Caveats for Version 22.34/Version 22.35 Modifications

This section describes possible unexpected behavior by Version 22.34. All the caveats listed in this section are resolved in Version 22.35. See Table 10 for the Cisco IOS software release that corresponds to the 22.35 microcode version.

The TCP connection is closed (a FIN sent) before all data is sent. The remaining data (1 to 12 bytes) is sent after the connection is closed with another FIN. This problem occurs only with TCP connections that include TCP options in the TCP header and if the remaining data to be sent on the connection will fill up the packet before taking into account the length of the TCP options (12 bytes). This problem occurs when using the TCP large window support, which utilizes the TCP Timestamp option, implemented per RFC 1323.

: The workaround is to complete the following tasks:

Step 1 Log into the CMCC console:

if-con <CCMCC Slot> c

Step 2 Display the current state of this RFC:

ipconf <Offload IP Address> tcp_rfc1323

Step 3 Disable this RFC:

ipconf <Offload IP Address> tcp_rfc1323 off

Step 4 Verify the configuration change using Step 2. This RFC can be re-enabled, if necessary, using the same command but with the "on" option.

ipconf <Offload IP Address> tcp_rfc1323 on

Step 5 Exit the CMCC console:

quit (CIP21-x/CIP204-x releases)
if-quit or ^C^C^C (CIP22-x/CIP205-x and all later releases or XCPA26-x/XCPA214-x and all later releases)

: Unlike configuration commands issued from the router console, this CMCC configuration command is not retained if the CMCC or the router reloads or crashes and reloads. [CSCdk57139]

When running the CMCC TN3270 Server, LU 1 print jobs hang if the print application sends the RU chains as EXR (exception response) and the connection is running over a RFC1646-style TN3270 print connection.

: The workaround is to print the job using LU 3 printing or to reconfigure the print application to send the SNA RU chains with DR (definite response) requested. [CSCdk59063]

Caveats for Version 22.32/Version 22.34 Modifications

This section describes possible unexpected behavior by Version 22.32. All the caveats listed in this section are resolved in Version 22.34. See Table 10 for the Cisco IOS software release that corresponds to the 22.34 microcode version.

The CMCC crashes with fatal error code 37 after the BSQ-0-SCB_CHAIN: Read SCB chain is out of sequence. If the routing processor sends an IP packet to the CMCC for a CLAW-type device and that IP packet header indicates a 0 byte packet, the CMCC incorrectly tries to send a 0 byte message to the host and eventually causes a FATAL_ERROR on the CMCC.

: There is no workaround. [CSCdk41469]

The CMCC adapter crashes with a fatal error code 35 when reconfiguring an offload statement using the same IP address that was used in a previously configured offload connection. This error occurs if the CMCC adapter has not completed deconfiguration cleanup of the previous offload statement before the new offload statement is configured using the same IP address. For example, the current configuration is as follows:

: offload e200 50 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: Reconfigure the offload statement as follows:
: no offload e200 50 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: offload e100 52 80.11.198.2 ciscovm rispix tcpip tcpip tcpip api
: To workaround, after deconfiguring the offload statement, exit the configuration and issue the show extended channel slot/port ip-stack ip address command. When the offload deconfiguration is complete for the indicated offload statement IP address, the output should indicate "...No IP statistics found". At this point the new offload statement using the same IP address can be configured.
: The following is an example configuration:
: rispix#show ext ch 0/1 ip-stack
: IP Statistics for IP Address 80.11.198.2
: Forwarding : no DefaultTTL : 64 InReceives : 0
: InHdrErrors : 0 InAddrErrors : 0 ForwDatagrams: 0
: InUnknownProtos: 0 InDiscards : 0 InDelivers : 0
: OutRequests : 0 OutDiscards : 0 OutNoRoutes : 0
: ReasmTimeout : 60 ReasmReqds : 0 ReasmOKs : 0
: ReasmFails : 0 FragOKs : 0 FragFails : 0
: FragCreates : 0 RoutingDiscards: 0

: rispix#config t
: Enter configuration commands, one per line. End with CNTL/Z.
: rispix(config)#in ch 0/1
: rispix(config-if)#no offload e200 50
: rispix(config-if)#end
: rispix#
: 01:22:25: %SYS-5-CONFIG_I: Configured from console by console
: rispix#show ext ch 0/1 ip-stack
: ...No IP statistics found

: [CSCdk45042]

When running CMCC cip22-31 microcode with CSNA configured and DLSW running, cip22-31 will send UI frames to the Cisco IOS software causing a router crash. This error happens if an APPN session over CSNA from VTAM to a downstream PU sets up an HPR session. This error will only occur in an HPR environment. This problem will not occur if the downstream PU does not have HPR configured. HPR is available over CSNA in cip22-31 for the first time.

: The workaround is to configure the downstream APPN node to not allow HPR sessions from the CSNA device. [CSCdk72962]

Caveats for Version 22.31/Version 22.32 Modifications

This section describes possible unexpected behavior by Version 22.31. All the caveats listed in this section are resolved in Version 22.32. See Table 10 for the Cisco IOS software release that corresponds to the 22.32 microcode version.

When running the CMCC Offload feature, the WRONGDESC error message was displayed if the host application issues a socket purge request using the host descriptor instead of the offload box socket descriptor. Socket purge requests are normally issued by VM/MVS/TPF TCP/IP applications when closing a socket.

: The message is misleading because the host application must sometimes use the host descriptor if it has not been notified of the offload box socket descriptor. This occurs when an error is detected during socket connection establishment. The WRONGDESC error message has been removed. [CSCdj92653]

When using TN3270 Server to connect to NetView when the NetView type ahead feature is used the LU-LU session can be stuck with a PROG MSG. Customer needs to recycle LU to continue.

: The workaround is to recycle the LU in VTAM and restart the session.[CSCdk11361]

CMCC TN3270 Server's DLUR session is unbound by DLUS with sense 1002 (RU length error) soon after the DLUR-DLUS pipe is established. This occurs when 10 or more LLC links connected to DLUR generate a topology database update (TDU) to DLUS that exceeds the maximum RU size specified in the Bind. The CP-CP session can fail with the same sense code for the same reason. In this case, the RU that exceeds the maximum RU size is the one specified in the locate which DLUR sends to find the DLUS.

: The workaround is to reduce the number of LLC links available to DLUR until the DLUR-DLUS pipe is established. [CSCdk11790]

BADTIMER messages appear when running TN3270 Server. In this case, the messages appear because a TN3270 session is being negotiated or recently has been negotiated. The messages do not impact normal TN3270 Server operations.

: There is no workaround. [CSCdk21633]

A print job hangs when printing through the CMCC TN3270 Server. The Host application sends an exception response on the end bracket chain followed by a CHASE.

: There is no workaround. [CSCdk27199]

When using a logon manager through CMCC TN3270 DLUR, the logon manager queues a session for the SLU to recover the session after the user has finished an application. VTAM sends UNBIND 02 (bind forthcoming). The CMCC TN3270 Server LU sends an UNBIND +RSP and the DLUR sends SESSEND with code 0A (SSCP gone). This forces SSCP to clean up the queued session from the logon manager. The expected PREALC-P session from the logon manager no longer exists. Using CMCC TN3270 Server DLUR EN capability, connect to a logon manager such as NetView access or TPX. [CSCdk29362]

Caveats for Version 22.30/Version 22.31 Modifications

This section describes possible unexpected behavior by Version 22.30. All the caveats listed in this section are resolved in Version 22.31. See Table 10 for the Cisco IOS software release that corresponds to the 22.31 microcode version.

When running CMCC TN3270 Server, the CMCC adapter reports fatal error code 35 and reloads. This error occurs when the CMCC adapter is running low on memory and a packet arrives that is larger than the SNA inbound request/response unit (RU) size. Typically, this error occurs when the router is running transports such as FDDI between the CMCC adapter and the client.

: The workaround is to increase the inbound RU size defined in the host logmode tables. [CSCdj76007]

Repeated inact/act of the XCA major node or the switched major node causes the TN3270 PUs to become stuck in a RESET/XID cycle.

: The workaround is to shut and then no shut the TN3270 Server. [CSCdk03985]

The CMCC TN3270 Server connects then disconnects a client. This occurs with LOGAPPL applications when the client sends data to the host application and the host's response to Notify reaches the server after the bind.

: The workaround is to reconnect. [CSCdk06887]

A connection can be terminated if the flowoff condition is reached. [CSCdk07022]
During bulk transfer operations that move data to the host, throughput to the host is limited by overhead on the channel causing channel utilization to approach 100 percent. Use the show controller cbus command to determine the ECA utilization. The ECA statistic is updated once a minute.

: There is no workaround. [CSCdk08438]

The CMCC microcode reports a fatal error and reloads. This is an infrequent problem that occurs when there is a very small timing window. [CSCdk08533]
When running CMCC TN3270 Server, the server disconnects the client when the host sent dactlu followed by actlu. In VTAM through cross domain, the host can send dactlu followed by actlu to clean up the lu session, but not to disconnect the lu session. [CSCdk08642]
When the connection to a host from the CMCC TN3270 Server is not via the channel, data corruption may occur, resulting in bad XIDs or Binds being reported.

: There is no workaround. [CSCdk10071]

TN3270 user cannot log on because the keyboard is locked. The keyboard can lock if a TN3270 user presses an invalid AID key (such as PF or PA) before logging on to a host application. This does not occur with TN3270 clients or LOGAPPL'd LUs.

: The workaround is to locally clear the keyboard lock, if the client supports such a feature. Otherwise, the user must disconnect and reconnect. [CSCdk10200]

The TN3270 Server refuses new TCP connections. This lasts for 2 to 20 minutes depending on the number of TCP requests. This occurs when there is one-way network congestion between one or more clients and the server. The congestion direction must be from the server to the client. The congestion causes the client not to see the SYN/ACK coming from the server and the client resends the SYN.

: There is no workaround. [CSCdk11113]

The CMCC adapter reports the IPC-NO-MEMD message and hangs. This occurs when CMCC adapter host communications have been cut off before a hierarchical reset. [CSCdk11787]
The TN3270 Server crashes with fatal error code 35. See caveat CSCdk02535. [CSCdk11968]
The CMCC microcode reports a fatal error and reloads. This occurs when unconnected PUs attempt to send XIDs and TEST frames to the host. The PU timer expires and corrupts the TN3270 Server timer-queue. This occurs either when the PU disconnects or when a NULL XID is about to be sent to the host.

: The workaround is to ensure that all PUs are either shutdown or connected. [CSCdk09978]

Caveats for Version 22.28/Version 22.30 Modifications

This section describes possible unexpected behavior by Version 22.28. All the caveats listed in this section are resolved in Version 22.30. See Table 10 for the Cisco IOS software release that corresponds to the 22.30 microcode version.

The CMCC adapter reports fatal error code 35 when running TN3270. Before the fatal error, the CMCC adapter reports the following error message:

%CIP24-4-MSG: %TN3270S-4-NO_LU_SESSIONS: No LU sessions left for PUs at IP addr a.b.c.d, port x

: The problem may occur when the maximum-lu limit has been reached or when no more LUs are available at a given TN3270 Server listening point.
: The workaround is to increase the maximum-lu limit to a level that will not be reached during operation of the server. Also, the user should increase the number of PUs (really LUs) on each listening point. [CSCdj80602]

With Offload, a socket can be closed in a way that the control block lingers for 60 seconds. If an attempt is made to re-establish the same connection before the 60 second period has expired, connection failure may occur. [CSCdj80952]
Additional information was added to the CMCC fatal error output report.This will help identify the events leading up to the failure. [CSCdj85568]
The CMCC DLUR repeatedly tries to establish CP-CP sessions with an incompatible NN server and fails to try other links for a NN server in the following conditions:
- When using CMCC TN3270 Server DLUR/DLUS with preferred-NNserver configured, when the DLUR is varied inactive by lu/cpname on the primary host and is defined statically on the primary, as cross-domain resource (CDRSC) or LU, but the link between the primary and the CMCC adapter is left active. This situation makes controlled SSCP takeover difficult.

: The workaround is to not configure preferred-NNserver. [CSCdj87854]

When running fast mainframe processors in offload mode, 10-20 percent of the channel bandwidth can be wasted by improperly handling the more-to-come processing within the CLAW protocol.

: There is no workaround. [CSCdj88636]

If a DMA write error occurs on the CIP in the process of sending a packet to the Cisco IOS software, the CIP could go into an infinite loop when the CIP interface the DMA error occurred on is shut down or the router performs a cbus complex restart. [CSCdj90280]
At show ext cn/2 pu/lu, some dddlu LU names appear blank if Host applications send NULL slu data in the bind.

: There is no workaround. [CSCdj90734]

Sometimes outbound data is randomly corrupted. This situation occurs with CMCC images in Cisco IOS Release 11.2(BC) if the TN3270 PUs are attached to VTAM by Token Ring (rather than channel attached) and some clients are running 3270 extended datastream. The problem usually occurs after file transfer of binary data.

: There is no workaround. [CSCdj90738]

A reset of the CIP virtual interface configured with LLC2 can cause MEMD buffer errors resulting in a cbus complex restart. [CSCdj90822]
The CMCC TN3270 Server command show extended ch x/2 tn3270 pu lu history may cause the router to reload. This situation happens if the LU's history buffer contains an event indicating that it received data from the client after it sent unbind to the client.

: The workaround is to not use the show lu history command. [CSCdj91756]

When the maximum-lu is reached, clients cannot connect for a few minutes. Usually only one listening point is affected.

: The workaround is to increase the maximum-lu in the configuration so that the maximum-lu will not be reached. [CSCdj92158]

The CMCC adapter fails because of corruption in SNA-related code. Very small timing windows, which occur in unreliable or high latency networks, can cause this failure. These networks create many asynchronous balanced mode extended (SABMEs), which can trigger this bug.

: The workaround is to tune the LLC timers to reflect true delays in the network. [CSCdk02032]

CMCC adapter crashes with fatal error 35. The CMCC adapter reports the following message:

bad LU on DISC...


: This error is caused by CSCdj81522. The crash may occur if a TN3270E client connects and does not negotiate bind-image.
: The workaround is to ensure that all clients support bind-image. [CSCdk02535]

Caveats for Version 22.27/Version 22.28 Modifications

This section describes possible unexpected behavior by Version 22.27. All the caveats listed in this section are resolved in Version 22.28. See Table 10 for the Cisco IOS software release that corresponds to the 22.28 microcode version.

If the channel transport adapter device registers after the LLC2, the LLC2 informs the channel transport adapter of the connection count. [CSCdj32856]
The CMCC Adapter reports a BSQ-x-SCB_CHAIN error message indicating that the read SCB chain is out of sequence. The problem is caused by unusual conditions during status presentation such as ESCON link errors. There is no workaround. [CSCdj61319]
The CMCC TCP/IP stack uses path MTU discovery (RFC 1191) to select the size of an outgoing IP packet. The algorithm used does not work if the IP layer adds IP options to the packet. If this situation occurs, TCP connections will hang and eventually timeout as soon as they try to send a segment larger than the smallest MTU in the path. Of all the problems that could lead to dropped TCP connections because of path MTU discovery, this is probably the least likely to occur. It is much more common that the problem is caused by an improperly designed network (for instance, a configuration with a bridge connecting two networks with different MTUs) or a misconfigured router that does not send an ICMP type "Destination unreachable" with code "Fragmentation needed but DF bit set".

show extended channel slot/port ip-stack
show extended channel slot/port icmp-stack
show extended channel slot/port tcp-stack
show ip traffic

[CSCdj65774]

On a Cisco 7000 router with a CIP, if all interfaces on the CIP are shut down when the CIP is loaded then the interprocess communication (IPC) subfacility will not work on the CIP even after no shut commands are issued for the interfaces. [CSCdj74844]
CMCC TN3270 sessions can linger for up to 10 minutes after the PU that the sessions ran through is shut down. This situation causes subsequent activations of the XCA major node to fail at the host because the CMCC adapter/SAP is not ready to open.

: A workaround is to issue a shut and then a no shut command on the TN3270 Server, causing the connections to be brought down quickly. [CSCdj76280]

Following a reload, microcode reload, or after a no shutdown command is issued, IBM's MVS TCPIP could complain about channel status of x'06'. This problem occurs following a resetting event condition where MVS IOS expected to have cleared the resetting event condition prior to the event actually occurring. The recovery mechanism that is already in place should recover from this error. If the channel interface is always shut down prior to a reload or microcode reload and this fix is applied, the host should stop complaining about the channel status of x'06'. [CSCdj78947]
The CMCC Adapter reloads spontaneously after the following error message:

%CTA-0-UNEXP_LSI_CMD: PA1 CTA C020-56 received LSI command 0x4D11 at 0x8042CA8C

: An unrecognized command code was recognized during communication between the LLC2 and CSNA components on the CMCC Adapter. This problem has never been detected in customer use, and has only been seen during the debugging of a new feature. However, the problem could be caused by configuring High Performance Routing (HPR) in a remote device.
: The workaround is to reconfigure the remote device to not specify HPR. [CSCdj79403]

This problem results in the mainframe complaining about SIOCC2, which is a start I/O condition code 2. SIOCC2 is an indication that the device is busy for an extended period of time. Without this fix, the problem can be worked around by shutting down the CMCC interface and then bringing it up again. [CSCdj80886]
The CSNA responds to the TEST command when no SAP is active. This error may result in an end station trying to connect to a CMCC Adapter that has no connectivity to the host. This situation occurs when the CSNA interface is shut down manually or by other media problems (for example, a loose cable). [CSCdj80925]
The CMCC Offload code prints an OFFL-0-WRONGFREE error message and hits a fatal error. This problem occurs if the read channel program ends in the middle of a socket response that spans more than one CLAW buffer and a halt subchannel is issued before the read channel program resumes.

: There is no workaround. [CSCdj80990]

During the recovery from certain error conditions in the CMCC TN3270 Server, the CMCC Adapter may sometimes report a Fatal error message (code=35) and spontaneously reload. [CSCdj81522]
The CMCC microcode may log the message "Fatal Error 35" and spontaneously reload. This situation can happen if the CMCC TN3270 Server session switch (DLUR) feature is being used and either the DLUR component or TN3270 Server is shut down or deconfigured while there are configured DLUR links. The workaround is to remove the DLUR links first, using no link name. [CSCdj82232]
CSNA fails to send disconnect when indication buffer is in use. This causes the following results: the end-station is not able to connect back in and if the connection is flow-off, it will remain in flow-off state. [CSCdj82785]
With certain TN3270 client software, the user can successfully establish an LU-to-LU session, but when the user enters the first data after the bind, the CMCC TN3270 Server disconnects the client. The CMCC TN3270 Server logs the fact that it received invalid Telnet data from the client.

: The problem occurs only with certain clients (for example, PC3270 and Attachmate) and when the user enters data before the host application sends out its first screen (most applications send a screen of data immediately after the bind, start data traffic).
: Because the problem only occurs in TN3270E mode, and some clients have an option to disable TN3270E mode, it is possible to bypass this problem in situations where TN3270E mode is not required. The alternatives are to use a different client or change the host application. [CSCdj84064]

When a TN3270E client connects to a CMCC TN3270 Server and enters a logon request, the server sometimes discards the request and sends a "-B" message to the client. This message becomes appended, on the screen, to the logon request data. If the user now presses enter, the host replies with the following message:

"unsupported function".

: This problem occurs if the same LU can be used by TN3270 and TN3270E clients.
: The workaround is to retry the logon request. [CSCdj84122]

In some customer environments, LOGDATA records that consist of multiple error messages can result from the mainframe not responding to device level activity for longer the 500 ms. The ESCON architecture states that this timeout value can range from 400 ms to 850 ms. To avoid some of the occurrences of LOGDATA, adjust the timeout from 500 ms to 800 ms. [CSCdj84218]
The channel transport architecture device is informed of the connection count irrespective of the order in which the channel transport architecture device and LLC2 register. [CSCdj87846]

Caveats for Version 22.26/Version 22.27 Modifications

This section describes possible unexpected behavior by Version 22.26. All the caveats listed in this section are resolved in Version 22.27. See Table 10 for the Cisco IOS software release that corresponds to the 22.27 microcode version.

Under certain conditions during memory allocation, the CIP can encounter a fatal error upon completion of a direct memory access transfer from or to MEMD. The fatal error code is typically 35 and it can coincide with the following message:

"RSP-3-RESTART: Interface Channel4/x, output stuck

: This error can be triggered by all software features with the exception of CLAW (IP datagram). It is more likely to occur with features that use a lot of memory, like the TN3270 Server. [CSCdj52480]

If CIP TN3270-Server DLUR is configured with a link to VTAM over a CMPC tg, the link will not activate and the XID negotiation will fail.

: With the DLUR EN active, inact force the vtam local node by issuing the /v net,inact,id=mvsln,f command. Then try to activate the local node by issuing the /v net,act,id=mvsln command
: The workaround is to issue a shut command then no shut command on the TN3270 Server DLUR. Alternately, do not configure the link from DLUR EN to VTAM. Configure it only from VTAM to DLUR EN. [CSCdj63054]

There is a CIP fatal error in the IP Input task when running Offload or TN3270 Server.

: This bug occurs only if a new IP fragment received by the TCP/IP stack completely overlaps a fragment that is already on the reassembly queue. As a result of the overlap, the fragment on the queue is freed. There is a bug in the code where the memory used to hold this IP fragment is accessed after it is freed. This access can lead to a fatal error if the IP Input task gets preempted at the right time.
: The workaround is to apply an outbound access list that denies IP fragments on the channel interface. This action may break UDP applications and TCP applications that do not use path MTU discovery. If an IP node generates them, it should be sufficient to block fragments from just that IP source address. [CSCdj63361]

While parsing messages, the offload code does minimal sanity checking on blocks with Offload messages received from the mainframe. Corrupted blocks appear to contain a large number of Offload messages (up to 128 per 4 KB CLAW frame). Because there are not enough control blocks to handle this many messages, the CIP hits a fatal error. This problem should not occur if Offload messages are properly formatted.

: There is no workaround. [CSCdj64309]

In an environment where there are ESCON link-level errors occurring, the CIP may log the following message and reload:

%CIP25-0-MSG: %CCA-0-DEV_ERR2: Device error but no active defined device.

: The CIP's ESCON processor may lock up in the middle of connection recovery following link-level errors. The neighboring ESCON link-level facility (host or director) will report a sequence timeout followed by a not operational sequence (NOS) detected.
: There is no workaround. [CSCdj64563]

An RFC 1646 printer hangs when a client sends a negative response before it receives the whole frame and the negative response is not sent to the host.

: The workaround is to reconnect the printer. [CSCdj65302]

Any IP packet generated by the CIP's TCP/IP stack which contains IP options could contain an invalid TCP, UDP or ICMP checksum. The destination host will discard any such packet because the checksum does not match. [CSCdj65535]
After a few thousand disconnects, the VTAM gets the following error message:

IST565I..<nocmdBold>

: When the VTAM receives a NMVT power-off PSID, it may lose buffers. The workaround is to enter opt70 nmvt_psid 0 at the console port to disable sending the PSID. [CSCdj66921]

If clients do not set the response sequence, the TN3270E printer hangs because the host does not get a response.

: The workaround is to change client software. [CSCdj66924]

When a PC tries to bring up a session, the VTAM rejects it with the following connection request denied error message:

IST381I  AM SC EXIT FOR ID = T7751    FAILED - CANNOT DEFINE NODE
IST680I  CONNECTION REQUEST DENIED - ID = T7751    INVALID NETWORK NAME
IST1394I  CPNAME = NETVGI.T7751       STATION ID = 020005D07751
IST081I  LINE NAME = L0750C93, LINE GROUP = GXCA750 , MAJNOD = XCA750
IST314I  END


: There is no workaround.
: When a large number of sessions are abnormally terminated because of an invalid configuration of LLC parameters, the CSNA terminates the connection, but fails to notify VTAM. This results in the VTAM continuing to hang on to the session and the end stations trying to reconnect to the host. [CSCdj68124]

CSNA has a restriction on the usage of SAP value 6, which is reserved for DODIP (Department of Defense IP). This restriction has been removed. [CSCdj68133]
A CSNA user can regulate new connections by lowering the connection threshold below the maximum LLC originally specified. This change results in the CSNA not responding to the test frame from an end-station when session counts exceed the connection threshold. No new connection is brought up through the CIP. [CSCdj68517]
In networks with a high volume of type 1 traffic (typically XIDs) the VTAM may combine many type 1 messages in a block, mistakenly causing the frame to appear badly formed and resulting in the ASSERT message and an automatic reload of the CMCC image. This problem occurs only with cip21-19 images and earlier. It does not happen with cip22-xx and higher.

: The workaround is to artificially limit the rate at which remote stations can connect by adding delays to a startup script. [CSCdj69281]

CIP microcode reloads occasionally when the user issues a shut command then a no shut command when in the CIP TN3270 Server command mode. This problem occurs only when there are active TN3270 sessions connected to the CIP.

: The workaround is to shut each of the PUs associated with the TN3270 Server and then issue a shut command and a no shut command on the TN3270 Server. Issue a no shut command on the PUs again. [CSCdj69368]

When the offload code on the CIP and the TCP/IP offload code on the mainframe begin to communicate, they exchange restart requests and responses. Under certain conditions, the restart requests and responses from the CIP could contain invalid data. The mainframe will react to this condition with the following error message:

Unexpected result from offload device ..

: The mainframe will dump the offending offload message that contains the text "Data runs off end of buffer".
: There is no functional impact. [CSCdj69527]

If the CIP runs low on memory while the CIP TN3270 Server DLUR (SNA session switch) function is in use, then the CIP may reload spontaneously. [CSCdj70138]
The kernel timeout function hits a fatal error when called with a negative time value. For example, this will happen if the Offload code gets a connect request with a timeout value of 0x7fffffff seconds.

: The workaround for the offload problem is to reconfigure for IP datagram mode. There is no workaround available for the bug in the kernel timeout function. [CSCdj72646]

Caveats for Version 22.25/Version 22.26 Modifications

This section describes possible unexpected behavior by Version 22.25. All the caveats listed in this section are resolved in Version 22.26. See Table 10 for the Cisco IOS software release that corresponds to the 22.26 microcode version.

Despite "unbind-action keep" being configured, the TN3270 Server disconnects a TN3270/E client if sysreq is followed by any key. This disconnection is not a problem if sysreq is not used to close an LU-LU session.

: The workaround is to not use sysreq or to reconnect the client if an SSCP-LU session is required. [CSCdj21850]

For Offload and CLAW devices, if the write device (odd device number) on the mainframe is misconfigured to talk to the read subchannel (even device number), the CIP could crash with an SCBNRDY error message.

: The workaround is to properly configure the devices on the mainframe. The most likely cause of the problem is in the virtual machine (VM) if the write device is attached to the read subchannel. In this scenario, detach both devices (read and write) and reattach them to the correct subchannel. [CSCdj23802]

Sending a ping larger than 4096 bytes to a CIP TN3270 Server IP address will cause the CIP to hang and consume all available CIP memory. [CSCdj39225]
Although an NMVT PSID was sent to VTAM during the connection state, a PSID was not sent to VTAM during disconnection. Sending both PSIDs allows network management to know the connection time of the clients. [CSCdj39365]
The following changes have been made to address some TEST command issues:
- Answer TEST CMD other than DSAP of 0x0 if it is activated.
- TEST CMD is dropped if the adapter has not activated the SAP or if the maximum number of connections has been reached.
- TEST CMD is dropped while the SAP is in the deactivation processing mode.

: [CSCdj41342]

When a TN3270E connects, a new LU is selected. This selection causes the LU to cycle once and may cause a connection failure. [CSCdj43047]
When recycling a LOGAPPL application that is connected to a CIP TN3270 Server, one or more PUs can remain in flow-control state. This scenario can cause the PU to go into ACT/BUSY state and terminate all LU traffic going to users.

: The workaround is to recycle the PU. [CSCdj46065]

With a TN3270 Server, if a CIP application shuts down its own TCP connection, it sends out a FIN (finish) segment. If it never receives a FIN from the peer, the local side of the connection will stay in FIN_WAIT_2 state even after the application closes the socket completely. [CSCdj48609]
Memory is leaked by the CIP TCP/IP if a direct memory access (DMA) controller write operation detects an error. [CSCdj48929]
DLUR PUs can stick in PAPU2 state. Recycling (by issuing a shut command and then a no shut command) the DLUR does not help. This condition occurs if all of the DLUR PUs are made inactive at the host, but the DLUR EN PU is active.

: The repeated attempts of DLUR to activate the PUs result in buffer loss in the CIP. Eventually a pool of buffers becomes empty and no ACTPUs are processed.
: The workaround is to recycle the TN3270. [CSCdj50517]

The actual number of supported max-llc2-sessions is one less than the number configured. The workaround is to ensure adequate margin in the max-llc2-sessions specification. [CSCdj51067]
For CSNA devices, multiple LOGDATA records can occur as a result of the corruption of the count in the data request frame. Usually when multiple LOGDATA records occur, it is for some other reason (for example, a bad fiber connection). The way to verify that it is this problem, is to put an ESCON analyzer on the ESCON connection and trigger the beginning of connection recovery (UD sequence).

: There is no workaround. [CSCdj51076]

When a TN3270 client is powered down without terminating the TCP/IP session with the CIP, the TIMING-MARK and TCP retransmissions tear down the connection. If a client is unable to work with TIMING-MARK and uses a previously specified LU name then it will be unable to reconnect. [CSCdj51696]
If several of the TN3270 Server PUs are configured under DLUR and are INACT or unknown at the host, then the process of stabilizing the DLUR-DLUS pipe can be prolonged thereby preventing PUs from activating.

: This situation occurs with certain patterns of "good" and "bad" PUs. For example, out of a total of six PUs, the first five could be INACT at the host and the sixth could be CONCT.
: The workaround is to shut down the PUs on the CIP or make them active at the host. [CSCdj54138]

When the customer attempts an initial program load (IPL) to a Hitachi mainframe running IBM VSE 1.4.1 with Connectivity Systems TCPIP stack for VSE, the system goes into a loop and the CIP appears to be in an offline state. After several attempts to trace the problem on the CIP, the following trace indicates the CIP failed to respond:

Channel (F7)             Cisco/CIP        Explanation
 
   ALA    ==================>         (CH sends Aquire Link Address) 
          
          <=================   ALA    (CU sends Aquire Link Address) 
 
   ACK    =================>          (CH acknowledges request from CU) 
 
           End of Communication       (CU never acknowledges request from CH)

: [CSCdj55448]

During peak times of logon-rate and network congestion, end users cannot access the CIP TN3270 Server for extended periods of time (5 to 15 minutes). Existing TN3270 sessions exhibit normal response times during these periods, but new connections are locked out. [CSCdj56273]
The SNA sense code 2003 is sent to the host that is causing the client to disconnect. If the host has the direction and the client sends data, the data will be queued. Later, when the host sends data with the EBI bit on, the client data will be sent. However, subsequent data from the host will get a negative response.

: The workaround is to reconnect the client. [CSCdj58664]

There exists a small timing window that may cause the LLC2 connections to hang when the connection enters the ERROR state. This problem prevents the user from being able to change to XCA mode. [CSCdj59231]
A TN3270E disconnects after the host sends an unbind message. When the user presses the F3 key to end the LU-LU session, the session is disconnected instead.

: The workaround is to reconnect the client. [CSCdj59985]

Caveats for Version 22.24/Version 22.25 Modifications

This section describes possible unexpected behavior by Version 22.24. The caveat listed in this section is resolved in Version 22.25. See Table 10 for the Cisco IOS software release that corresponds to the 22.25 microcode version.

The host XCA node goes down or an attached PU or LU goes into the INOP state after installing a CIP image.

: The workaround is to revert to a previous CIP microcode version or install the next release, which does not contain this problem. [CSCdj51725]

Caveats for Version 22.23/Version 22.24 Modifications

This section describes possible unexpected behavior by Version 22.23. All the caveats listed in this section are resolved in Version 22.24. See Table 10 for the Cisco IOS software release that corresponds to the 22.24 microcode version.

The Offload write task does not terminate after deconfiguring the offload if the host has sent frames on the write subchannel IP link. The only known side effect is that this task will take up an entry in the task table and some memory. [CSCdj37835]
When using the offload feature, if a Halt Subchannel is issued from the mainframe when the offload read subchannel is busy with more-to-come chains, the CIP could fail in many ways. The problem could result in a fatal-error as a result of freeing and invalid addresses (for example, 0 or a non-four-byte aligned address) to the global page queue. The problem could also result in a fatal error as a result of the ESCON processor (ESCP) locking. It is unlikely that this problem will occur because the mainframe rarely performs a Halt Subchannel on busy connections. [CSCdj43959]
A TN3270 client, which is mapped to a specific LU, fails upon reconnection. Although the first connection is successful, when the client disconnects and then tries to reconnect, the connection attempt will fail. [CSCdj48876]

Caveats for Version 22.22/Version 22.23 Modifications

This section describes possible unexpected behavior by Version 22.22. All the caveats listed in this section are resolved in Version 22.23. See Table 10 for the Cisco IOS software release that corresponds to the 22.23 microcode version.

If a CIP TN3270 PU is configured to connect from the host to the CIP via NCP, the link may fail.

: The workaround is to configure the CIP TN3270 PUs as connecting at the host. [CSCdj07152]

When using DDDLU (LUGROUP) in conjunction with DLUR (for example, a CIP TN3270 as SNA Session Switch), the host's session awareness does not recover after a DLUS outage. This error occurs because DLUR provides the session awareness on the required space character for the ACTLU, but for DDDLU LUs there will be no ACTLU. [CSCdj15193]
If a PU is remaining in the busy state, a new session may connect to the PU despite the availability of other PUs. The original connection will fail and there will be no warning message to indicate the connection failed.

: For the TN3270E client, there is no warning message if the host does not send a start data traffic (SDT) message. If a Telnet instead of a TN3270 client connects in the connection will fail, but an LU may be permanently assigned and not be reused again. If the host sends a DACTPU message, the statistics of the LU connections and disconnections may be wrong.
: Some hosts may send system services control points (SSCP) LU data before they send notify-response data. Also, a "no bind" warning message may be sent. [CSCdj24694]

Following a channel error or host initial program load (IPL), the VTAM is unable to activate the XCA major node. The router log shows the following message at each attempted activation of the XCA major node:

Jul  4 00:10:28: %CIP25-6-MSG: %MSG802-6-LLC_DUP_SAP: LLC Duplicat SAP on interface 546 : SAP=4.

: Issuing the llc show all command on the CIP indicates that CSNA has failed to clear up one remaining session.

CIP-Slot5#llc show all
--- AdapNo 02, LanType Token     , SAP 04 ---
pcep=0860 rmac=4000.0000.7190 lmac=C000.0115.6500 rsap=04 lsap=04 this=8120EDA8
pcep=0860 state=ADM rbusy=no  lbusy=no  flow=on  pflag=1 dflag=0 v_r=0    v_s=0    last_nr=0    flag=60264282


: The workaround is to issue a microcode reload command to clear the hanging session. [CSCdj26081]

The LUs are allocated from a PU so that no more LUs leave from the PU. If the PU become inoperative (INOP), then typically 255 sessions are lost. However, if the LUs are PUs evenly allocated, then fewer users are affected upon PU INOP. [CSCdj28852]
A CIP configured with CSNA and TN3270 Server may crash with the following message:

SSI_ASSERT failure in ../cta802/ccb802.c @ 3044 - LOOPBACK_FLOW_RECEIVED
Fatal error (code=09)

: [CSCdj29175]

When a DACTPU Giveback is sent to a TN3270 Server DLUR PU, no response is sent to the VTAM. After V INACT,ID=pu,TYPE=G, the PU is left in the state physical device address control point. [CSCdj29413]
The CIP crashes with a fatal error code 35 because the global queue of 4 KB buffers contains 0x00010001 instead of a valid address. The fatal error output contains the following line:

 "%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF 803F0010 00000000 00010001  ..."

: If the second double word on this line contains 00000000 00010001 it is likely that the crash was caused by this bug. [CSCdj30387]

Each time a client connects and selects a static LU, the client is delayed for 3 seconds before the host connection is made. [CSCdj30652]
An extra end of job message (EOJ) may be sent to the printer after the last message, but before the client response. This may cause the printer drop the last messages.

: This bug is a regression caused by CSCdj28167. It occurs if the last message the host sends does not have end bracket (EB) bit on it. [CSCdj30937]

A CIP may crash with the following message after many errors are received over an ESCON Channel Adapter (ECA):

Jul 30 00:53:29: %CIP3-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta/cta.c @ 345 - FALSE
Jul 30 00:53:29: %CIP3-0-MSG: %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)

: [CSCdj30949]

Under rare circumstances (for example, during power outages or when a TN3270 client disconnects suddenly in middle of normal traffic) the CIP microcode may reload spontaneously with error 35.

: There is no guaranteed workaround other than to avoid random disconnection from the client in the middle of transactions. [CSCdj31131]

Performing a no shutdown command on a CIP virtual interface where the llc2-max-connections command is greater than 5000, can result in excessive memory consumption. This problem exists in versions up to cip22-21.

: For example, the interface works well if it is brought up with 6000 sessions. However, when the interface is issued a shutdown command and no shutdown command, an additional 64 K 160-byte buffers is added to one of the channel transport adapter buffer pools, consuming about 10 MB of memory. This excessive memory consumption causes various problems depending on the size of the CIP memory. The size of the buffer pool can be corrected by issuing a microcode reload command. [CSCdj31884]

The show controller cbus command could indicate that the channel utilization is 100 percent busy, despite no device-level traffic. This situation most likely occurs with a Parallel Channel Adapter (PCA), and less likely with an ECA. Without this fix, any start subchannel connected to one of the devices should cause the utilization to start reporting correctly. [CSCdj32046]
This bug fixes and deprecates an unimplemented trap (cipCardLinkFailure) and implements a new trap (cipCardDtrBrdLinkFailure). Also, a new snmp-server enable traps channel-failures command was added to the parser. This command enables and disables the new trap (cipCardDtrBrdLinkFailure). [CSCdj32297]
A TN3270 Server, when operating with RFC1646-compliant printers, may send the wrong sense-code to the host when presented with a printer 'InterventionRequired' condition. The sensecode actually provided to VTAM is 0x1003000; correct operation might result in a sensecode of 0x08020000 or similar. [CSCdj36856]
The TN3270 Server may drop an unbind image from a job entry subsystem to a TN3270E client. The client (for example, a PC3270) may send a disconnect after receiving a bind image without receiving an unbind image. [CSCdj36868]
If VTAM is shut down while traffic is flowing, an external communication adapter (XCA) node may not start when the VTAM is restarted.

: The workaround is to issue the no csna command on the nonfunctioning subchannel, the no shutdown command on the physical interface, or the microcode reload command. [CSCdj38712]

When using a CIP TN3270 Server with the SNA session switch feature (DLUR), PUs that have a fully qualified name length of 17 characters cannot be activated. Activation fails with the SNA sensecode 0x10060000.

: The workaround is to use PU names that are less than eight characters. [CSCdj39358]

When hosts send a null response unit with begin chain (BC), the server will not send a TN3270E header to the printer client. The client then sends a disconnect to terminate the session. A typical host application is a job entry subsystem. [CSCdj39359]

Caveats for Version 22.21/Version 22.22 Modifications

This section describes possible unexpected behavior by Version 22.21. All the caveats listed in this section are resolved in Version 22.22. See Table 10 for the Cisco IOS software release that corresponds to the 22.22 microcode version.

When the CIP TN3270 servers only active DLUR links are configured from the host end and not from the CIP end, no attempt is made to find a network node server. [CSCdj18737]
The CIP1 with 8 MB DRAM reloads continuously when configured for 10 LLC sessions when using CSNA and cip22-19 microcode. With max-llc2-sessions 1 configured, however, the CIP runs without any problems. [CSCdj19012]
If clients disconnect from a CIP TN3270 Server in a short period of time, the server loses buffers and the PUs stay in the ACT/BUSY state. [CSCdj20423]
A CIP TN3270 Server logs both the rejection of received binds and the rejection of sent binds as "Rejecting rcvd Bind." [CSCdj20719]
The commands that begin with show extended channel slot/port can fail to display all expected data because of a bug in the inter-process communications function used by Cisco IOS software to communicate with the CIP. [CSCdj21544]
LU-LU sessions are not preserved and the links are disconnected when an SSCP takeover or giveback occurs. [CSCdj22128]
A client can hang when a TN3270E client sends data before it sends a response. This error causes the data to be sent to the host before the response and causes the bracket state to be incorrect. This problem occurs using Personal COMMunication (PCOMM) 4.1 when the PA1 key on the TN3270 terminal is pressed while data is sent to the client. [CSCdj22926]
A CIP TN3270 Server PU stays in ACTIVE state after removing the internal adapter from the router configuration that the PU was using to connect to the host over the physical channel on the CIP. [CSCdj23224]
When the CIP is not channel attached, the CIP crashes with the following SSI_ASSERT message:

 %CIP0-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../ssi/ssi_buff.c @ 158 - (msg) && ((( msg)->m_flags & ( M_PK
 %CIP0-3-MSG: THDR | M_EXT)) == ( M_PKTHDR | M_EXT))

: [CSCdj23424]

In a CIP TN3270 Server using TN3270E client, multiple chain messages do not use TN3270E responses when the first in chain has the Exception-response (EXR) flag set. The definite-response (DR) actually comes on last in the chain, but by that time it is too late.

: The workaround is to handle multiple chain messages as if they are definite responses from the host while generating TN3270E header. This workaround will ensure that the definite-response from the host can be used to guarantee an end-to-end response. [CSCdj24073]

The CIP TN3270 Server should stop listening on the relevant IP port if it cannot accept any more TN3270 or TN3270E connections. This action ensures that device driver makes correct decisions. [CSCdj24385]
The SNA session switch (DLUR) support in the CIP TN3270 Server is limited to 16384 concurrent sessions per CIP. Attempts to activate more LUs are rejected with sense code 0812 0007. [CSCdj24704]
A CIP running TCP/IP offload can (under very rare circumstances) hit a fatal error. The fatal error messages will be preceded by:

%CIP21-0-MSG: %CCA-0-BSQ_FULL: Buffer status queue is full

: [CSCdj25040]

The CIP crashes with a fatal error code 35 because the global queue of 4 KB buffers contains 0x00000100 instead of a valid address. The fatal error output contains the following line:

%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF BE810000 00000000 00000100  ...

: If the second double word on this line contains 00000000 00000100 it is likely that the crash was caused by this bug. [CSCdj25062]

During link inactivation, a message from downstream through a CIP TN3270 Server could cause the CIP to reload spontaneously. [CSCdj25255]
If the host sends SSCP-LU data before a notify response and the client sends data before a notify response, the client is disconnected. This bug should happen only on a busy host with an application software sending data as soon as it receives data. [CSCdj27305]
If the host sends consecutive exceptional response frames, the TN3270 Server will send these frames before any responses comes back from the RFC 1646 printer client. Some clients (for example, Attachmate Extra 4.3) may drop the data. [CSCdj28167]
When a DLUR link goes inactive, the TN3270 Server reports the link outage with the wrong transmission group number. If the transmission group number is zero, then there is no problem. If the transmission group number is not zero, then DLUS may attempt to route dependent LU sessions over the link and the session setup will fail. [CSCdj29401]
When the offload code on the CIP gets a duplicate send request because of the IBM bug known as APAR PQ02051, it responds with an EINVAL error code to the second request. The mainframe reacts to this error by dropping the session.

: The workaround is to drop the duplicate request. [CSCdj31238]

This fix corrects the CSNA problem of handling invalid channel blocks from host. [CSCdj31253]

Caveats for Version 22.20/Version 22.21 Modifications

This section describes possible unexpected behavior by Version 22.20. All the caveats listed in this section are resolved in Version 22.21. See Table 10 for the Cisco IOS software release that corresponds to the 22.21 microcode version.

If all CIP interfaces are shut down when the CIP is initialized (for example, during a microcode reload or router load) on a Cisco 70xx RP router, the following error message will be displayed:

%CIPn-2-MSG: %IPC-2-NOMEMD: Unable to obtain CBUS IPC transmit buffers(BUS)

: This error message does not cause any problems in the network. [CSCdj00153]

The CIP1 in the RSP immediately crashes with an error 35 after loading the router. [CSCdj09542]
This fix addresses the CIP failure caused by the CIP LLC2 timer services malfunctioning. [CSCdj11140]
Issuing a shut or no shut command when using the Cisco IOS/390 TCPIP stack and the Parallel Channel Adapter (PCA) can cause incorrect data transfer lengths and data corruption. [CSCdj13880]
If an inactive CIP TN3270 link is deleted with the no link command and is then added again, the CIP microcode may spontaneously reload. [CSCdj14956]
If the mainframe issues two close requests for the same socket, the second close request will cause an OFFL-4-BADDESC message to be displayed followed by a printout of the context necessary to troubleshoot the problem. This is a cosmetic bug caused by an unusual timing condition. This bug will not affect normal operations and does not indicate any session failures. [CSCdj15521]
The CIP may occasionally reload spontaneously with a traceback and the following error message:

%DEBUGGER-0-FATAL_ERROR: Fatal error (code=32)

: This failure has only been observed at sites running the CIP across an SRB network to a host (instead of the normal channel attachment). [CSCdj17365]

Configuration of CIP-CSNA appears to intermittently cause blocked virtual routes across VTAM-to-VTAM connections. [CSCdj17412]
If the mainframe offload code sends a socket request with a bad length field, the CIP may print an error message indicating that the length is bad. During the processing of this error message, the code could cause an alignment exception. The result is a fatal error with code 35. [CSCdj17843]
If a CIP TN3270 DLUR link is deleted with the no link command and is then added again, the link becomes stuck in WAIT state. [CSCdj19069]
When the CIP TN3270 Server disconnects a TN3270 client session, it sends out Telnet commands and an ASCII message describing its reason for the disconnect. The TCP session closes shortly after the message. Some clients do not like the Telnet command; others do not like TCP close coming after the data. The clients may behave unusually by giving an error message or locking up. These clients do not have the problem with servers that do not send Telnet commands and the ASCII message before the TCP closes. This message may cause the TN3270 client to freeze. If the TN3270 client freezes, reboot the operating system. This situation has not been reported with other TN3270 servers.

This malfunction could be caused by the following situations:

TN3270 clients do not follow the RFC, which allows network virtual terminal messages to be sent at disconnection time to inform the client of reason for disconnection
Client TCPIP stack reorders the data and finish packets causing an error on client

The workaround is to upgrade to a client TCPIP stack and application that conform to RFCs.

If a CIP TN3270 DLUR (SNA session switch) link fails or is taken down remotely, then DLUR incorrectly reports that the link state is up. This can lead to session start attempts failing with sense 80140003.

: The workaround is to take down the DLUR-DLUS session. [CSCdj19817]

In TN3270 Server on CIP, the PU sometimes stays in ACT/BSY state. In this state, no new users are allowed to connect and existing user sessions stop.

: This problem only occurs if customers are using TN3270E. Therefore, it does not affect customers who are only using TN3270 clients.
: The buffers are lost only if BIND is followed immediately by UNBIND without start data traffic. This circumstance should be avoided because some host application might amplify it.
: To avoid locking up the PU, periodically reload the microcode on the CIP if a TN3270E and special host application are being used. PU reactivation is also a way to recover although it does not guarantee recovery. [CSCdj20210]

The CIP can spontaneously reload during operation if the host applications attempt to rebind immediately after a client disconnects. This problem did not exist in versions prior to cip22-20.

: A possible workaround is to ensure that the client always goes back to SSCP-LU after being in session, which means not using LOGAPPL or session-queuing. [CSCdj20596]

The following error messages may appear when issuing a DACTPU or removing a PU:

May 27 18:26:37: %CIP1-1-MSG: %TN3270S-1-LU_ERROR: lu error lu not in hash
table: :36 pu:80A78998, tnet:0 May 27 18:26:37: %CIP1-1-MSG:
%TN3270S-1-LU_ERROR_INFO: LU info: Event 0 0 0 0 0 0 0 0 0 0 0 0 0 3 6 14 ,
state = A, snaState = 0, flag = May 27 18:26:37: %CIP1-1-MSG:  1

: This error message is caused by fixing CSCdj15559. These error messages should not hurt network operations. [CSCdj21011]

During the recovery of certain ESCON link errors, the CIP could crash with a fatal error after the ESCON adapter reports a device-level error when there is no active device. When this problem occurs, the fatal error is preceded by the following error message:

CCA-0-DEV_ERR2: Device error but no active defined device

: The workaround is to determine and resolve the reason for the ESCON link error. [CSCdj21031]

Caveats for Version 22.19/Version 22.20 Modifications

This section describes possible unexpected behavior by Version 22.19. All the caveats listed in this section are resolved in Version 22.20. See Table 10 for the Cisco IOS software release that corresponds to the 22.20 microcode version.

The tracerte utility on VM or MVS hosts does not work with the CIP Offload code. [CSCdi52947]
TCP/IP sometimes sends a purge socket request with a bad socket descriptor. The socket descriptor is a 16-bit value placed in a 32-bit field. A corrupted request has some of the upper 16 bits set. Usually these values correspond to the 32-bit host socket descriptor for that socket.

: With this fix, the CIP now specifically checks for a host descriptor and searches through the control blocks for a match. Because using the host descriptor is considered incorrect behavior, the following error message is displayed:

OFFL-4-WRONGDESC

: [CSCdi64196]

If the host is not configured for Dynamic Definition of Dependent LUs (DDDLU), the client connection is rejected without warning. [CSCdi73120]
The following are issues related to the output from a show extended channel slot/port csna stat command:
- The byte count sent to the host is not accumulated correctly. A symptom is that the number of blocks exceeds the number of bytes.
- The output direction is host-centric (transmitted means bytes from host) instead of Cisco's convention of router-centric (transmitted means bytes to host). This issue has been corrected.
- The block count sent to the host, which includes all blocks, exceeds the sum of the values for the CSNA device such as Txd by maxpiu, Txd by time-delay and Txd by length-delay Blocks/Bytes counts because the LSA channel protocol includes blocks that contain only control information. [CSCdi77063]
When the host sends the Offload box a close request followed by a purge request for the same socket, collect the following CIP trace information:

: trace len 500 trace all off trace offl on trace offl_hdr on trace socket on stop offl_lpurge on
: Wait for the next BADPURGE error message and capture the trace table information:
: tasks trace display stop off trace default
: Send the output and all the console messages to Cisco engineering to resolve the problem. [CSCdi84662]

The CIP crashes when it tries to process either the CLAW Offload configuration command number 129 or the CSNA command number 257.

: The workaround is to not configure more devices or subchannels on a channel interface than are designated in the router configuration manual. [CSCdi86777]

If the LU name in VTAM has a "$" character, the output from show extended channel slot/ 2 tn3270 server pu pu-name will display a "?" character. [CSCdj03576]
The CIP crashes with Fatal error (code 35) when the host sends a Write request without wcc (illegal data). [CSCdj05890]
When using the SNA session switch feature of a CIP TN3270 Server, if an upstream link is lost while it has LU-LU sessions, then the LU with the first local form session identifier (lowest LFSID) session will be left in a hung state. [CSCdj06185]
For a CSNA user, this fix enables the CSNA to better cope with malformed protocol data unit (PDU) or garbage frames from the network. [CSCdj06519]
If a link from a CIP TN3270 DLUR to VTAM (not the link that carries the DLUR-DLUS pipe) is a shut command then no shut command or deleted and added again, then the link will not be selected for LU-LU sessions. The resource sequence number (RSN) used to report the changed link state is incorrect, so DLUS ignores the information that the link has been restored. This circumstance can be confirmed by issuing the command DISPLAY NET,TOPO,ORIG=x,DEST=y at VTAM, where x is the CP name of the DLUR, and y is the CP name of VTAM on that link. If the problem has occurred then the status will be shown as INOP although the link is really active (and can be confirmed by reversing ORIG and DEST and reissuing the command).

: A workaround is to take down the DLUR-DLUS pipe after restoring the link. This can be done by issuing the VARY NET,INACT,ID=x,F command at VTAM, where x is the CP name of the DLUR, then making it active again. During this recycle, no new LU-LU sessions can be established, but existing sessions will be unaffected. [CSCdj09855]

An extra 2 bytes of 01 c2 will be sent to the LU type 1 printer after end of job if the client printer sends data or negative response to the server. This may cause the printer to print 2 bytes of garbage data. [CSCdj10135]
If a CIP TN3270 Server PU is configured with the same remote MAC and SAP, then communication with the CIP is lost (output is hung). [CSCdj10605]
When using Interlinks SNS TCPACCESS or Cisco IOS/390, the claw connection may not become established after a hard shutdown and restart of the host TCP/IP stack. The workaround for this problem would be to shut down the CIP interface and then issue the no shut command. [CSCdj11561]
If the mainframe offload code sends a socket request with a bad length field, the CIP can crash with an alignment exception. The result is a fatal error with code 35. [CSCdj13586]
This change provides additional diagnostic information when CIP detects failure condition. To capture this additional diagnostic information, users who have "logging buffered" configured have to configure a log buffer size of at least 36KB. [CSCdj14084]
If two PUs are trying to talk to each other, a spontaneous microcode reload could happen with fatal error 35 in the Timer area. This fix corrects that potential microcode reload.

: The workaround is to correctly configure the PU. [CSCdj14302]

If an inactive CIP TN3270 link is deleted with a no link command and then added again, then the link will always be rejected by the CSNA layer with the following message:

%MSG802-6-LLC_DUP_CCB.

: [CSCdj14957]

Caveats for Version 22.18/Version 22.19 Modifications

This section describes possible unexpected behavior by Version 22.18. All the caveats listed in this section are resolved in Version 22.19. See Table 10 for the Cisco IOS software release that corresponds to the 22.19 microcode version.

If a packet without end of record (EOR) is received and followed by another packet with EOR and followed by data, a failure condition can occur for a TN3270 session. When this failure occurs, a random number of bytes will be appended to the first packet. If the second packet only contains EOR, or if multiple packets that end in EOR are received, the problem does not occur. The EOR for a TN3270 Server is represented by the message FF EF. This failure could result in one of several atypical system behaviors including:
- Spontaneous reload of CIP
- Lost sessions that are accessing the host via this channel connection

: In this case the channel connection that this TN3270 session is using must be restored by deactivating and reactivating at the host.
: [CSCdj08881]

Caveats for Version 22.17/Version 22.18 Modifications

This section describes possible unexpected behavior by Version 22.17. All the caveats listed in this section are resolved in Version 22.18. See Table 10 for the Cisco IOS software release that corresponds to the 22.18 microcode version.

An offload application can deplete all control blocks of a particular type and prevent traffic from going through a port adapter on the CIP. This situation can occur when several thousand established TCP connections close in a short period of time.

: The workaround is to reload the CIP microcode. [CSCdi41087]

When the TN3270 Server is running on the CIP, the CIP may send the following error message:

tnet sequence lost, expected....

: [CSCdi68249]

When the CIP TN3270 Server requests dynamically allocated logical unit (LU) sessions, the system services control points (SSCP) host VTAM produces the following message:

IST1016I
REASON = LU HAS ACTIVE OR PENDING ACTIVE SESSIONS

: The LU has a controlling Primary LU as defined by the LOGAPPL parameter.
: The workaround is to request another session. [CSCdi86173]

A request/response unit (RU) gets marked Definite Response when DLUS at the host sends an RU to the CIP TN3270 Server's DLUR (a session switch feature). The DLUR responds incorrectly, causing DLUS to unbind the session with sense code 400F0000. The PUs under DLUR enter HARD INOP state at VTAM. [CSCdi90099]
A TN3270 client can send inbound data after the TN3270 Server commits to accept outbound data. If the host data ends with a segmented RU, and the server queues the inbound data, then the server takes the inbound data out of the queue without waiting for the final segment. The server then incorrectly tracks the bracket state and rejects the next message from the host with SNA sense 2003.

: The workaround is to ensure that the outbound data is not segmented and by configuring the llc2 N1 4105 command on the virtual adapter of the CIP virtual interface. [CSCdi91434]

When the CIP TN3270 Server runs with a load greater than the CIP CPU can handle, the VTAM consumes more cycles than is desirable.

: The workaround is to reduce the offered load on the affected CIP card by reducing the number of connected sessions. [CSCdi92360]

When connecting the TN3270 Server and defining the PU with an LU-seed name, you must add a fifth character to the LU-seed T1 number. A fifth character is also required on the client- specified device name. Subsequent connections use the expected 4-character names. [CSCdi93113]
CSNA allows the VTAM XID3 to advertise a larger window size than the CSNA has been configured. With this fix, CSNA will enforce the VTAM XID3 to only advertise a window size that does not exceed the configured receive window. [CSCdj01070]
When a host sends a NULL RU CD after a write structure field write, the client keyboard is locked. [CSCdj02987]
The details of the TN3270 connection are not displayed with the following error message:

%TN3270S-1-NegRsp_NO_CORRELATOR: TN3270E Neg Resp no correlator found

: This error message makes it impossible to isolate the cause of the problem. A useful error message includes the remote IP address and LU details. [CSCdj03345]

Previously, the CIP microcode allocated 64 buffers for each CLAW device. The number of buffers per CLAW increased because of sudden burst of traffic and the large number of routes being passed to host-based TCP/IP stacks.

: Now, for each CLAW statement, the CIP microcode will retain the static 64 buffers that are 4096 in size. However, each 4096 byte buffer can be segmented into either 4 smaller buffers of 1024 bytes each or 8 smaller buffers of 512 bytes each. When buffers are allocated in this fashion, the 4096-byte buffer is reassembled after all of the smaller chunks are freed. [CSCdj03799]

Stress testing of a TN3270 generates the following message:

TN3270S-1-LU_NO_BUFFER: No buffer for lu: SNA PosRspToHost.
 
[CSCdj05600]

A CIP microcode reload may occur under the following circumstances:
- PU is not configured or shutdown
- TN3270 Server is shut down
- Channel virtual port is shut down on a TN3270 Server

: If a CIP microcode reload does occur, then check to see if the CIP TN3270 Server displayed the following message when the PU was configured:

%CIP3: OpenNMLogListenEndPoint failed:bind failed

: If this problem occurs, then it is likely that the situation described in CSCdj07773 occurred previously and the user should not perform a shutdown.
: The workaround is to reload the CIP microcode manually. [CSCdj07762]

Caveats for Version 22.16/Version 22.17 Modifications

This section describes possible unexpected behavior by Version 22.15. All the caveats listed in this section are resolved in Version 22.17. See Table 10 for the Cisco IOS software release that corresponds to the 22.17 microcode version.

Issuing a shut command on the TN3270 Server while there are active links can cause the CIP to reload spontaneously. The CIP reports error 9. [CSCdi81749]
Issuing a shut command on the CIP virtual interface when tn3270-server command is configured on the interface can lead to the CIP spontaneously reloading. The CIP reports error 35. [CSCdi87976]
The CIP will crash when either a no tn3270 or no pu command is issued within 10 seconds after a TN3270 E or non-E client disconnects. This defect causes the error message: CIP crash after issue no TN3270 command.

: This is a regression in the code Release 11.0(13.3)BT1(1.4) and 11.2(4.2) and was introduced by CSCdi90765.
: The workaround is to not issue a no TN3270 or the no pu command within 10 seconds of a client disconnecting. [CSCdi93241]

Some mainframe applications emit SNA ambiguous sequences (for example, CA7). The problem is a result of an SNA sequence sending an End Bracket and a Change Direction on the same RU. The CIP rejects the RU with a sensecode of 0x40090000. The CIP should permit End Bracket and Change Direction RUs.

: To work around this problem, consult the documentation for mainframe applications. Some of the applications have startup modification options that can disable End Bracket and Change Direction PUs. [CSCdj00195]

Caveats for Version 22.15/Version 22.16 Modifications

The Version 22.16 was never released. All of the modifications listed in version 22.16 are included in Version 22.17.

Caveats for Version 22.14/Version 22.15 Modifications

This section describes possible unexpected behavior by Version 22.14. All the caveats listed in this section are resolved in Version 22.15. See Table 10 for the Cisco IOS software release that corresponds to the 22.15 microcode version.

The show extended command may not function properly after inserting an IP card into a Cisco 75xx with CIP installed. The CIP card or router is not affected. [CSCdi58895]
When a TN3270 Server is operating with a configured primary and backup DLUS host, the DLUR-DLUS connection to the backup DLUS is not brought up until an unsuccessful attempt to rediscover the primary DLUS has been made. Depending on the number of timeouts in the APPN network (for example, in FEPs), this connection can take up to 15 minutes. Also, The CIP TN3270 DLUR should bring up a DLUR-DLUS session to the backup DLUS before it is needed. [CSCdi71259]
When running CSNA on the CIP, the CSNA channel device becomes inactive for over six minutes and causes all SNA connections over the subchannel to be disconnected.

This problem occurs under the following two possible failure scenarios:

The PCA-to-CIP communication will sometimes hang if the PCA adapter is configured with a path value that is not 0100 and no shutdown/shutdown interface commands are applied to the PCA interface. However, if a path value of 0100 and any other valid path value are defined on the PCA interface, the PCA-to-CIP communication will not hang.

: If the 0100 PCA logical path is not going to the established state as displayed by the show extended channel slot/port stats command and the CHPID is online, the customer may encounter the PCA-to-CIP communication problem. The workaround is to issue a shut command on the interface, issue a microcode reload command, and then issue a no shut command. [CSCdi74726]

This problem occurs under two possible failure scenarios.
- The PCA-to-CIP communication will sometimes hang if the PCA adapter is configured with a PATH value that is not 0100 and no shutdown/shutdown interface commands are applied to the PCA interface. However, if a PATH value of 0100 and any other valid PATH value is defined on the PCA interface, the PCA to CIP communication will not hang.
If the 0100 PCA logical path is not going to the ESTABLISHED state as displayed by the show extended channel slot/port stat command and the CHPID is online, the customer may have encountered this problem. The workaround is to issue a shut command on the interface, a microcode reload command, then a no shut command.
- Whenever a microcode reload command is performed while the PCA interface is not shutdown, the PCA to CIP communication might hang. Following a microcode reload command or no shut command, if the 0100 PCA logical path is not going to the ESTABLISHED state as displayed by the show extended channel slot/port stat command and the CHPID is online, the customer may experience this problem. If this problem was encountered, the following messages appear on subsequent attempts to reload the microcode:

%CIP0-0-MSG: %ADAPTER-0-DIAGFAIL: Port 0 failed the PCA Diagnostic Mode 1 diagnostic
%CIP0-0-MSG: %ADAPTER-0-DIAGDATA: Module Call: 0 0  Error ID: 0 FFFFFFFF 0 c

: The workaround is to OIR of the CIP with a 10-second delay between the removal and the insertion of the CIP card. [CSCdi77139]

The fix for CSCdi56069 introduced a bug in a rarely used code path. If the CIP has run out of message buffers in the past and a command is printing to a message port (typically the console port) and the user disconnects from that port, then the CIP may terminate with a fatal error dump. The fatal error occurs only when a large amount of output is sent to the CIP console (for example, when you issue a memory command at the CIP console). The error also happens when a large number of error messages are sent to the operating system. [CSCdi78520]
All CSNA SNA sessions are lost when the CIP fatal error dump (code 09) occurs. The problem occurs about once a day on a Cisco 7513 with an RSP2 running Cisco IOS Release 11.1.7 (image rsp-jv-mz.111-7.CA1.bin) and CIP microcode version 22.12. When this error occurs, the following error message is displayed:

CIP5-0-MSG: %DMA-0-BADFIFO: FIFO failure detected during transfer (40 7E90).

: [CSCdi79267]

In the show controller cbus command output, the CIP utilization data was upgraded to show more details. For each statistic, the value for a 1-minute sample period is shown with 5-minute and 60-minute sliding averages of the same statistic. The sliding averages are inaccurate, however. The 5-minute value can be too low by as much as 4 percentage points, and the 60-minute value can be too low by as much as 59 percentage points. [CSCdi79798]
IP packets sent to an offload device with a destination address that differs from the address of the offload device are forwarded to the host without going through the TCP/IP stack on the CIP. If the packets arrive at the CIP faster than the host can read them, they queue on the CIP until it runs out of resources. No more data can be sent to the host on that interface until the next microcode reload. This problem occurs if a large amount of data is sent and is more likely to happen with UDP than with TCP. [CSCdi80263]
The CIP may reload spontaneously when engaged in the hierarchical resetting of LUs that are TN3270 Server-based. Shutting down a PU, link, or external communication adapter can cause hierarchical resets.

: The workaround to properly shut down a host, ESCON channel, link or PU is to shut down the PUs that will be affected before shutting down the host resource. [CSCdi81150]

The CIP may fail after extended periods of use when there are not many offload sessions. [CSCdi82181]
When all the PUs in a TN3270 Server using a particular TCPIP IP/port listening pair are inactivated from the host, the statistics for that IP/port pair are reset. The statistics are reset for the show extended command output and the SNMP output in the TN3270 Server MIB.

: The workaround is to keep active at least one PU on the IP/port, which prevents the statistics from being reset. [CSCdi82513]

A TCP session may hang or UDP packets will be lost if the 16-bit sum of the TCP or UDP pseudo header equals 65535 (0xffff). Because the pseudo header is calculated from the source address, destination address, protocol, and protocol packet length once the problem tries to connect, that connection will eventually timeout because all of the packets will be dropped.

: View the output from the show extended channel slot/port tcp-stack and show extended channel slot/port udp-stack commands to view the errors. The variables that will be incremented for TCP and UDP will be TcpInErrors and UdpInErrors, respectively. [CSCdi83308]

The following error message may be displayed if there are multiple FTP sessions to the MVS host:

*Dec 30 14:54:21: %CIP0-3-MSG: %OFFL-3-ILLEN: Illegal byte count in offload data. 
 1599427375 specified, 20500 available.  xfer_element = 0
 
*Dec 30 14:54:21: %CIP0-3-MSG: x841BDA68
 
The FTP sessions, however, are unaffected at the application level.

: [CSCdi83886]

The TN3270 Server will send a value of 0 for end node CPs and DLUR user-defined transmission group characteristics. Instead of 0, the value should be the standard APPN default, which is 128. This applies to both real links and virtual ring nodes.

: Route selection problems can occur in networks with user-defined parameters in the transmission group characteristics. [CSCdi84886]

The CIP interface is reset when the router displays the following error message:

%CBUS-3-INITERR: Interface 65535, Error (8034), idb 00000000 0 rx_setup - cbus_init()

: [CSCdi85216]

The CSNA user can configure a maximum of 6000 LLC connections. To enable this feature, the user must use CIP microcode version cip21.14 (cip204.213), cip22.15 (cip206.171), or later. [CSCdi85623]
The session switch (DLUR) feature in the CIP TN3270 Server does not accept ACTLU for LUs with names that are the maximum length (8 bytes NETID plus 8 bytes LU name). The ACTLU is not acknowledged and the VTAM state is Pending Activate LU Response (PACTL).

: The workaround is to use shorter LU and NETID names. [CSCdi90243]

The fix for CSCdi26192 allowed the RP or RSP to retrieve the following pieces of information without having the CIP interfaces configured: adapter type, adapter hardware version, adapter software version, available and total SRAM, as well as available and total DRAM.

: If the customer has an operating system that includes CSCdi26192, but is using a microcode that does not include the fix for this problem, the following error messages will be displayed when issuing the show controller cbus command:

00:09:52: %CBUS-3-CCBCMDFAIL1: Controller 0, cmd (77 0x00000000) failed (0x8008)00:09:52: %CBUS-3-CCBCMDFAIL1: Controller 0, cmd (77 0x00000010) failed (0x8008)00:09:52: %CBUS-3-CCBCMDFAIL1: Controller 0, cmd (78 0x00000001) failed (0x8008)

: [CSCdi90794]

The number of reported maximum LUs is incorrect when queried by SNMP or when displayed in the show extended channel command in the TN3270 Server. This problem occurs when Dynamic Definition of Dependent LU (DDDLU) is disabled on one or more PUs.

: The workaround is to use Dynamic Definition of Dependent LU (DDDLU)-enabled PUs. [CSCdi92154]

Caveats for Version 22.12/Version 22.14 Modifications

This section describes possible unexpected behavior by Version 22.12. All the caveats listed in this section are resolved in Version 22.14. See Table 10 for the Cisco IOS software release that corresponds to the 22.14 microcode version.

In VTAM, the +r unbind dequeues the queued bind, but the Nfy Unav overtakes it and causes the bind to stay queued. This exposes a security hole in the session manager. The problem occurs when the user completes the following steps:

Step 1 Signs on (userid and password) to the session manager.

Step 2 Selects a Customer Information Control System (CICS) application. Clsdst/pass occurs to CICS application. Simlogon happens to session manager.

Step 3 Enters a CICS transaction.

Step 4 Releases the session from a CICS master terminal. The Rumba V4.1 TN3270 client then returns the message "requested LU unavailable."

Step 5 User disconnects from the Rumba client and reconnects, bypassing the entry validation screen. User is sent directly to the application selection menu.

: The existing sequence is:

    Host              Tn3270            Client
 
           <--------------------------- logoff
    unbind ---------->
                       disc ---------->
           <--------- +r unbind
           <--------- Nfy Unav

: This problem will be fixed in a future release. [CSCdi58780]

Historically, both the default and maximum values for the TN3270 Server maximum-lus parameter were set at 20000. Because of licensing issues, the default value will be set to 2100; the maximum value will become 32000. License reminders will be displayed when the default is exceeded, and warning messages will be displayed when the configured maximum is approached. [CSCdi62250]
In the SNA-NAU-MIB, snaLuOperName is not displayed correctly. [CSCdi69052]
CSNA users occasionally receive a CTA-0-INACTIVE message with an incorrect timeout value. The problem can result in the CSNA subchannel being reset when the subchannel is idle for more than 9 seconds. [CSCdi69282]
An LU2 bind was accepted for printer client. A LU2 and LU3 bind was accepted for screen client. This behavior was incorrect. A fix was implemented so the bind is now rejected and the client disconnected. [CSCdi70482]
This bug was introduced by CSCdi38483. IBM's offload implementation issues a never-ending receive on all RAW and datagram sockets. If packets come in to these sockets faster than the host can read them, the sockets start filling memory on the CIP. CSCdi38483 introduced a throttling mechanism for these sockets. However, it did not address the problem of closing a socket that was paused (throttled). The result is a fatal error caused by the offload code trying to resume a paused receive operation on a socket that no longer exists.

: This problem is corrected by making sure the socket control block for a paused socket remains after the socket closes until the resume operation is processed. [CSCdi72208]

When running the CIP TN3270 Server, no PLU sessions can be queued for statically defined until the first downstream TN3270 client connects to that LU. This may interfere with initialization of host-based print software such as RSCS, VPS, and so on. This reason for this is that the SLU is INHIBITED at ACTLU time, and goes to DISABLED or ENABLED state only during or after the first TN3270 client connection to the LU. The TN3270 Server should initially place the SLU in DISABLED state (not INHIBITED).

: The workaround is to connect the downstream print clients before directing the host print software to queue sessions to the affected LUs. [CSCdi73134]

If the Distributed Director feature is used with the TN3270 Server, it occasionally locks up the TN3270 Server. This results in new TN3270 connections not being accepted and previous connections not proceeding well. The workaround is to reload the CIP microcode. [CSCdi74255]
When running CSNA on the CIP, the CSNA channel device becomes inactive for over six minutes and causes all SNA connections over the subchannel to be disconnected.

This problem occurs under the following two possible failure scenarios:

The PCA-to-CIP communication will sometimes hang if the PCA adapter is configured with a path value that is not 0100 and no shutdown/shutdown interface commands are applied to the PCA interface. However, if a path value of 0100 and any other valid path value are defined on the PCA interface, the PCA-to-CIP communication will not hang.

: If the 0100 PCA logical path is not going to the established state as displayed by the show extended channel slot/port stats command and the CHPID is online, the customer may encounter the PCA-to-CIP communication problem. The workaround is to issue a shut command on the interface, issue a microcode reload command, and then issue a no shut command. [CSCdi74726]

When a host sends a NULL RU with EB, the client may lock up because the server did not clear the keyboard restore bit. In the WSF, extra keyboard restore frames can be sent to the clients. [CSCdi74900]
The RFC 1646 printer is not supported. [CSCdi75065]
When using the TN3270 Server DLUR feature and running the dependent LU sessions through an IBM 3746 as an intermediate network node, the IBM 3746 sometimes rejects the bind response from the server. [CSCdi75453]
Sometimes while running the TN3270 Server, the CIP will reload with fatal error 32.

: [CSCdi75996]

When running TN3270E mode, the response to the host may come in too early (it is not the true response from the client). [CSCdi76545]
When running an undocumented CIP console command tracing TN3270 Server actions, the CIP reloads. This happens only when TN3270 sessions are connecting to the router. The failure is intermittent. [CSCdi76558]
When running the TN3270 Server on the CIP, the CIP leaks DRAM memory. over time. This leaking can cause crashes or hangs because of the lack of memory on the CIP.

: The memory leak is slow over a period of days when processing 4000 TN3270 connections per day. The workaround is to reload the CIP microcode periodically (for example, once a week).
: Inspect the output of show controller cbus daily and look at the amount of DRAM available to the CIP. [CSCdi76764]

Occasionally, snmp and show command report unusually large response times for host and TCP side in the TN3270 Server.

: If TN3270 printer sessions are not being run, this problem will not happen. This problem does not affect operation of TN3270 sessions or the TN3270 Server itself. [CSCdi76786]

This problem occurs under two possible failure scenarios.
- The PCA-to-CIP communication will sometimes hang if the PCA adapter is configured with a PATH value that is not 0100 and no shutdown/shutdown interface commands are applied to the PCA interface. However, if a PATH value of 0100 and any other valid PATH value is defined on the PCA interface, the PCA to CIP communication will not hang.
If the 0100 PCA logical path is not going to the ESTABLISHED state as displayed by the show extended channel slot/port stat command and the CHPID is online, the customer may have encountered this problem. The workaround is to issue a shut command on the interface, a microcode reload command, then a no shut command.
- Whenever a microcode reload command is performed while the PCA interface is not shutdown, the PCA to CIP communication might hang. Following a microcode reload command or no shut command, if the 0100 PCA logical path is not going to the ESTABLISHED state as displayed by the show extended channel slot/port stat command and the CHPID is online, the customer may experience this problem. If this problem was encountered, the following messages appear on subsequent attempts to reload the microcode:

%CIP0-0-MSG: %ADAPTER-0-DIAGFAIL: Port 0 failed the PCA Diagnostic Mode 1 diagnostic
%CIP0-0-MSG: %ADAPTER-0-DIAGDATA: Module Call: 0 0  Error ID: 0 FFFFFFFF 0 c

: The workaround is to OIR of the CIP with a 10-second delay between the removal and the insertion of the CIP card. [CSCdi77139]

SNMP queries sent to the CIP or show extended channel commands that use IPC can corrupt data for offload sessions or data for ind$file transfers.

: If SNMP requests and show extended channel commands are not issued, there is no problem. [CSCdi77480]

This problem only affects the output of in_use global pages while using the mbstat command on the CIP console. It causes no functional problems. [CSCdi77481]
When clients acting as an IBM 3270 Model 3, 4 or 5 connect to the Information Management System (IMS) through a CIP TN3270 Server, the output screens may be corrupted.

: IMS does not perform a read partition query to determine the terminal's screen size characteristics. If IMS receives a LOGMODE message with a primary screen size of 24 x 80 (MOD2) and an alternate screen size of 27x132 (MODS), IMS sets the bind to both primary and alternate screen size of 27x132 (MOD 5). TN3270 Server does a +RSP to the bind, but the TN3270 client does not know that the primary screen size has changed. The client expects a primary screen size of MOD2, and the application (IMS) has changed the primary screen size to MOD5.
: When IMS sends an ERASE WRITE message, it expects the screen to be 27 x 132. The client expects the screen to be 24 x 80 and a garbled screen results.
: This problem affects all non-TN3270E clients. Many TN3270E clients are also affected because they ignore the bind data.
: The TN3270 Server must detect the discrepancy and translate between ERASE WRITE and ERASE WRITE ALTERNATE messages. [CSCdi77802]

TN3270 Server direct PUs send XID3s with no CP name vector. While this is legal (back-level LEN node behavior), some VTAMs reject it with sense code 089500xx. The PUs remain in the XID state. [CSCdi78349]
The fix for CSCdi43140 introduced a memory leak in the offload support. Whenever offload quits (shut, no offload, interface reset) it does not free all its memory. The only workaround is to occasionally reload the microcode. [CSCdi78569]
In the show controller cbus command output, the CIP utilization data was upgraded to show more details. For each statistic, the value for a 1-minute sample period is shown with 5-minute and 60-minute sliding averages of the same statistic. The sliding averages are inaccurate, however. The 5-minute value can be too low by as much as 4 percentage points, and the 60-minute value can be too low by as much as 59 percentage points. [CSCdi79798]
If a CIP TN3270 Server PU is varied INACT then ACT at the host, the server might try to reconnect the PU before the ACT. When this happens, the host replies with an XID3 carrying subvector 22. Because this generates host console messages, the server does not retry the connection for two minutes.

: The workaround is to recycle the PU using INACT,TYPE=REACT instead of INACT followed by ACT. [CSCdi79815]

Occasionally when the user hits the PF key, the keyboard hangs. This is a regression error introduced by CSCdi74900. [CSCdi80141]
IP packets sent to an offload device with a destination address that differs from the address of the offload device are forwarded to the host without going through the TCP/IP stack on the CIP. If the packets arrive at the CIP faster than the host can read them, they queue on the CIP until it runs out of resources. No more data can be sent to the host on that interface until the next microcode reload. This problem occurs if a large amount of data is sent and is more likely to happen with UDP than with TCP. [CSCdi80263]
Because of incorrect configuration from host, VTAM can send SSCP-LU SNA character string data to a client that requires 3270DS. The TN3270 client will display garbled output or reject the connection.

: Similarly, the user's logon will be sent in 3270DS format, and the host must be configured to expect that. If the USS10 sent was in the wrong format, the logon will not be understood.
: The CIP TN3270 Server should detect the problem and do what it can to convert the datastreams. Users often do not realize they must configure the host to match the format. [CSCdi82008]

Caveats for Version 22.10/Version 22.12 Modifications

This section describes possible unexpected behavior by Version 22.10. All the caveats listed in this section are resolved in Version 22.12. See Table 10 for the Cisco IOS software release that corresponds to the 22.12 microcode version.

A TN3270 session that is connected but not immediately bound gets disconnected 2 1/2 minutes later. Additionally, the following message appears on the router console:

%CIP2-1-MSG: %TN3270S-1-NO_BIND_REQ_RCVD: No BIND REQ received on LU...

: The LU affected is not disabled; a VTAM display of the LU shows that it is ENABLED.
: Proper operation would allow the LU (printer or screen) to remain unbound until the inactivity timer triggers or the connection is shut down. In any case, proper operation dictates that a disconnected TN3270 session is reflected with the LU being in a DISABLED or INHIBITED state. [CSCdi70475]

For users who are running CSNA and Offload concurrently, Offload can consume all the free buffer list (FBL) internal resources that CSNA needs in order to complete the channel WRITE operation. The resource consumption often causes CSNA to detect the subchannel idle condition and display following message:

%CTA-0-INACTIVE: PA0 CTA 0110-06 reset after being inactive for 180 seconds

: [CSCdi71177]

The CIP card stops operation and reloads when a shut tn3270-server or a no tn3270-server command is issued at the CIP virtual interface. This reload occurs intermittently when Dependent LU Requester (DLUR) links have been defined for the TN3270 Server feature.

: A workaround for this problem is to go to the DLUR configuration mode under the TN3270 Server configuration mode of the virtual interface and issue no lsap commands to deconfigure the adapter attachment points for DLUR before deactivating the TN3270 Server. Be sure to record the current link and lsap command contents, as these values must be reconfigured when the TN3270 Server is brought up again. [CSCdi71216]

For CSNA, there is a buffer leak problem associated with initiating an outgoing call. The buffer leak may result in locking up the subchannel or displaying the following message:

PA1 CTA c010-d1 reset after being inactive for 180 seconds

: [CSCdi73007]

CSCdi39888 introduced a serious memory leak in Offload. CIP microcode that contains the fix for CSCdi39888, but not the fix for CSCdi74628, should not be used with Offload.

: Host applications that issues accept requests to the Offload devices can cause memory leaks of roughly 3 KB for every connection accepted. The Telnet Server application in MVS TCP/IP V3.1 is one example of such an application. Because of the memory leak, eventually the Offload application can no longer find enough memory to create new sockets and prints out the following error message:

%OFFL-3-REJSOCK: Not enough memory to handle new socket. <xxx> sockets open.

: The TCPIP job log on the host will show the following error message:

EZB5141E Unexpected result from offload device ... ... 
EZB5153I        trgcls hi-order accept... 
EZB5162I     Data: 
EZB5062I 000000:00000001 FFFFFFFF FFFFFFFF 0000000C

: This message indicates that the application on the host will no longer accept any incoming connections on that socket. For the Telnet Server, TCPIP must be recycled to allow clients to connect to the host again. Recycle other applications to correct the problem on the host.
: To correct the problem on the CIP, the Offload device must be unconfigured and reconfigured or the channel interface must be bounced (shut down and then restarted) with a shut command followed by a no shut command.
: The only workaround is to occasionally bounce the Offload devices on the CIP. [CSCdi74628]

The fix for CSCdi56069 introduced a bug in a rarely used code path. If the CIP runs out of message buffers, it may encounter a bad instruction in this code path and terminate with a fatal error dump. The fatal error occurs only when a large amount of output is sent to the CIP console (for example, when you issue a memory command at the CIP console). The error also happens when many error messages are sent to the router operating system. [CSCdi74911]
All data from the CIP to the Switch Processor (SP) or RSP is dropped and counted as an "ignore" in the show interface display. The problem potentially affects any feature that the CIP supports for supported releases. A clear indication of this problem is when the value for "rxcurr" is greater than 65000 in the show controller cbus display for the CIP interface. [CSCdi75138]
The CIP may fail under certain conditions when multiple clients are bound to the same socket, but not fully bound. Running multiple copies of an FTP server is an example of this condition. This condition can also occur while doing multiple concurrent FTP GETS, which typically requires some connections to terminate abnormally so that the FTP sessions are taken down in a different order than they were created. [CSCdi75396]

Caveats for Version 22.7/Version 22.10 Modifications

This section describes possible unexpected behavior by Version 22.7. All the caveats listed in this section are resolved in Version 22.10. See Table 10 for the Cisco IOS software release that corresponds to the 22.10 microcode version.

Historically, both the default and maximum values for the TN3270 Server maximum-lus parameter were set at 20000. Because of licensing issues, the default value will be set to 2100; the maximum value will become 32000. License reminders will be displayed when the default is exceeded, and warning messages will be displayed when the configured maximum is approached. [CSCdi62250]
Under some circumstances, static TN3270 LUs cannot be selected by name by the client. The LU is active at the host and at the CIP, but attempts to select it are refused as though it were unknown.

: The more static LUs in the network, the higher the chance that any given LU is affected. [CSCdi67583]

For CSNA users running Cisco IOS Releases 11.0(11) and 11.1(6), download one or both of the following microcode images from Cisco Connection Online.

For Release 11.0(11):

cip21-10 for CIP 1
cipp21-10 for CIP 2

For Release 11.1(6):

cip22-10 for CIP 1
cipp22-10 for CIP 2

There is a potentially catastrophic problem with the CSNA feature in the microcode bundled with Cisco IOS Release11.0(11). The problem can occur with SNA path information units (PIUs) 4025 bytes or larger destined for the channel. [CSCdi69773]

Caveats for Version 22.6/Version 22.7 Modifications

This section describes possible unexpected behavior by Version 22.6. All the caveats listed in this section are resolved in Version 22.7. See Table 10 for the Cisco IOS software release that corresponds to the 22.7 microcode version.

The CSNA fails to detect the host halted via the "ZET NET, CANCEL" command. (Included with the corrections for this problem is an enhancement that speeds up the connection termination process so it will be more responsive to the vary active XCA major node command.) [CSCdi53187]
The direct memory access (DMA) controller on the CIP which transfers packets between MEMD (on the SP or RSP) and memory on the CIP. The resulting error message looks like one of the two following examples:

DMA-0-BADFIFO: FIFO failure detected during transfer (4x 0100) 
DMA-0-BADFIFO: FIFO failure detected during transfer (4x 0001)

: The numbers 0100 or 0001 in the parentheses indicate that the error is from a different type of unexpected behavior. IP datagram connections will drop packets that encounter the transfer problem. Only packets coming from the mainframe are affected. These dropped packets will be retransmitted by higher level protocols (for example, TCP) and the new packets will not run into the same problem due to different IP sequence numbers in the IP header.
: Offload connections will drop outgoing packets (packets from the mainframe) that encounter the DMA transfer problem. Incoming packets will be dropped due to incorrect TCP or UDP checksums. Again, higher-level protocols will retransmit the packet. CSNA will be affected in much the same way as IP datagram. The major difference is that there is nothing equivalent to an IP sequence number in an LLC2 packet, so the retransmitted packets could encounter the DMA transfer problem. If enough unsuccessful retransmissions occur, the LLC2 session will drop. However, it is unlikely that this problem will occur because there are numerous conditions that must be met. [CSCdi54732]

The CIP halts if the router switches a packet to the CIP for the virtual port adapter (interface channel slot/2) using the wrong virtual circuit number the CIP crashes. Before the fatal error dump you will see the following error message:

%CIP5-3-MSG: %CONFIG-3-WRONGINT: VCN 0(0000) not for port adapter 2

: In addition to preventing the unexpected halt, the fix in version 22.7 also adds code to print out the beginning of the bad packet. This allows to find out why the VCN was wrong. [CSCdi61532]

On a CIP 2 (hardware revision 5.x) with CSNA and TCP Offload both in use, TCP sessions could randomly drop out with the remote client appearing to have requested disconnect. [CSCdi63044]
Occasionally, if the CIP receives a packet greater than 4 k from RP/RSP, CIP may stop functioning properly and eventually may crash with fatal errors. The following message is an indication that the problem is encountered:

CLAW-6-TOOBIG: 4352 byte IP datagram exceeds CLAW MTU for device

: The workaround is to reload the router. [CSCdi64874]

If you are running IP datagram, and a number of Selective Resets are issued to a CLAW connection, that CLAW connection may hang. One sign that this problem is occurring would be if the CLAW connection state is "Y," but every packet from the router to the CIP is dropped as viewed by the Read Block Dropped counter in the output from the show extended channel slot/port stat command. A microcode reload is required to clear the problem. [CSCdi65099]
When more the one device is configured on a CIP interface, a potential exists for those devices to stop accepting data from the mainframe. For CLAW devices, this only prevents data from being received from the host. For CSNA devices, this would prevent traffic from flowing in or out of the host. A microcode reload is required to recover from the problem. [CSCdi66108]
CSNA and Offload are not supported features if the CIP hardware revision is lower than Version 4.4. The fix for microcode version 22.7 adds a warning if these features are configured on down-level hardware. [CSCdi66745]
When using a version of CIP microcode that contains the fix for CSCdi56069 (cip20-9, cipp20-9, cip204-80, cipp204-80, cip206-70) and running in an RASP platform, DBUS-INTERRs could result while entering commands into the CIP console. [CSCdi67549]

Caveats for Version 22.3/Version 22.6 Modifications

This section describes possible unexpected behavior by Version 22.3. All the caveats listed in this section are resolved in Version 22.5. See Table 10 for the Cisco IOS software release that corresponds to the 22.6 microcode version.

While running CSNA and in the process of bringing up a session, or while in data transfer phases, VTAM deactivates all active sessions with following error message:

INOP RECEIVED FOR XXXXXXXX code = 02

: [CSCdi64229]

The CIP was designed to run two channel adapters with only 2 MB of DRAM when running in IP datagram mode. When running 32 CLAW devices with RIP, packets would be dropped even though additional DRAM was available to buffer packets until the mainframe could receive them. The fix for microcode version 22.6 allows CIPs with more than 2 MB of DRAM to make use of the additional memory when running IP datagram mode. [CSCdi54042]
This fix addresses unexpected behavior when running CSNA, which could potentially cause session failure, BADFIFO error messages, and other side effects. [CSCdi61131]
Under certain conditions, the FTP server on VM or MVS stops functioning if the offload device returns an invalid return code to a particular socket request to receive data. This return code also generates a traceback in the TCPIP logs for TCPIP for VM and MVS. The offload device no longer returns this invalid return code. [CSCdi61870]

Caveats for Version 22.0/Version 22.3 Modifications

This section describes possible unexpected behavior by Version 22.0. All the caveats listed in this section are resolved in Version 22.3. See Table 10 for the Cisco IOS software release that corresponds to the 22.3 microcode version.

Hub terminals manufactured by HOB expect a Receive Ready (RR) to be sent after the SABME is sent. This is not required by the 802.2 standard. After the HOB sends a SABME to the CIP LLC stack, the CIP LLC stack should respond with an RR and then assume that the terminal is in normal transfer mode. [CSCdi45083]
The Offload read and write tasks are created with too little stack space. Under certain conditions, typically when several hundred sessions are established, a stack overflow can occur, which usually leads to a fatal error dump. The error code in this dump can be almost anything, with 32 and 35 being most likely. If you are running Offload with microcode versions cip21-3, cip11-4, cip22-1, or earlier, you should upgrade to at least cip21-4 (Cisco IOS Release 11.0(7) or later) or cip22-3 (Cisco IOS Release 11.1(2.4) or later). [CSCdi48357]
When running CSNA, during large bursts of LLC, type 1 traffic from VTAM (many sessions configured for callout) an automatic reload of the CIP microcode may occur with the following message displayed: SSI_ASSERT failure in../cta/cta_mbuf.c @ 287 ... [CSCdi48855]
When running MVS V=R in a VM/XA guest machine with a PCA, the mainframe channel will generate an interface disconnect in the middle of command chaining when it reaches an invalid CCW. If multiple devices are active on the PCA, this may result in an SCB_CHAIN error. The only work around for the SCB_CHAIN error is not to run in this configuration. [CSCdi49057]
When running CSNA, if XCA major nodes are cycled inactive/active many times without reloading the CIP microcode, a CCA error message TOOMANY may be seen, and channel operation is paused without completing the current channel program. Depending on traffic levels, operation may or may not resume. If not, the CIP microcode must be reloaded. [CSCdi51452]
Restarting TCPIP on the mainframe while data is moving through an Offload connection can cause the CIP to halt unexpectedly. The result is a fatal error dump. This dump must be sent to development engineering for analysis. The problem can be avoided by shutting down TCPIP, which causes all open sockets/connections to be closed, before restarting it. [CSCdi51859]
With the CSNA feature, if an XCA major node is inactivated or VTAM is shut down while connections are active and traffic is flowing to VTAM, the CIP may pause indefinitely. If this pause occurs, the CIP microcode must be reloaded. [CSCdi53138]

CIP Microcode Release cip21 Caveats and Modifications

The following sections describe the caveats to current CIP microcode versions and the modifications made in current CIP microcode versions for cip21 microcode. The caveats listed apply to only the most serious problems. See Table 10 for the Cisco IOS software releases supported by cip21 microcode.

Caveats for Version 21.3/Version 22.0 Modifications

CIP Microcode Version 22.0 was the first version specifically built for unbundled microcode support under Cisco IOS Release 11.1. Because CIP Microcode Version 22.0 was based on Version 21.3, modifications made in Version 21.3 are listed in this section. See Table 10 for the Cisco IOS software release that corresponds to the 22.0 microcode version.

This fix handles the VTAM flow request and eliminates the following message from being displayed: CSNA code does not recognize 0x0d50, Flow Request from VTAM [CSCdi45035]
If the host sends a CLAW disconnect message to a link that has already been disconnected and that CLAW connection has a different link that is connected, the CIP will cause the static route for the CLAW connection to be removed. Version 2.1 of Interlink and IBM TCPIP V2 behave in this manner.

: The router will show that the Claw connection, as viewed by show extended channel slot/port statistics is connected, but the static route will be removed. [CSCdi45752]

When status is pending on initial connection, the pending status is not flushed. This resulted in owed status being suppressed. On CSNA connections this causes data transfer to stop, and VTAM or the Missing Interrupt Handler detects an operation as taking too long. [CSCdi46037]
This fix only applies to CSNA users who are using host backup configuration. If the user has duplicate VTAMs, for backup purposes, the user can configure two or more logical LAN adaptors (ADAPNO) with same MAC address on different internal LANs. When one of the VTAMs is brought down, similar to varying off the XCA major node, or one of the VTAMs is in trouble, all end-stations that previously connected to the problem VTAM can then reconnect to the backup VTAM.

: The subroutine that handles the reconnect logic requires this fix. [CSCdi47267]

CIP-Related Caveats for Cisco IOS Releases

For a complete list of caveats against the Cisco IOS Releases, use Cisco Connection Documentation or access Cisco Connection Online as described in the section "Cisco Connection Online" later in this document. You can also refer to the following publications which are available on Cisco Connection Documentation:

Release Notes for Cisco IOS Release 11.1 (Document Number 78-2886-xx)
Release Notes for Cisco IOS Release 11.2 (Document Number 78-3648-01-xx)
Release Notes for Cisco IOS Release 11.2BC (Document Number 78-4694-xx)
Release Notes for Cisco IOS Release 11.3 (Document Number 78-4998-xx)
Release Notes for Cisco 7000 Family for Cisco IOS Release 11.3T (Document Number 78-5015-xx)
Release Notes for Cisco IOS Release 12.0 (Document Number 78-6035-xx)
Release Notes for Cisco 7000 Family for Cisco IOS Release 12.0T (Document Number 78-6055-xx)
Release Notes for Cisco IOS Release 12.1 (Document Number 78-10724-xx)
Release Notes for Cisco 7000 Family for Cisco IOS Release 12.1T (Document Number 78-10811-xx)

CIP and Processor Module ROM Monitor Recommendations

CIP and processor module (RP, RSP, and RSP7000) ROM monitor (system bootstrap) versions and system software images are typically independent of each other; however, the CIP hardware version has minimum recommended requirements for each Cisco IOS Release and CIP Microcode Version as listed in Table 11. Other microcode versions can be used, but only when recommended by technical support personnel. Table 12 identifies the processor module monitor versions.

Note For Cisco IOS Release 11.2BC, the CIP card is supported only on the Cisco 7000 router with RSP7000 and on the Cisco 7500 series routers.

Use the show diag EXEC command to display the CIP hardware version. The original CIP card is identified as version 4.x. The CIP2 card is identified as version 5.x.
Table 11: CIP Hardware, Cisco IOS Release, and CIP Microcode Compatibility

CIP Hardware Version Minimum Cisco IOS Release Required Minimum CIP Microcode Version Recommended

CIP 4.1

10.2(4.6)

cip10-4

CIP 4.2

10.3(5.1)

cip10-7

10.3(8.5)

cip20-5

10.3(6.2)

rsp_cip20-2

CIP 4.4¹

20.2(10.2) or later

cip10-4

cip20-4

10.3(7.5)

cip10-9

10.3(8.5)

cip20-5

10.3(7.5)

rsp_cip20-3

11.0(3.5)²

cip11-4

11.0(4.5), 11.1(1)

cip21-3

11.0(3.5)

rsp_cip21-2

11.1 any version

cip22-x

11.2 any version

cip22-x

CIP2 5.x

10.2(3), 10.3(13)

cipp20-8

11.0(10)

cipp21-7

11.1(5)

cip22-6

11.1(6)

cip22-7

11.1(7), 11.2(1), 11.2(2)

cip22-10

11.1(8), 11.2(3), 11.2(4)

cip22-12

11.1(9)

cip22-14

11.1(10)

cip22-15

11.2(5)

cip22-17

11.1(11)

cip22-18

11.2(6)

cip22-19

11.1(12), 11.2(7)

cip22-20

11.1(13), 11.2(8)

cip22-21

11.1(14), 11.2(9)

cip22-22

11.1(15)

cip22-23

11.1(16), 11.2(10)

cip22-25

11.1(17), 11.2(11)

cip22-26

11.1(18), 11.2(12), 11.2(13)

cip22-27

11.1(20), 11.2(14)

cip22-30

11.2(15)

cip22-31

11.1(22), 11.2(16)

cip22-32

11.1(24), 11.2(17)

cip22-34

11.2(18)

cip22-35

11.2(19)

cip22-38

11.2(20)

cip22-39

11.2(21)

cip22-40

11.2(22)

cip22-41

11.2(23)

cip22-43

11.2(8)BC

cip24-0

11.2(9)BC

cip24-1

11.2(10)BC

cip24-2

11.2(11)BC

cip24-3

11.2(12)BC

cip24-4

11.2(13)BC

cip24-5

11.2(14)BC

cip24-6

11.2(15)BC

cip24-7

11.2(16)BC

cip24-8

11.2(17)BC

cip24-9

11.2(18)BC

cip24-11

11.2(19)BC

cip24-13

11.2(20)BC

cip24-14

11.2(21)BC

cip24-15

11.2(22)BC

cip24-16

11.2(23)BC

cip24-18

11.3(1)

cip25-3

11.3(2)

cip25-6

11.3(3), 11.3(4)

cip25-7

11.3(5), 11.3(6)

cip25-8

11.3(7)

cip25-9

11.3(8)

cip25-10

11.3(9)

cip25-11

11.3(10)

cip25-12

11.3(11)

cip25-13

11.3(3)T

cip26-0

11.3(4)T

cip26-1

11.3(5)T, 11.3(6)T

cip26-2

11.3(7)T, 12.0(1), 12.0(2), 12.0(1)T, 12.0(2)T

cip26-4

11.3(8)T, 12.0(3)

cip26-5

11.3(9)T, 12.0(4)

cip26-7

11.3(10)T, 11.3(11)T, 12.0(5)

cip26-8

12.0(6), 12.0(7)

cip26-9

12.0(8)

cip26-10

12.0(9)

cip26-11

12.0(10)

cip26-12

12.0(11)

cip26-13

12.0(12)

cip26-15

12.0(3)T

cip27-0

12.0(4)T

cip27-1

12.0(5)T

cip27-2

12.0(7)T

cip27-4

12.1(1), 12.1(1)T

cip27-6

12.1(2), 12.1(2)T

cip27-7

12.1(3), 12.1(3)T

cip27-8

¹The Cisco 7500 series requires CIP hardware revision 4.4 or later.
²Cisco IOS Release 11.0 and later requires a CIP hardware revision 4.4 or later.

CIP Hardware Version	Minimum Cisco IOS Release Required	Minimum CIP Microcode Version Recommended
CIP 4.1	10.2(4.6)	cip10-4
CIP 4.2	10.3(5.1)	cip10-7
	10.3(8.5)	cip20-5
	10.3(6.2)	rsp_cip20-2
CIP 4.4¹	20.2(10.2) or later	cip10-4
		cip20-4
	10.3(7.5)	cip10-9
	10.3(8.5)	cip20-5
	10.3(7.5)	rsp_cip20-3
	11.0(3.5)²	cip11-4
	11.0(4.5), 11.1(1)	cip21-3
	11.0(3.5)	rsp_cip21-2
	11.1 any version	cip22-x
	11.2 any version	cip22-x
CIP2 5.x	10.2(3), 10.3(13)	cipp20-8
	11.0(10)	cipp21-7
	11.1(5)	cip22-6
	11.1(6)	cip22-7
	11.1(7), 11.2(1), 11.2(2)	cip22-10
	11.1(8), 11.2(3), 11.2(4)	cip22-12
	11.1(9)	cip22-14
	11.1(10)	cip22-15
	11.2(5)	cip22-17
	11.1(11)	cip22-18
	11.2(6)	cip22-19
	11.1(12), 11.2(7)	cip22-20
	11.1(13), 11.2(8)	cip22-21
	11.1(14), 11.2(9)	cip22-22
	11.1(15)	cip22-23
	11.1(16), 11.2(10)	cip22-25
	11.1(17), 11.2(11)	cip22-26
	11.1(18), 11.2(12), 11.2(13)	cip22-27
	11.1(20), 11.2(14)	cip22-30
	11.2(15)	cip22-31
	11.1(22), 11.2(16)	cip22-32
	11.1(24), 11.2(17)	cip22-34
	11.2(18)	cip22-35
	11.2(19)	cip22-38
	11.2(20)	cip22-39
	11.2(21)	cip22-40
	11.2(22)	cip22-41
	11.2(23)	cip22-43
	11.2(8)BC	cip24-0
	11.2(9)BC	cip24-1
	11.2(10)BC	cip24-2
	11.2(11)BC	cip24-3
	11.2(12)BC	cip24-4
	11.2(13)BC	cip24-5
	11.2(14)BC	cip24-6
	11.2(15)BC	cip24-7
	11.2(16)BC	cip24-8
	11.2(17)BC	cip24-9
	11.2(18)BC	cip24-11
	11.2(19)BC	cip24-13
	11.2(20)BC	cip24-14
	11.2(21)BC	cip24-15
	11.2(22)BC	cip24-16
	11.2(23)BC	cip24-18
	11.3(1)	cip25-3
	11.3(2)	cip25-6
	11.3(3), 11.3(4)	cip25-7
	11.3(5), 11.3(6)	cip25-8
	11.3(7)	cip25-9
	11.3(8)	cip25-10
	11.3(9)	cip25-11
	11.3(10)	cip25-12
	11.3(11)	cip25-13
	11.3(3)T	cip26-0
	11.3(4)T	cip26-1
	11.3(5)T, 11.3(6)T	cip26-2
	11.3(7)T, 12.0(1), 12.0(2), 12.0(1)T, 12.0(2)T	cip26-4
	11.3(8)T, 12.0(3)	cip26-5
	11.3(9)T, 12.0(4)	cip26-7
	11.3(10)T, 11.3(11)T, 12.0(5)	cip26-8
	12.0(6), 12.0(7)	cip26-9
	12.0(8)	cip26-10
	12.0(9)	cip26-11
	12.0(10)	cip26-12
	12.0(11)	cip26-13
	12.0(12)	cip26-15
	12.0(3)T	cip27-0
	12.0(4)T	cip27-1
	12.0(5)T	cip27-2
	12.0(7)T	cip27-4
	12.1(1), 12.1(1)T	cip27-6
	12.1(2), 12.1(2)T	cip27-7
	12.1(3), 12.1(3)T	cip27-8

Platform and Processor	CIP Boot ROM Version	Processor ROM Monitor Version
Cisco 7000 family router¹ with a Route Processor (RP), 7000 Series Route Switch Processor (RSP7000), RSP1, and RSP2	Version 1.6 or later (required)	System Bootstrap Version 11.0 or later

Table 12: Minimum Recommended CIP Boot ROM Versions

Platform and Processor CIP Boot ROM Version Processor ROM Monitor Version

Cisco 7000 family router¹ with a Route Processor (RP), 7000 Series Route Switch Processor (RSP7000), RSP1, and RSP2

Version 1.6 or later (required)

System Bootstrap Version 11.0 or later

¹The Cisco 7000 family routers include the Cisco 7000, Cisco 7010, Cisco 7505, Cisco 7507, and Cisco 7513.

CIP and RP/RSP DRAM Requirements

For the Cisco routers to take advantage of the Cisco IOS Release Software CIP features, you might need to upgrade code, main system, or CIP memory. For specific Cisco IOS-related memory requirements, refer to the Release Notes for Cisco IOS Release 11.x or the Release Notes for Cisco IOS Release 12.x publications, which are available on Cisco Connection Online.

CIP Microcode Upgrade Overview

Following is an overview of how to upgrade unbundled CIP microcode (CIP Microcode Version 22.0 and later) for the Cisco 7000 family routers.

Note In the following procedure, a Cisco IOS Release 11.1 (or later) image is booted before the CIP microcode image is copied to Flash memory.

For CIP microcode images that were shipped on floppy disks or were obtained from CCO, do the following:

Step 1 Upload the CIP microcode image (and the Cisco IOS image if not on ROM) from the floppy disks or from CCO to a TFTP server.

Step 2 From the running configuration, remove any microcode cip configuration commands that specify a CIP microcode image.

Step 3 Save your running configuration to a TFTP server or Flash memory.

Note If you have a Cisco 7000 series router and plan to install new software ROM with Cisco IOS software, skip Steps 4 and 5 and turn off power to your router. Install the new ROMs, then proceed to Step 6.

Step 4 Before you copy tftp you need to rename the microcode you downloaded from CIP22-3.BIN to CIP22-3. If you do not rename the microcode image, the RSP does not find the kernel because it will be named CIP22-3.BIN_kernel... instead of CIP22-3_kernel....

Step 5 Download the Cisco IOS Release software image to Flash memory.

Step 6 Configure the router to boot from the Flash memory where the Cisco IOS Release software image resides.

Step 7 Boot the Cisco IOS Release software image.

Note The router must be running Cisco IOS Release software before copying the CIP image to Flash memory in the following step because the CIP image must be "exploded" from the single image file on the TFTP server to multiple files in Flash memory. This capability is added in Release 11.1.

Step 8 Download the CIP microcode image to the Flash memory card in slot 0.

Step 9 Perform a microcode reload.

Step 10 Restore the running configuration with the configuration you saved to the TFTP server in Step 3.

For CIP microcode that shipped on Flash memory cards, do the following:

Step 1 Insert the Flash memory card into a Flash memory card slot 0.

Step 2 Configure the router to boot from the Flash memory card in slot 0.

Note For the specific procedures associated with the steps in this overview, refer to the companion publication Upgrading Software and Microcode in Cisco 7000 Family Routers (document number 78-1144-xx), which includes the information and procedures necessary to upgrade your CIP microcode. The Upgrading Software and Microcode in Cisco 7000 Family Routers publication includes information on upgrading software and microcode images, transferring files to and from Trivial File Transfer Protocol (TFTP) servers, copying files between nonvolatile random-access memory (NVRAM) and Flash memory, and between TFTP servers and Flash memory. The publication also includes basic instructions for booting your system.

Cisco Connection Online

Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

WWW: http://www.cisco.com
WWW: http://www-europe.cisco.com
WWW: http://www-china.cisco.com
Telnet: cco.cisco.com
Modem: From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.

For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.

Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.

Documentation CD-ROM

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.

Default CIP Microcode Version	Cisco IOS Release 11.1	Cisco IOS Release 11.2	Cisco IOS Release 11.2 BC	Cisco IOS Release 11.3	Cisco IOS Release 11.3T	Cisco IOS Release 12.0	Cisco IOS Release 12.0T	Cisco IOS Release 12.1	Cisco IOS Release 12.1T
21-3	11.1(1)
22-0	11.1(1)
22-3	11.1(3)
22-6	11.1(5)
22-7	11.1(6)
22-10	11.1(7)	11.2(1), 11.2(2)
22-12	11.1(8)	11.2(3), 11.2(4)
22-14	11.1(9)
22-15	11.1(10)
22-17		11.2(5)
22-18	11.1(11)
22-19		11.2(6)
22-20	11.1 (12)	11.2(7)
22-21	11.1 (13)	11.2(8)
22-22	11.1(14)	11.2(9)
22-23	11.1(15)
22-25	11.1(16)	11.2(10)
22-26	11.1(17)	11.2(11)
22-27	11.1(18)	11.2(12), 11.2(13)
22-30	11.1(20)	11.2(14)
22-31		11.2(15)
22-32	11.1(22)	11.2(16)
22-34	11.1(24)	11.2(17)
22-35		11.2(18)
22-38		11.2(19)
22-39		11.2(20)
22-40		11.2(21)
22-41		11.2(22)
22-43		11.2(23)
24-0			11.2(8) BC
24-1			11.2(9) BC
24-2			11.2(10) BC
24-3			11.2(11) BC
24-4			11.2(12) BC
24-5			11.2(13) BC
24-6			11.2(14) BC
24-7			11.2(15) BC
24-8			11.2(16) BC
24-9			11.2(17) BC
24-11			11.2(18) BC
24-13			11.2(19) BC
24-14			11.2(20) BC
24-15			11.2(21) BC
24-16			11.2(22) BC
24-18			11.2(23) BC
25-3				11.3(1)
25-6				11.3(2)
25-7				11.3(3), 11.3(4)
25-8				11.3(5), 11.3(6)
25-9				11.3(7)
25-10				11.3(8)
25-11				11.3(9)
25-12				11.3(10)
25-13				11.3(11)
26-0					11.3(3)T
26-1					11.3(4)T
26-2					11.3(5)T, 11.3(6)T,
26-4					11.3(7)T	12.0(1), 12.0(2)	12.0(1)T, 12.0(2)T
26-5					11.3(8)T	12.0(3)
26-7					11.3(9)T	12.0(4)
26-8					11.3(10)T, 11.3(11)T	12.0(5)
26-9						12.0(6), 12.0(7)
26-10						12.0(8)
26-11						12.0(9)
26-12						12.0(10)
26-13						12.0(11)
26-15						12.0(12)
27-0							12.0(3)T
27-1							12.0(4)T
27-2							12.0(5)T
27-4							12.0(7)T
27-6								12.1(1)	12.1(1)T
27-7								12.1(2)	12.1(2)T
27-8								12.1(3)	12.1(3)T

Table of Contents

Channel Interface Processor Microcode Release Note and Microcode Upgrade Requirements