IBM CIP Protocols

Document ID: 17543

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Hardware Requirements
      Bus and Tag
      ESCON
Host Requirements
      Host Software Version
      Host Software Configuration
      Host Operating System Considerations
Syntax and Examples of CIP Host Configuration
      TCP/IP Configuration for IP Datagram
      TCP/IP Configuration for Offload
      CSNA Configuration on the Host
Router Interface Configuration
      CSNA Configuration with SRB
      CIP Configuration as a TN3270 Server with SRB
How to Troubleshoot CIP Connection Problems
      Host Channel Condition Code 3
      Host Channel Interface Control Check
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

This Channel Interface Processor (CIP) installation checklist is intended to help you install and configure a CIP card.

If this is a new installation, it is recommend that you work with your Cisco Technical Support engineer to ensure success.

For more information about CIP, refer to Channel Interface Processor Frequently Asked Questions.

Prerequisites

Requirements

This document presumes either that you are working with a Cisco-certified engineer or that you are familiar with the following topics:

• Router operations and hardware

• TCP/IP

• Systems Network Architecture (SNA) and IBM terms and concepts

• Channel technology and IBM host operations

• Source-route bridging (SRB)

Components Used

The information in this document is based on these software and hardware versions:

• Cisco 7000, 7200, or 7500 router

• CIP card, if in a Cisco 7000 or 7500 router

• Channel Port Adaptor (CPA) card, if in a Cisco 7200 router

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Hardware Requirements

Each CIP card takes up one slot in a Cisco 7000 or 7500 router. A typical configuration would use one or two CIPs per router, but it is possible to put a CIP card in every available slot. The CPA is available for the 7200 series only. It can not be used in a Versatile Interface Processor (VIP) card. It provides the same functionality as a one-port CIP cards, but with reduced performance.

To connect a Cisco 7000 router to an IBM or compatible mainframe computer with a CIP card—or to connect a Cisco 7200 router to a mainframe with a CPA—this hardware is required:

• Cisco CIP card or CPA

• For Bus and Tag—Parallel channel cables and terminators. Up to two parallel channel adapters can be added to a single CIP.

  For Enterprise System Connection (ESCON)—ESCON fiber-based cables, directors, and so forth. Up to two ESCON channel adapters (ECAs) can be added to a single CIP.

Note:  A CPA is always single port.

Bus and Tag

The CIP supports these IBM or compatible mainframes and software (including Amdahl and Hitachi mainframes):

• S/390 (all models)

• ES/9000 (all models)

• ES/3090 (all models)

• 4381

Bus and Tag Cables

These three cables are required for Bus and Tag attachment:

• CAB-PCA-Y—A 78-pin Y cable that attaches to the card. The 78-pin terminator that ships with a CAB-PCA-VA installs on the female end of the Y cable (Bus and Tag OUT on the router). This terminator can be used in lieu of standard Bus and Tag terminators, which would be attached to the ends of CAB-PCA-VB as described later in this section. If a CAB-PCA-VB is used, the 78-pin terminator is not used.

  Note: If CAB-PCA-VB is not used, then you must use the 78-pin terminator.

• CAB-PCA-VA—Converts outbound host Bus and Tag cable connections to 78-pin D-Shell. This connects to the male end of the Y on CAB-PCA-Y (Bus and Tag IN on the router).

• CAB-PCA-VB—A 78-pin to Bus and Tag conversion for the next downstream channel-attached control unit, which connects to the female end of the Y on CAB-PCA-Y (Bus and Tag OUT on the router). You may put standard Bus and Tag terminators at the end of this cable, if the router is the last device on the channel.

  Note: If CAB-PCA-VB is not used, then you must use the 78-pin terminator.

For details and diagrams of sample Bus and Tag cable configurations, refer to Channel Interface Processor Cable Information.

ESCON

The CIP supports these IBM or compatible mainframes and software (including Amdahl and Hitachi mainframes):

• S/390 (all models)

• ES/9000 (all models)

• ES/3090 (T and J models)

• 9032 and 9033 ESCON Directors

ESCON Channel Cables

These three cables are required for ESCON attachment:

• CX-CIP-ECA1—Single ESCON channel interface.

• CX-CIP-ECA2—Dual ESCON channel interface.

• CX-CIP-ECAP1—Single ESCON and single parallel channel interface.

Host Requirements

Host Software Version

This section lists the minimum software versions that must be installed for each principle host software component.

IBM TCP/IP

One of these suites of transport and application protocols for TCP/IP is required, depending on the host operating system:

• IBM TCP/IP for virtual machine (VM), Version 2, Release 2 or later. Further, these IBM Authorized Program Analysis Reports (APARs) are required:

  • APAR PN35887

  • APAR PN45248

• IBM TCP/IP for Multiple Virtual Storage (MVS), Version 2, Release 2.1 or later. Further, these APARs and Problem Trouble Fixes (PTFs) are required.

  • PTF UN47759 or greater (UN63422 includes UN47759 and fixes other bugs as well)

  • PTF UN51632 (APAR PN45287)

Note: You might need to contact your IBM representative for details about which APARs, PTFs, or both that you need to have on your system.

Interlink TCP/IP

Interlink TCP/IP requires Secure Network Services/Transmission Control Protocol (SNS/TCP) access for MVS, Version 2, Release 1 or later. Further, these patches are required:

• PTF TP02808

• PTF TP02780

• USERMOD MA27478 (or equivalent PTF, when available)

CIP-SNA or TN3270 Support

Regardless of whether you are using an MVS, VM, or Virtual Storage Extended (VSE) system, CIP-SNA or TN3270 support requires the installation of IBM Adapter Configuration Facility/Virtual Telecommunications Access Method (ACF/VTAM), Version 3, Release 4 or later.

Host Software Configuration

This section describes the specific changes to host software that you must do to configure the host.

IOCP Generation for ESCON and Bus and Tag

An Input/Output Control Program (IOCP) generation (gen) defines the characteristics of the communication between the mainframe and the channel-attached devices.

The IOCP gens for ESCON and Bus and Tag CIPs are nearly identical. The main differences is that you must specify ESCON Director and port information for an ECA but you must specify channel speed for a PCA. In addition, the channel path identifier (CHPID) types are different.

IOCP Macros

These macros are run to create IOCP gens that provide or define particular characteristics:

• Resource Macro—Lists the logical partitions (LPARs) on the host, which can be thought of as separate virtual hosts that occupy the same physical mainframe.

• CHPID Macro—Describes the channel path.

• CTLUNIT Macro—Tells the host how to talk to the control unit.

• IODEVICE Macro—Tells the host how to talk to the device or devices attached to the control unit. In the case of the CIP, the control unit and the device are not physically separate, but they are genned as if they are physically seperate.

For details, refer to the sample configuration in Configuring IOCP from a 9221 Mainframe.

The parameters that you provide to these macros depend on whether the physical connection is ESCON or Bus and Tag.

ESCON Macros

Your configuration of ESCON macros must conform to these requirements:

• In the CHPID macro, you must code TYPE=CNC.

• In the CNTLUNIT and IODEVICE macros, you should code UNIT=RS6K or UNIT=3172, if your level of operating system supports these specifications; otherwise code UNIT=SCTC.

• In the CHPID Macro, if you code SHARED then you must specify the partition number in the CLAW statement in the router, even if you are not using ESCON Multiple Image Facility (EMIF).

  SHARED automatically becomes the default if you code PART or NOTPART. When the device is shared—either implicitly because PART or NOTPART is coded or explicitly because SHARED is coded—you must know the values coded in the RESOURCE macro to code the correct value for the partition number in the CLAW statement in the router.

• In the CHPID macro, if you do not code SHARED—and if you do not specify an access list (by coding PART) or you do not code NOTPART—then specify an LPAR number of 0 (zero) in the CLAW statement in the router.

• If you are using an ESCON director, you must code SWITCH= switch_number in the CHPID macro and you must code LINK= link_number in the CNTLUNIT macro; switch_number is the logical number assigned to the ESCON director, and link_number is the ESCON director port number of the port directly connected to the CIP.

Bus and Tag Macros

Your configuration of Bus and Tag macros must conform to these requirements:

• In the CHPID macro, you must code TYPE=BL.

• In the CNTLUNIT and IODEVICE macros, you must code UNIT=3088 or UNIT=CTC.

  Note: Some operating systems may support UNIT=3172 or UNIT=RS6K.

• In the CNTLUNIT macro, you must code SHARED=N.

• In the CNTLUNIT macro, you must code the channel speed with either PROTOCL=S (for 3 Mbps) or PROTOCL=S4 (for 4.5 Mbps).

Dynamic Reconfiguration Management

If you are using Dynamic Reconfiguration Management (DRM) with earlier versions of TCP/IP, you must code DYNAMIC=NO in the DEVICE statement. Only later versions support DYNAMIC=YES.

Host Operating System Considerations

These are the operating system considerations for TCP/IP with IP Datagram and Offload:

• Missing Interrupt Handler (MIH) must be disabled on the host for CIP addresses.

  • MVS—Put a statement in the IECIOS file in the PARMLIB directory:

    1. Include this statement in the IECIOSxx file, where xx is an arbitrary sequence number assigned by the user:

       MIH TIME=00:00:00, DEV=(xxx-xxx)

       In that statement, xxx-xxx is the device number range.

    2. Include this statement in the IEASYSxx, where xx is an arbitrary number (the default is 00):

       IOS=xx
       

       The xx in that statement points at the xx suffix of the IECIOSxx file. If this statement is not included in the IEASYS file, you may specify it dynamically by issuing this command at the command line:

       SET IOS=xx
       
       

    3. If those commands have been omitted from the above files, you may dynamically change the MIH value by issuing this command from the command line:

       SETIOS MIH DEV=xxx, TIME=00:00
       

       In that command, xxx is the specific device number.

    Note: To confirm the MIH timer value, issue this command from the command line:

    D IOS,MIH
    

  • VM—Issue this command:

    SET MITIME xxx-xxx 00:00
    

    In that command, xxx-xxx is the device number range.

    Alternatively, you may specify the keyword OFF in place of 00:00 (for example, SET MITIME 0600 OFF). To set this option permanently, the command should probably be coded as a statement in the PROFILE EXEC for the AUTOLOG1 user ID (or equivalent user ID), which is usually started during the initial program load (IPL) of the VM.

    Note: To confirm the MIH timer value, issue this command from the command line:

    Q MITIME
    

• For VM or MVS Guests under VM, you must code V=R (Real mode) for the Guest in order for the Common Link Access for Workstations (CLAW) channel programs to be properly built and executed.

Syntax and Examples of CIP Host Configuration

This section provides the syntax for TCP/IP parameter configuration statements. It also provides examples of how each statement applies to a CIP host.

TCP/IP Configuration for IP Datagram

IP Datagram passes TCP/IP frames to and from the mainframe-resident TCP/IP stack. IP Datagram support is available with Cisco IOS® Software Releases 10.3 and 11.0 and above.

These are the explanations of the parameters:

DEVICE Statement

DEVICE device_name CLAW address host_name workstation_name NONE read_buffers write_buffers read_size write_size

Here is an example of a DEVICE statement:

DEVICE CIP1 CLAW 7E0 CETCPIP CECIPE0 NONE 20 20 4096 4096

LINK Statement

LINK link_name IP 0 device_name

Here is an example of a LINK statement:

LINK CHIP1 IP 0 CIP1

HOME Statement

HOME ip_address link_name

Here is an example of a HOME statement:

HOME
128.207.160.2 CHIP1

GATEWAY Statement

GATEWAY network first_hop driver packet_size subn_mask subn_value

The GATEWAY statement provides the static route pointing the host at the router. This is where you associate subnets with the LINK statement for the router.

Here is an example of a GATEWAY statement:

GATEWAY 128.207 = CHIP1 4096 0.0.255.0 0.0.160.0

DEFAULTNET Statement

DEFAULTNET first_hop driver packet_size subn_mask subn_value

Here is an example of the DEFAULTNET statement:

DEFAULTNET = CHIP1 1500 0

START Statement

START device_name

Here is an example of a START statement for a device named CIP1:

START CIP1

TCP/IP Configuration for Offload

TCP/IP Offload places TCP/IP protocols onto the CIP, and the CIP assumes the responsibility for processing the TCP/IP frames, calculating checksums, and retransmitting bad frames. The mainframe TCP/IP stack is still required for server applications like FTP, Telnet, TN3270, Network File System (NFS), and line printer daemon (LPD); but TCP/IP processing is removed from the mainframe and performed on the CIP.

Note: IBM has withdrawn support for Offload in later versions of OS/390. Therefore, new installations should use CLAW.

These are the explanations of the parameters:

DEVICE Statement

DEVICE device_name CLAW address host_name workstation_name NONE read_buffers write_buffers read_size write_size

Here is an example of a DEVICE statement:

DEVICE CIP2 CLAW 7D0 CETCPIP CECIPE0 NONE 20 20 4096 4096

First LINK Statement

LINK link1_name OFFLOADLINK1 1 device_name

Here is an example of a LINK statement:

LINK CHIP2 OFFLOADLINK1 1 CIP2

HOME Statement

The HOME statement is not used in an Offload configuration.

Second LINK Statement

LINK link2_name OFFLOADAPIBROAD ip_address device_name link1_name

Here is an example of a LINK statement:

LINK CHIP2A OFFLOADAPIBROAD 128.207.161.2 CIP2 CHIP2

GATEWAY Statement

GATEWAY network first_hop driver packet_size subn_mask subn_value

The GATEWAY statement provides the static route pointing the host at the router. This is where you associate subnets with the LINK statement for the router.

Here is an example of a GATEWAY statement:

GATEWAY 128.207 = CHIP2A 4096  0.0.255.0 0.0.161.0

DEFAULTNET Statement

DEFAULTNET first_hop driver packet_size subn_mask subn_value

Here is an example of the DEFAULTNET statement:

DEFAULTNET = CHIP2A 1500 0

START Statement

START device_name

Here is an example of a START statement for a device named CIP2:

START CIP2

CSNA Configuration on the Host

CSNA places an Logical Link Control, type 2 (LLC2) layer on the CIP and uses the External Communications Adapter (XCA).

Major Node support is provided in the ACF/VTAM. CSNA on the CIP delivers SNA traffic to and from the mainframe from a variety of sources. These systems deliver SNA traffic to the CSNA on the CIP:

• Local LANs using SRB

• Remote LANs using remote source-route bridging (RSRB) or data-link switching plus (DLSw+)

• Advanced Peer-to-Peer Networking (APPN)

• Downstream physical unit (DSPU) concentration

• Qualified Logical Link Control (QLLC)

• Source-route translational bridge (SR/TLB)

• SDLC-to-LAN Conversion (SDLLC)

Host SNA Configuration Example

This section provides an example of the VTAM definitions required on the mainframe for CSNA and explains the meaning of the various parameters. The configuration is contained in one or more Switched Major Nodes and in one or more XCA major nodes.

CESW01   VBUILD TYPE=SWNET
***********************************************************************
PU21     PU    ADDR=01,IDBLK=05D,IDNUM=20001,                          X
               ANS=CONT,                                               X
               PUTYPE=2
LU0212   LU    LOCADDR=2,                                              X
               MODETAB=ISTINCLM,DLOGMOD=D6327802,                      X
               USSTAB=USSTAB,LOGAPPL=VM,PACING=7
***********************************************************************

*

X

CESW01

VBUILD TYPE=SWNET

Physical Unit

Each Switched Major Node must contain at least one physical unit (PU) macro. A PU definition is required for each physical controller in the network.

These are the parameters that relate to the PU:

PU21
LU02102

ADDR=01

IDBLK

IDNUM

PUTYPE=2

ANS=CONT

Logical Unit

A logical unit (LU) definition represents the point of entry to the SNA network, such as a terminal.

These are the parameters that relate to the LU:

LOCADDR

MODETAB

DLOGMOD

USSTAB

LOGAPPL

XCA Major Node Configuration Example

Each CSNA statement configured on the router must have at least one corresponding XCA major node.

XCA0202  VBUILD TYPE=XCA
PORT202  PORT ADAPNO=0,CUADDR=202,SAPADDR=04,MEDIUM=RING
GRPCSNA  GROUP ANSWER=ON,AUTOGEN=(5,L,P),CALL=INOUT,DIAL=YES

XCA0202

PORT202

ADAPNO=0

CUADDR=202

SAPADDR=04

MEDIUM=RING

GRPCSNA

ANSWER=ON

AUTOGEN=(5,L,P)

CALL=INOUT

DIAL=YES

Router Interface Configuration

This section provides sample router configurations that allow you to use CSNA with SRB and to configure a TN3270 server function on the CIP.

CSNA Configuration with SRB

This section shows a sample router configuration of the simplest way to use CSNA with SRB. Only the parts that relate to the CIP are explained, as you should already understand SRB.

source-bridge ring-group 100
!
interface Channel1/0
 no ip address
 no keepalive
 csna 0100 10
!
interface Channel1/2
 no ip address
 no keepalive
 LAN TokenRing 0
  source-bridge 1 1 100
  adapter 0 4000.1234.0001
!
interface TokenRing4/0
 ring-speed 16
 source-bridge 2 1 100
 source-bridge spanning
!

• First, notice the CSNA statement, which is much simpler than TCP/IP. The path and device address are configured the same as in TCP/IP. So, in our example, this is a CSNA device that is either Bus and Tag or directly connected ESCON and that is using channel address 10.

• Configuration of the portion that looks like an XCA Major Node to VTAM is done in the the virtual channel adapter, Channel x /2, where x is the slot number in the router. In this example, it is Channel1/2. Notice there is no Channel1/1. There could be if this were a two-port CIP; but, in either case, there would only be a Channel1/2 because a single virtual channel interface serves both ports on any one CIP.

Next, consider these statements under the virtual channel interface:

interface Channel1/2
 no ip address
 no keepalive
 LAN TokenRing 0
  adapter 0 4000.1234.0001
  source-bridge 1 1 100

• Notice that there is no IP address or keepalive configured. These serve no purpose on a virtual interface.

• The LAN TokenRing 0 statement defines a virtual LAN (VLAN). The LAN is a Token Ring that is assigned an arbitrary LAN number of 0. This number can be any number from 0 to 31 and it must be unique on this CIP. It does not match any part of the host configuration in VTAM.

• The adapter 0 4000.1234.0001 statement is the virtual adapter mentioned in the XCA Major Node Configuration Example section of this document.

  • 0—The RAN that matches the RAN configured for the XCA Major Node in VTAM.

  • 4000.1234.0001—The locally administered MAC address of the virtual adapter, which is the address for which devices in the network explore and to which they eventually connect.

  Note: There is a VTAM limitation that does not allow more than 18 adapters to be defined on a single CIP. It arises from the amount of data that VTAM will read from a channel-attached device. During link initialization, VTAM requests information about all of the adapters on the box to which it is connected. VTAM provides only a channel read that is long enough to define 18 adapters. XCAs were originally 3172s, which support a maximum of four adapters.

To tie this into SRB, configure this statement:

source-bridge ring-group 100

There is a real Token Ring with a ring number of 2 tied to virtual ring 100 across bridge 1 with these statements:

interface TokenRing4/0
source-bridge 2 1 100

Finally, just like in the real ring, tie the virtual ring on the CIP (which carries a ring number of 1) into ring group 100 across bridge 1 with this statement:

source-bridge 1 1 100

At this point, real users on real ring 2 can connect to VTAM across ring group 100 on to ring 1; they can also connect into the XCA’s adapter, which carries a MAC address of 4000.1234.0001. In its simplest form, the topology for this configuration looks like this:

The following graphics show the relationship between the IOCP, the XCA definition, and the router configuration. The mainframe host is on the right, in a box outlined with a dotted line. The router is on the left, in a similar box.

CIP Configuration as a TN3270 Server with SRB

To configure the TN3270 server function on the CIP, start with the sample CSNA Configuration with SRB in this document and add some lines to it:

source-bridge ring-group 100
!
interface Channel1/0
 no ip address
 no keepalive
 csna 0100 10
!
interface Channel1/2
 ip address 172.16.39.98 255.255.25.224
 no keepalive
 lan TokenRing 0
  source-bridge 1 1 100
  adapter 0 4000.1234.0001
  adapter 1 4000.0000.0001
 tn3270-server
  pu CETN3270 05d90001 172.16.39.97 token-adapter 1 04 rmac
   4000.1234.0001 lu-seed X70TN1##
  pu CETN327X 05d91234 172.16.39.99 token-adapter 1 08 rmac 4000.1234.0001
!
interface TokenRing4/0
 ring-speed 16
 source-bridge 2 1 100
 source-bridge spanning
!

An IP address is assigned to the CIP virtual interface with this statement:

ip address 172.16.39.98 255.255.255.224

This is just like any real interface; the value can not overlap with other interfaces.

The TN3270 PUs can be configured to use, as their local adapter, the same adapter as the XCA Major Node; but this is not recommended. For ease of troubleshooting and other operations, these PUs are set up to use the XCA that has opened adapter 0 (MAC address 4000.1234.0001), with adapter 1 (MAC address 4000.0000.0001) as the local adapter.

How to Troubleshoot CIP Connection Problems

This section explains two basic connection failures:

• Host Channel Condition Code 3—No path available.

• Host Channel Interface Control Check (IFCC)

Host Channel Condition Code 3

When the subchannels are varied online on the operating system and the host message indicates a condition code 3 (CC3), the channel path to the system unit is not available. One or more of these problems has occurred:

• The control unit (the CIP) is offline.

• The channel “select out” signal is not being honored by the CIP (Bus & Tag channel).

• The light is not seen by the CIP (ESCON channel).

These are the possible causes of these errors:

New Installation or Reconfiguration

• Improper Input/Output Configuration Data Set (IOCDS)—multipath specified.

• Improper IOCDS—incorrect address.

• Bus & Tag cable switched to Bypass.

• CHPID is offline.

• Incorrect cabling to the host.

• Incorrect PATH specified in the CIP.

Working Application

• Bus & Tag Cable switched to Bypass.

• CIP microcode abort.

• CIP shutdown command issued.

• TCP/IP stack brought down.

Note: A No physical paths available message could be indicative of an incorrectly coded CLAW, OFFLOAD, or CSNA statement (path nibble 3) in the router. If SHARED is coded in the CHPID Macro and nibble 3 of the path parameter in the CLAW statement in the router is zero (0), you will get the No physical paths available message. Likewise, if SHARED is not coded in the CHPID, but nibble 3 of the path parameter in the CLAW statement in the router is zero (0), you will receive the message. There may be other occassions where the PATH statement is incorrectly coded; that is, where it does not match the IOCP or the Host Controller Driver (HCD).

Host Channel Interface Control Check

Host Channel Interface Control Check can be caused by any of the following conditions or events:

New Installation or Reconfiguration

• Improper cabling to host.

• Bus and Tag reversed.

• Bus-in or Tag-in and Bus-out or Tag-out reversed.

• Missing Channel Terminators.

• Bent pin on Channel Serpentine Connectors.

• Y cable is disconnected from the CIP while its switch is in the S position.

Working Application

• CIP microcode abort during Command Chaining.

• System Unit Application hang during a read operation.

• Loose cable on CIP card.

• Y cable is disconnected from the CIP while its switch is in the S position.

Note: If you see this message on the host, try the listed suggestions:

CLAW device device_name unexpected siocc 3 from sense id from device device_address

• MVS—Issue the d u,,,device_address,2 command, where device_address is the address of the CLAW device. This command shows if the device is online. If it is, then check the configuration to see if it is configured as a dynamic device (DYN=YES). The MVS TCP/IP product (earlier than 3.1) does not support dynamic devices (without a PTF that may not yet be available).

• VM—Issue the q device1-device2 command to check that both devices are online. They should also be attached to the TCP/IP VM. If not attached, attach them.

NetPro Discussion Forums - Featured Conversations

Related Information

• What is a Subarea?
• Understanding Logical Link Control
• Technology Support
• Product Support
• Technical Support - Cisco Systems