Cisco IOS Bridging and IBM Networking Configuration Guide, Release 12.2
Configuring Cisco Transaction Connection
Download this chapter
Configuring Cisco Transaction ConnectionConfiguring Cisco Transaction Connection
give_us_feedback

Table Of Contents

Configuring Cisco Transaction Connection

Technology Overview

Using CTRC for CICS Access

Using CTRC for DB2 Access

Using the CTRC Keepalive Timer

Configuration CTRC Task List

General Tasks

Router Requirements

Host Requirements

CICS Host Requirements

DB2 Host Requirements

Client Requirements

Defining the CTRC Router to VTAM

Logmode Table Entry

Major Node Definitions

Preparing a CICS Host for Remote Access

Defining the CICS Subsystem to VTAM

Configuring CICS for ISC

Defining APPC Connections to CTRC

Creating Static Definitions for Router Connections

Using Autoinstall for Router Connections

Installing Client Virtual Terminals

Supporting CICS Security Models

Bind Security

Link Security

User Security

Preparing a DB2 Host for Remote Access

Defining the DB2 Subsystem to VTAM

Configuring DB2 for Remote Access

Configuring DDF

Starting DDF

Defining CTRC in the DB2 Communications Database

Configuring Password Expiration Management

PEM Support for IP Passthrough

PEM Support for APPC

Configuring the CTRC Router

Configuring CTRC for CICS Communications

Configuring a CTRC Destination for CICS

Configuring a CTRC Server for CICS

Configuring a CTRC Route for CICS

Configuring CTRC for DB2 Communications

Configuring SNA Switching Services

Configuring the CTRC License

Verifying the CTRC Configuration

Configuring CTRC Clients

Setting Up DB2 DRDA Client Connections

Setting Up CICS Clients

Setting Up CICS Universal Client Connections

Setting Up TXSeries as a CTRC Client

Setting Up COMTI Client Connections

Monitoring and Maintaining CTRC

Monitoring and Maintaining CTRC Communications with CICS

Monitoring and Maintaining CTRC Communications with DB2

CTRC Configuration Examples

CTRC Servers with IP Addresses Configuration Example (DB2)

CTRC Servers with IP Addresses, RDB Names, and Ports Configuration Example 1 (DB2)

CTRC Servers with IP Addresses, RDB Names, and Ports Configuration Example 2 (DB2)

Server Selection by IP Addresses, RDB Names, and Ports Configuration Example (DB2)

CTRC with CIP and DB2 on VTAM Configuration Example (DB2)

CTRC Servers Using Token Ring to a LEN Configuration Example (CICS and DB2)

CTRC Servers with IP Addresses, Routes, and Multi-Valued Destinations Configuration Example (CICS)


Configuring Cisco Transaction Connection

This chapter describes how to configure the Cisco Transaction Connection (CTRC) feature. For a complete description of the CTRC commands mentioned in this chapter, refer to the "Cisco Transaction Connection Commands" chapter of the Cisco IOS Bridging and IBM Networking Command Reference (Volume 2 of 2).To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

This chapter contains the following sections:

•Technology Overview

•Configuration CTRC Task List

•Defining the CTRC Router to VTAM

•Preparing a CICS Host for Remote Access

•Preparing a DB2 Host for Remote Access

•Configuring the CTRC Router

•Verifying the CTRC Configuration

•Configuring CTRC Clients

•Monitoring and Maintaining CTRC

•CTRC Configuration Examples

To identify the hardware platform or software image information associated with a feature, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the "Identifying Platform Support for Cisco IOS Software Features" section in the "Using Cisco IOS Software" chapter.

Technology Overview

CTRC provides TCP/IP end-users and servers with fast, reliable, and secure access to IBM DB2 databases and Customer Information Control System (CICS) transaction programs. The CTRC feature of the Cisco router provides a flexible, cost-effective, and scalable solution for enterprise-wide database access and transaction processing. CTRC allows Windows or UNIX client applications to call CICS transactions without changes to the client or host software. Any client running a Distributed Relational Database Architecture (DRDA) requestor, which is included in most Open Database Connectivity (ODBC) applications, can use CTRC to access data in DB2 databases.

With CTRC, you can continue using current CICS client/server applications on a more robust, higher-performing platform than the general-purpose operating system gateways. CTRC provides protocol independence between client workstations and the host, enabling the applications to communicate directly with CICS and DB2 without costly mainframe application upgrades or expensive middleware servers.

The CTRC software feature provides:

•Access to DB2 databases from TCP/IP clients

•Access to CICS applications from TCP/IP clients

•A keepalive timer to maintain the TCP/IP connection

•Integration with the Cisco IOS software to provide intelligent network services for application connectivity, workload management, and fault tolerance

CTRC is a standards-based solution that can be managed either from the host, using mainframe management software, or from a Simple Network Management Protocol (SNMP) workstation. The following MIBs allow monitoring the CTRC router from the management platform of choice:

•CISCO-DATABASE-CONNECTION-MIB.my - 93

•CISCO-TRANSACTION-CONNECTION-MIB.my - 144

For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB website on Cisco.com.

Using CTRC for CICS Access

When a router is configured to use CTRC for communications with CICS systems, the router converts Inter-System Communications (ISC) packets over TCP/IP to ISC packets over Advanced Program-to-Program Communications (APPC) LU 6.2, and then routes them to the appropriate CICS region. CTRC converts CICS client messages received via TCP/IP to SNA messages and uses Cisco SNA Switching Services (SNASw) to send them to the host.

When a client connects to a CICS region on an IBM mainframe host, CTRC allocates an APPC conversation over SNA to an IBM server and acts as a gateway between ISC over TCP/IP and ISC over APPC. CTRC allows you to configure specific routes for CICS transactions, giving you control over which transaction is routed to which CICS region.

CTRC supports connectivity to CICS from the IBM Universal Client (also referred to as the Common Client), TXSeries clients, and Microsoft Common Object Module Transaction Interface (COMTI) clients. See the "Configuration CTRC Task List" section for details on the hardware and software that CTRC supports.

Figure 237 illustrates how CTRC allows CICS client applications on TCP/IP networks to interact with CICS transaction monitoring systems on IBM hosts.

Figure 237 Cisco Router Configured with the CTRC Feature for CICS Communications

Using CTRC for DB2 Access

In addition to its CICS-related functionality, CTRC includes the feature previously known as Cisco Database Connection (CDBC). CTRC allows Cisco routers to use IBM's DRDA protocol to provide a gateway between client workstations on TCP/IP networks and IBM DB2 databases on SNA networks. CTRC also provides full duplex TCP passthrough to DB2 systems that support direct TCP/IP access.

Clients use a CTRC IP address and port on the router to connect to the IBM host system in either an SNA network or a TCP/IP network.

Figure 238 illustrates how the Cisco router configured with the CTRC feature enables the exchange of database information between an ODBC client application running DRDA in a TCP/IP network and a DB2 system in an SNA network. For an SNA host connection, the CTRC router converts DRDA packets over TCP/IP to DRDA packets over APPC (LU 6.2) and then routes them to DB2 databases. When a client connects to the database on an IBM mainframe host, CTRC allocates an APPC conversation over SNA to an IBM server and acts as a gateway between DRDA over TCP/IP and DRDA over APPC.

Figure 238 Cisco Router Configured with the CTRC Feature for DB2 Communications (SNA Host Network)

Figure 239 illustrates a configuration where CTRC supports direct TCP/IP access to DB2. For a TCP/IP host connection, CTRC routes the DRDA packets over TCP/IP without protocol changes. To use this TCP/IP passthrough feature of CTRC, the host database version must support direct TCP/IP access and the SNA Switching Services must be available.

Note Licensing of the CTRC router is based on the cpname assigned to the router in the SNA Switching Services configuration. You must install and start SNA Switching Services with at least a minimal configuration to support the TCP/IP connections. Refer to the "Configuring SNA Switching Services" section for more information about configuring the CTRC license and the SNA Switching Services that CTRC requires.

Figure 239 Cisco Router Configured with the CTRC Feature for DB2 Communications (TCP/IP Host Network)

Using the CTRC Keepalive Timer

In environments where there is heavy network traffic or limited processing capabilities, TCP/IP connections can time out before transactions are completed. The Keepalive Timer feature enables CTRC servers to send acknowledgment messages to clients at specific intervals to maintain the TCP/IP connection. CTRC servers that support direct TCP/IP connections to a DB2 host also can be configured to send keepalive messages to the host. The Keepalive Timer feature keeps TCP/IP connections active so they do not time out from inactivity.

Configuration CTRC Task List

CTRC can be configured for use with CICS, with DB2, or both. Both CICS and DB2 configurations require Cisco SNA Switching Services.

General Tasks

Setting up CTRC involves the following general tasks:

•Defining the CTRC Router to VTAM

•Preparing a CICS Host for Remote Access

•Preparing a DB2 Host for Remote Access

•Configuring the CTRC Router

•Verifying the CTRC Configuration

•Configuring CTRC Clients

To configure CTRC for use with both CICS and DB2, complete all the configuration tasks. Otherwise, skip the sections that are related only to CICS or DB2, as appropriate for your needs. The "CTRC Configuration Examples" section provides example configurations for using CTRC in various network topologies.

The following sections describe the hardware and software required to use CTRC.

Router Requirements

CTRC became available in Cisco IOS Release 12.05(XN). It is available for the following platforms:

•Cisco 7200 series routers

•Cisco 7500 series routers

CTRC consists of a system image and a microcode image, which are virtually bundled as one combined image. Within the Cisco IOS software listings, look for a software feature called Enterprise/SNASw Plus.

If you want to run CTRC on a router with a CIP card, also be sure to download the CIP hardware microcode appropriate for the Cisco IOS software level you are using.

Host Requirements

Mainframe hosts using SNA with the CTRC server must be running VTAM V3.0 or later.

CICS Host Requirements

Using CTRC for CICS access requires CICS Version 4.0 or later. CTRC supports the following CICS servers:

•CICS Transaction Server for OS/390, Version 1 or later

•CICS/400, Version 3.1

•CICS on Open Systems and NT (TXSeries)

•CICS/ESA, Version 3.3*

•CICS/ESA, Version 4.1

•CICS/MVS, Version 2.12.*

•CICS/VSE, Version 2.2*

•CICS/VSE, Version 2.3

•CICS for OS/2, Version 2.01 or later

Note Versions marked with an asterisk (*) have limited server support. These versions support ECI but they do not support EPI or the Terminal Emulation function.

DB2 Host Requirements

When CTRC is configured for access to DB2 in an SNA network, client-based ODBC applications can connect to the following IBM DB2 relational databases:

•DB2 for OS/390 (DB2/MVS), Version 2.3 or later

•SQL/DS (DB2 for VM and VSE), Version 3.3 or later

•DB2/400 (OS/400), Version 2.2 or later

•DB2 Universal Database for UNIX, OS/2, and Windows NT, Version 5.1 or later

•DB2 Common Server, Version 2.1 or later

CTRC for DB2 access via direct TCP/IP is supported for the following versions of DB2:

•DB2 for OS/390, Version 5.1 or later (requires OS/390 Version 1.3 or later)

•DB2 for VM and VSE, Version 6.1 or later

•DB2/400 (OS/400), Version 4 Release 2 or later

•DB2 Universal Database for UNIX, OS/2, and Windows NT, Version 5.1 or later

Client Requirements

CTRC supports connectivity to DB2 from any client that supports the Level 3 DRDA. Many of the available workstation-based DRDA requestors are ODBC client applications, such as StarSQL.

CTRC supports connectivity to CICS from the following clients:

•IBM Universal Client, version 2.0 or later, using the Extended Presentation Interface (EPI) or the Extended Call Level Interface (ECI)

•IBM TXSeries for AIX or NT, version 4.2 or later, running as clients

•Microsoft COMTI

Defining the CTRC Router to VTAM

Regardless of whether you want to connect to a CICS or a DB2 host, the CTRC router must be defined to VTAM so that the host recognizes and accepts session initiation requests from it. VTAM handles network communications for MVS for direct VTAM and SNA gateway configurations. For each CTRC router, the VTAM system programmer must create a logmode table entry and major node definitions for the CTRC router link.

The following sections provide information about the logmode table entry and major node definitions required for CTRC. Consult your VTAM documentation for detailed instructions on configuring VTAM. You also may want to take advantage of VTAM's support for dynamic definition of independent LU's, which is described in the VTAM documentation.

Logmode Table Entry

The logmode table entry contains information that governs how conversations take place in VTAM. It defines pacing, RU sizes and class of service (COS) parameters. The mode entry can be placed in any mode table under VTAM—the default mode table or the one used in the APPL statement for the LU definitions. (See the "Defining the CICS Subsystem to VTAM" section and the "Defining the DB2 Subsystem to VTAM" section for example APPL statements).

The following example shows a logmode table entry for APPC, with a LOGMODE name of IBMRDB. Make a note of the LOGMODE name because you must use the same name for the DLOGMODE value in the major node definitions and also in the SNA configuration. The PSERVIC field identifies the LU traffic protocol—the value shown in the following example is for an independent LU using LU6.2. 

IBMRDB  MODEENT  LOGMODE=IBMRDB,

            FMPROF=X'13',

            TSPROF=X'01',

            PRIPROT=X'B0',

            SECPROT=X'B0',

            COMPROT=X'50A1',

            RUSIZES=X'8989',

            TYPE=0,

            PSNDPAC=X'03',

            SRVCPAC=X'03',

            SSNDPAC=X'02',

            PSERVIC=X'060200000000000000002F00'

Major Node Definitions

The VTAM system programmer creates an XCA major node definition for the connection to the CTRC router. Additionally, a switched major node definition and a Cross Domain Resource definition can be created to represent the LU for the CTRC router.

In the switched major node definition, the DLOGMOD value must match the LOGMODE value in the mode table entry. The name of IBMRDB is specified for both the LOGMODE value in the previous example and in the following switched major node definition example. Make a note of the values for the LU and PU names, and the CPNAME, DLOGMOD, and CONNTYPE parameters because you must specify the same values in the SNA configuration. 

S02CTRC   VBUILD   TYPE=SWNET

* CTRC DOWNSTREAM PU

CTRCPU  PU    ADDR=01,

            CPNAME=CTRCBOX,

            ANS=CONT,

            DISCNT=NO,

            IRETRY=NO,

            ISTATUS=ACTIVE,

            PUTYPE=2,

            SECNET=NO,

            MAXDATA=521,

            MAXOUT=2,

            MAXPATH=1,

            USSTAB=USSS,

            MODETAB=ISTINCLM,

            DLOGMOD=IBMRDB,

            CONNTYPE=APPN

*

CTRCCIP PATH GRPNM=G02E20A,CALL=IN

*

CTRCBOX LU     LOCADDR=00,    INDEPENDENT LU

           DLOGMOD=IBMRDB,

Preparing a CICS Host for Remote Access

CTRC connects to CICS using the SNA LU6.2 (APPC) communication protocol. The SNA functions are provided by a separate SNA product on the host, and CICS uses the services of that product. On a mainframe host, the SNA product is VTAM (also known as eNetwork Communications Server). You must configure both the CICS subsystem and VTAM to enable ISC.

Defining the CICS Subsystem to VTAM

The APPL statement defines the CICS subsystem to VTAM to support remote access. If your CICS subsystem is not already supporting remote access, you must create an appropriate APPL statement.

The following example shows an APPL statement that defines CICS to VTAM. Make a note of the APPL statement label, which is CICSB in this example, and the password, if one is specified, because you must specify the same values in the SNA configuration. Note that the DLOGMOD value, IBMRDB in this example, must match the LOGMODE value that is specified in the VTAM mode table entry (see the "Logmode Table Entry" section). 

A02CICS VBUILD  TYPE=APPL

CICSB  APPL    AUTH=(ACQ,SPO,PASS,VPACE),

          MODETAB=ISTINCLM,

          DLOGMOD=IBMRDB,

          HAVAIL=YES,

          VPACING=9,

          EAS=10000,

          PARSESS=YES,

          APPC=NO,

          SONSCIP=YES

Configuring CICS for ISC

To use CTRC to communicate with CICS, you must configure CICS for APPC connections. If you have configured another product, such as TXSeries for AIX, to connect to CICS, some of these steps might be completed already.

Step 1 Set the ISC parameter in the CICS system initialization table (SIT) to YES. The following example overrides the CICS SIT parameters with the APPL statement label (CICSB in this example), and a value of YES for the ISC parameter. 

APPLID=(CICSB),

GMTEXT='CICS TS V1.2',

AUXTR=OFF,

EDSALIM=80M,

FCT=NO,

ISC=YES,

MXT=100

Step 2 Install the CICS-supplied resource definition group, DFHCLNT. This installation includes definitions of the CICS internal transactions, CCIN and CTIN, and of the programs they use.

Step 3 When a CICS client sends a request, the server controller calls a routine that supports code page translations and data conversions. Regardless of whether translations and conversions are required, you need to create or modify a DFHCNV table to allow the server controller to handle incoming requests. The use of the DFHCNV macro for defining the table is described in the CICS Family, Communicating from CICS on System/390 document. The following example shows the DFHCNV table entries: 

         PRINT   NOGEN

         DFHCNV   TYPE=INITIAL,SRVERCP=037,CLINTCP=437

         DFHCNV   TYPE=FINAL

         END     DFHCNVBA

Note It is not necessary to code the pages used with CICS clients on the CLINTCP and SRVERCP operands of the DFHCNV TYPE=INITIAL macro.

Step 4 Messages relating to client support are written to the CSCC transient data queue, which you must define to CICS. There is a sample definition in the supplied resource definition group, DFHDCTG. The sample defines CSCC as an indirect extra partition destination, pointing to CSSL.

Defining APPC Connections to CTRC

You must install APPC connections to define the CTRC connection to CICS. This section describes the definitions and methods for installing them.

In the CONNECTION definition you specify information about the CTRC router and how it connects to CICS. The following example shows a CONNECTION definition named CTRC. Note that the NETNAME value must be the same as the CTRC router LU name, which is CTRCBOX in this example. Setting the AUTOCONNECT option to YES allows CICS to dynamically activate the router connection. See the "Supporting CICS Security Models" section for information about specifying security parameters in the CONNECTION definition. 

DEFINE 

    CONNECTION(CTRC) 

    DESCRIPTION(CTRC)

    AUTOCONNECT(YES)

    NETNAME(CTRCBOX) 

    ACCESSMETHOD(VTAM)

    PROTOCOL(APPC) 

    SINGLESESS(NO) 

    ATTACHSEC(IDENTIFY)

    BINDPASSWORD(NO) 

    BINDSECURITY(NO) 

    USEDFLTUSER(YES)

Following is an example SESSIONS definition. Note that the value for the CONNECTION parameter must be the same as the name of the CONNECTION definition, which is CTRC for this example. 

DEFINE 

    SESSIONS(CTRC)

    CONNECTION(CTRC)

    MODENAME(IBMRDB)

    PROTOCOL(APPC)

    MAXIMUM(64,1) 

    SENDSIZE(4096)

    RECEIVESIZE(4096)

The connections can be single- or parallel-session links. Install APPC connections to CICS either by creating static definitions for the router or using an autoinstall. The installation methods are addressed in the following sections.

Creating Static Definitions for Router Connections

You can use the CICS CEDA transaction DEFINE and INSTALL commands to create static definitions. For more information about defining APPC connections, refer to the CICS Intercommunication Guide.

Using Autoinstall for Router Connections

Another method of installing router connections is to use autoinstall. If you use autoinstall you must create suitable CONNECTION and SESSIONS template definitions. For information about autoinstall and defining templates, see the CICS Resource Definition Guide. For information about customizing your autoinstall user program to handle APPC connections, see the CICS Customization Guide.

Installing Client Virtual Terminals

Virtual terminals are used by the EPI and terminal emulator functions of the CICS client products. Both IBM-supplied autoinstall programs support virtual terminal autoinstall. Refer to the CICS Customization Guide for detailed information on autoinstall for virtual terminals.

Supporting CICS Security Models

This section addresses how to configure the the Bind, Link, and User security models that are supported in CICS.

Bind Security

Bind-time security currently cannot be configured on the Cisco router. Therefore, specify BINDSECURITY(NO) in the CONNECTION definitions that define the router to CICS.

Link Security

Link security provides the lowest level of resource security for intercommunication links. It defines the total set of resources that can be accessed across the connection.

To set link security for a CICS client connection, specify a userid for the link for the SECURITYNAME option of the CONNECTION definition. Then define a profile to your External Security Manager for the link userid. Users of the connection will be able to access only those resources that the link userid is authorized to access.

If you do not specify a userid for the SECURITYNAME option, the authority of the link is that of the CICS default user.

User Security

User (attach-time) security defines how individual users of an intercommunication link are to be checked. It also affects the resources that individual users are able to access. Unless you specify LOCAL user security (in which case all potential users share the authority of the link userid), you must define user profiles to your External Security Manager.

Preparing a DB2 Host for Remote Access

CTRC provides a gateway between DRDA client requests over TCP/IP to DB2 in SNA networks. CTRC also provides full duplex TCP passthrough to DB2 systems that support direct TCP/IP access. Perform the steps in this section if you want to use CTRC to provide access to DB2 hosts. Otherwise, skip to the "Configuring the CTRC Router" section.

Defining the DB2 Subsystem to VTAM

The APPL statement defines the DB2 subsystem to VTAM to support remote access. If your DB2 system is not already supporting remote access, you must create an appropriate APPL statement.

The following is an example of an APPL statement. Make a note of the APPL statement label, which is DSNV510 in the following example, and the password, if one is specified. You need to specify the same values when you configure or update the distributed data facility (DDF) record in the Bootstrap Data Set (BSDS) as described in the next section. 

DB2APPL  VBUILD  TYPE=APPL

DSNV510  APPL    AUTH=(ACQ),

            APPC=YES,

            AUTOSES=1,

            DMINWNL=10,

            DMINWNR=10,

            DSESLIM=20,

            MODETAB=ISTINCLM,

            SECACPT=ALREADYV,

            SRBEXIT=YES,

            VERIFY=NONE,

            VPACING=2

Configuring DB2 for Remote Access

To use CTRC as a gateway between TCP/IP clients and the DB2 host, you need to configure and start DDF and define the CTRC router in the DB2 communications database table.

Configuring DDF

DB2 reads the BSDS during start up to obtain the system installation parameters. The DDF record in the BSDS contains information used by DB2 to connect to VTAM. If the DB2 system supports direct TCP/IP access, the DDF record specifies which port to use for TCP/IP communications.

If you are installing DB2, use the DDF installation panel DSNTIPR to provide the following parameters. If DB2 is already installed, use the change log inventory utility DSNJU003 to update this information in BSDS.

•DDF location name

•DDF LUNAME

•Password used when connecting DB2 to VTAM, if a password is required

•IP port to use for TCP/IP access

The following example updates the BSDS with a location name of DB2510, LU name of DSNV510 for SNA access, a password of STARPASS, and a port of 446 for TCP/IP communications. The RESPORT and PORT parameters are required only for TCP/IP access and can be omitted if using only SNA. 

//* 
//DSNTLOG EXEC  PGM=DSNJU003,COND=(4,LT)

//STEPLIB  DD  DISP=SHR,DSN=DSN510.SDSNLOAD

//SYSUT1   DD  DISP=OLD,DSN=DSN5CAT.BSDS01

//SYSUT2   DD  DISP=OLD,DSN=DSN5CAT.BSDS02

//SYSPRINT  DD  SYSOUT=*

//SYSUDUMP  DD  SYSOUT=*

//SYSIN   DD  *

        DDF LOCATION=DB2510,LUNAME=DSNV510,

          PASSWORD=STARPASS,RESPORT=5020,PORT=446

//*

LOCATION is used as the Remote Database (RDB) name. If your system does not require a password to connect DB2 to VTAM, replace the PASSWORD parameter with NOPASSWD. Note the DDF LUNAME because you must specify the same value in the SNA configuration. Also make a note of the LOCATION name because you must specify the same value as the Database Server Name during data source configuration on the desktop (described in the "Setting Up DB2 DRDA Client Connections" section).

Note You also can determine the DDF location name from the syslog. The DB2 message "DSNL004I (starting DDF)" contains the location name.

For complete information about configuring DDF, consult IBM's DB2/MVS installation documentation.

Starting DDF

Use the following command, which requires authority of SYSOPR or higher, to start DDF: 

-START DDF

When DDF starts successfully, the following messages are displayed: 

DSNL003I - DDF IS STARTING 
DSNL004I - DDF START COMPLETE LOCATION locname LU netname.luname

If DDF has not been properly installed, the START DDF command fails and displays the following message: 

DSN9032I - REQUESTED FUNCTION IS NOT AVAILABLE

If DDF has already been started, the START DDF command fails and displays the following message: 

DSNL001I - DDF IS ALREADY STARTED

Defining CTRC in the DB2 Communications Database

The DB2 host maintains a database table that defines the network attributes of remote systems. To enable communication between a CTRC client and the DB2 host, there must be an entry in this table. On DB2 for OS/390 or later versions, the name of this table is SYSIBM.LUNAMES. For DB2 on MVS v4.1, the name of this table is SYSIBM.SYSLUNAMES. Table 9 describes the table entry parameters and indicates which are applicable to one or both versions of the table.

Table 9 DB2 Communications Database Table Entry 

Parameter
SYSLUNAMES
LUNAMES
Description

LUNAME

Yes

Yes

LUNAME of the remote system. An empty string means that any LU is valid for this row.

SYSMODENAME

Yes

Yes

VTAM login mode name used for DB2 for MVS/ESA intersystem conversations. A blank frame indicates that IBMDB2LM should be used. Use the mode name specified in the logmode table.

ENCRYPTPSWDS

Yes

Yes

Indicates whether passwords exchanged with this partner are encrypted. Use the default value of NO for passing passwords between a client and DB2 host using CTRC.

MODESELECT

Yes

Yes

If `Y,' the SYSMODESELECT table is used to obtain the mode name for each outbound distributed database request. If not `Y,' the mode name IBMDB2LM is used for system-directed access requests, and the mode name IBMRDB is used for DRDA requests.

USERNAMES

Yes

Yes

Indicates the level of come-from checking and user ID translation required. It also specifies the security parameters this DB2 for MVS/ESA subsystem uses when requesting data from the remote partner (outbound security requirements). `I' indicates an "inbound" ID is subject to translation. `O' indicates an "outbound" ID, sent to the corresponding LUNAME, is subject to translation. `B' indicates that both inbound and outbound IDs are subject to translation. A blank indicates no translation for inbound or outbound IDs.

USERSECURITY

Yes

—

Network security acceptance options required of the remote system when the DB2 for MVS/ESA system acts as a server for the remote system (inbound security requirements).

SECURITY_IN

—

Yes

Defines the security options that are accepted by this host when an SNA client connects. `V' for "verify" indicates that the incoming connection request must include a password. `A' for "already verified" indicates the request does not require a password, although the password is checked if it is sent.

SECURITY_OUT

—

Yes

Defines the security option that is used when local DB2 SQL applications connect to any remote server associated with this LUNAME. `A' for "already verified" indicates that outbound connection requests contain an authorization id and no password. `P' for "password" indicates that outbound connection requests contain an authorization id and password. `R' for "RACF PassTicket" indicates that outbound connection requests contain a userid and RACF PassTicket.


The following command inserts a row into the SYSIBM.SYSLUNAMES table that any LU can use because the value of the LUNAME column is an empty string: 

INSERT INTO SYSIBM.SYSLUNAMES (LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, 
MODESELECT, USERNAMES) VALUES (' ',' ', 'C', 'N', 'N', ' ');

The following command inserts a row into the SYSIBM.LUNAMES table that any LU can use: 

INSERT INTO SYSIBM.LUNAMES (LUNAME, SECURITY_IN, ENCRYPTPSWDS, USERNAMES) VALUES (' ', 
'V', 'N', ' ');

Configuring Password Expiration Management

Users of DRDA-based applications, such as StarSQL, can change their host password using CTRC's Password Expiration Management (PEM) feature. This feature is supported by CTRC using IP passthrough and APPC. PEM support for IP passthrough is provided by DB2 for OS390 V5 or later. PEM support when using APPC is provided by either APPC/MVS or CICS.

PEM Support for IP Passthrough

There is no CTRC configuration required for PEM support as it is native in DRDA over TCP/IP. However, the DB2 host must be enabled to support PEM. To enable PEM support on DB2 for OS390 V5 or later, you must configure and use extended security using either:

•The DSNTIPR (DDF) panel on the DB2 installation dialog

•A customized configuration job DSNTIJUZ, with the option EXTSEC=YES specified

Refer to the DB2 Installation Guide for details on setting up and using extended security.

Note If you are using DB2 for OS390 V5, install the maintenance fix PTF UQ21052. The IBM APAR PQ15977 describes the problems fixed by this PTF. This maintenance fix is not required for later releases.

PEM Support for APPC

The CTRC PEM support over APPC is implemented using SNA architecture TPs. Therefore, CTRC requires that a surrogate subsystem such as APPC/MVS or CICS be used to change passwords. Both APPC/MVS and CICS support the SNA architecture TPs.

To allow PEM support for DB2 connections, use the dbconn pem command to turn on PEM support as needed for the CTRC routers handling the connections. In the dbconn pem command statement, specify the LU name of the APPC/MVS base configuration. APPC/MVS configuration statements are in SYS1.PARMLIB(APPCPMxx). Consult your MVS systems programmer to obtain the name of the target LU that will be used by CTRC. The PEM support does not require any explicit definitions of the SNA architecture TPs. The following example shows a LUADD statement, such as found in SYS1.PARMLIB. 

LUADD ACBNAME(MVSLU01) BASE TPDATA(SYS1.APPCTP)

The following is an example VTAM APPL definition for the APPC/MVS LU: 

MVSLU01   APPL    ACBNAME=MVSLU01,   ACBNAME FOR APPC

             APPC=YES,

             AUTOSES=0,

             DDRAINL=NALLOW,

             DLOGMOD=IBMRDB,

             DMINWNL=5,

             DMINWNR=5,

             DRESPL=NALLOW,

             DSESLIM=10,

             LMDENT=19,

             PARSESS=YES,

             SECACPT=CONV,

             SRBEXIT=YES,

             VPACING=1

Another alternative for providing PEM support is through the CICS support for SNA architecture TPs, which is provided in resource group DFHISC. To use this method, define the connection to CTRC as described in the "Defining APPC Connections to CTRC" section, and use the CICS APPLID as the rlu value in the dbconn pem command.

Configuring the CTRC Router

After you define the CTRC router to VTAM and prepare the CICS and DB2 hosts for remote access, you must configure the router.

Configuring CTRC for CICS Communications

To configure CTRC to communicate with CICS, you must define a destination and specify a particular server process. You also can define specific routes to be used for particular transaction programs.

Configuring a CTRC Destination for CICS

To configure CTRC to communicate with CICS, you must configure a CTRC destination. A CTRC destination is typically a single CICS system defined in terms of its remote LU name and APPC mode. To configure a destination, use the following global configuration command:

Command
Purpose

Router(config)# txconn destination destination-name

rlu rlu-name mode mode-name

Specifies a CICS system with which CTRC will communicate.


If you want to assign more than one CICS system or region to a single CTRC destination name, such as to help balance the workload, repeat the txconn destination command with the same destination name and different remote LU and mode values. If a CTRC destination is configured in this way, the CTRC server sends traffic to the destination's defined CICS regions on a rotating basis. A Cisco router can be configured to communicate with multiple CTRC destinations, whether each of those destinations is defined as an individual pair of remote LU and mode values or as a set of such values.

Configuring a CTRC Server for CICS

After you have configured a CICS destination, configure a CTRC server process to handle communications with that CICS system. Additional CTRC servers can be configured on the same router for communications with other CICS destinations. To configure a CTRC server process to communicate with CICS, use the following global configuration command:

Command
Purpose 
Router(config)# txconn server server-name destination 
destination-name [access {cics | comti}] [client-timeout 
minutes] [ccsid number] [host-timeout minutes] [ipaddress 
ip-address] [keepalive attempts number] [keepalive interval 
seconds] [port port-number] [target {cics | ims-tm}] 
[window-size bytes][fold {on | off}]

Configures a CTRC server process for communicating with CICS. If you do not supply a port number, CTRC uses the default value of 1435.


When a client attempts to connect to a CTRC server for CICS, the server's port and IP address determine whether that connection is accepted. By default, the CTRC server port for CICS client communications is 1435. You can create multiple CTRC server processes for both CICS and DB2 on one router.

Configuring a CTRC Route for CICS

After you have configured one or more destinations and server processes for communicating with CICS, you have the option of explicitly configuring CTRC routes that will direct traffic to the appropriate destination based on a transaction ID. If you do not explicitly configure CTRC routes, the CTRC server routes traffic to its own defined default destination. To configure a CTRC route, use the following global configuration command:

Command
Purpose

Router(config)# txconn route [server server-name] tranid transaction-id destination destination-name

Configures a particular route for traffic with the specified transaction ID.


Configuring CTRC for DB2 Communications

To configure a CTRC server process for APPC communications with DB2, use the dbconn server command in global configuration mode. To configure a CTRC server to communicate with an IP-enabled DB2 database, use the dbconn tcpserver global configuration command.

Command
Purpose 
Router(config)# dbconn server server-name [idle-timeout 
minutes] [ipaddress ip-address] [keepalive attempts 
number] [keepalive interval seconds] [mode mode] [port 
port-number] [rdbname rdbname] [rlu remote-lu] [tpname 
tp-name] [window-size bytes][wlm {off | on}]

Configures a CTRC server for APPC communications with DB2. 

Router(config)# dbconn tcpserver 
server-name remote-hostname remote-hostname|remote-ip 
remote-ipaddress [idle-timeout minutes] [ip ip-address] 
[keepalive attempts number] [keepalive interval seconds] 
[port port-number] [rdbname rdbname] [remote-keepalive 
attempts number] [remote-keepalive interval seconds] 
[remote-port remote-port] [window-size bytes][wlm {off | 
on}

Configures a CTRC server to communicate with IP-enabled DB2 databases.


When a client attempts to connect to a CTRC server for DB2, the server's port, IP address, and RDB name determine whether that connection is accepted. By default, the CTRC server port for client requests for DB2 communications is 446. You can create multiple CTRC server processes for both CICS and DB2 on one router.

Configuring SNA Switching Services

CTRC uses the SNA Switching Services (SNASw) of the Cisco router. Even if you do not need to convert client messages received over TCP/IP to SNA messages (such as in a TCP/IP passthrough topology), SNASw must be present, and you must specify a CPNAME for the CTRC router. The following command illustrates the minimal SNASw configuration required to enable the CTRC license: 

snasw cpname netid.cpname

To configure basic SNASw, complete the following steps beginning in global configuration mode:

 
Command
Purpose

Step 1 

Router(config)# snasw cpname {netid.cpname | netid [hostname | ip-address interface-name]}

Defines an SNASw control point name. For the netid.name variable, specify the fully qualified CP name for the router, which consists of both network ID and cpname.

Step 2 

Router(config)# snasw port portname [hpr-ip | vdlc ring-group mac mac-address] interfacename [conntype nohpr | len | dyncplen] [nns-required] [hpr-sap hpr-sap-value] [max-links link-limit-value] [maxbtu max-btu-size] [sap sap-value] [vnname virtual-node-name] [nns][nostart]

Associates an SNASw port with an interface.

Step 3 

Router(config)# snasw link linkname port portname rmac mac-address | ip-dest ip-address [rsap sap-value] [nns] [tgp [high | low | medium | secure]] [nostart]

Configures upstream links.

Note For a LEN-level connection between SNASw and the host, you also need to configure the snasw location configuration command for the specific resource names to be contacted on the host. Do not define locations if APPN connectivity is being used between SNASw and the host. See the "Cisco IOS Software Configuration" section for an example of the SNASw configuration statements.

For additional information about configuring SNASw, consult the SNA Switching Services chapter of this document.

Configuring the CTRC License

An unlicensed installation of CTRC allows up to two DB2 connections, two CICS conversations, or one DB2 connection and one CICS conversation for evaluation purposes. To use more than two connections or conversations, you must configure the CTRC license.

The CTRC license key is locked to one node and is based on the SNASw control point name (cpname) for the router. Use the show config | include cpname command to determine the cpname for the router you want to license. Then contact your Cisco representative and request a CTRC license key. You will receive a license key along with information about the number of connections you are licensing and, if the license has a time limit, the expiration date.

For communications with DB2, CTRC checks the number of connections in use against the licensed number of connections. For communications with CICS, CTRC checks the number of concurrent and queued conversations. One license key is used for both CICS and DB2 communications, so you can use either of the following global configuration commands to configure the CTRC license. If your license is not for an unlimited number of connections and period of time you must specify the number of connections and expiration date.

Command
Purpose

Router(config)# dbconn license license-key [connections licensed-connections] [expiration-date yyyymmdd]

Configures a CTRC license.

Router(config)# txconn license license-key [connections licensed-connections][expiration-date yyyymmdd]

Configures a CTRC license.


Verifying the CTRC Configuration

After preparing the host systems and configuring the CTRC router, perform the following steps to ensure CTRC can communicate with the host systems:

Step 1 To verify that you have SNA connectivity between the router and each host system, use the ping sna command, specifying the mode and the fully-qualified remote LU name appropriate for your environment in place of IBMRDB and STARW.BUDDY in the following example. 

ping sna -m IBMRDB STARW.BUDDY

Step 2 If you configured CTRC for communications with CICS, perform the following steps to verify the router is properly configured. Skip to Step 3 if you are using CTRC only for DB2 communications.

a. Enter the show txconn destination command in EXEC or privileged EXEC mode. Make sure that all CICS destinations you configured are listed with the RLU and mode values you specified. 

Router# show txconn destination

Name              Remote LU          Mode        Hits

----------------- ------------------ ----------- --------

CICSB             CICSB              IBMRDB    0

GEN               CICSB              IBMRDB    0

                  CICSC              IBMRDB    0

GUAVA             GUAVA              IBMRDB    0

CICSC             CICSC              IBMRDB    0

b. For each CICS destination shown in the previous step, enter the txconn ping command to verify that the router can communicate with that destination. 

Router# txconn ping CICSB

Trying CICSB CICSB:IBMRDB

Destination CICSB successfully contacted!

Elapsed time was 00:00:00.600

c. Enter the show txconn server command. Make sure that all CTRC servers you defined for communications with CICS are listed with the configuration values you specified. 

Router# show txconn server

Server     Port  IP Address   Dest      State     NumConn

---------- ----- ------------ --------- --------- -------

CICSB      1435  0.0.0.0      CICSB     enabled   0

CICSB&C    1436  0.0.0.0      GEN       enabled   0

CICSC      1434  0.0.0.0      CICSC     enabled   0

GUAVA      1437  0.0.0.0      GUAVA     enabled   0

Use the show txconn server server-name form of the command to display detailed information for an individual server. 

Router# show txconn server CICSB

                  server: CICSB

             destination: CICSB

            server state: enabled (accepting connections)

              ip address: 0.0.0.0

                    port: 1435

          client timeout: 0 (none)

            host timeout: 0 (none)

             window size: 4096 bytes

       fold program name: on

            CCSID: 037

   number of connections: 0

   number of transactions: 0

         client type: CICS

d. If you defined any routes for specific transaction IDs to take to CICS destinations, enter the show txconn route command. Make sure that all CTRC routes you defined are listed with the configuration values you specified. A <default> in the SERVER column indicates a global route that can be used by all txconn servers on the router. A <default> in the TranID column indicates the default route for the listed txconn server. 

Router# show txconn route

Server            TranID            Destination

----------------- ----------------- ----------------

CICSC             <default>         CICSC

CICSB             <default>         CICSB

CICSB&C           <default>         GEN

GUAVA             <default>         GUAVA

<default>         CPMI              CICSC

CICSB             CPMI              CICSB

Step 3 If you configured CTRC for communications with DB2, perform the following steps to verify the router is properly configured. If you are using CTRC only for CICS communications, skip to Step 4.

a. Enter the show dbconn server command. Make sure the servers you defined are listed with the configuration values you specified. 

Router# show dbconn server

Server      Port   IPAddress      RDBName     State     NumConn

SERVERA     446    0.0.0.0        MATTY       enabled   0

SERVERB     446    0.0.0.0        SCU_DSNM    enabled   0

SERVERC     446    0.0.0.0        DSN4        enabled   0

SERVERD     446    0.0.0.0        MKTG        enabled   0

SERVERE     446    0.0.0.0        ABBY        enabled   0

SERVERF     446    0.0.0.0        DB2510      enabled   0

SERVERG     446    0.0.0.0        ELLE        enabled   0

SERVERH     446    0.0.0.0        SUNSET      enabled   0

SERVERI     446    0.0.0.0        NELL        enabled   0

SERVERJ     446    198.989.999.32 SAMPLE      enabled   0

SERVERK     446    0.0.0.0        DB2410      enabled   0

SERVERL     446    0.0.0.0        SQLDS       enabled   0

SERVERM     446    0.0.0.0        STELLA      enabled   0

SERVERN     446    10.10.19.4     OAK         enabled   0

SERVERO     447    0.0.0.0        DB2510      enabled   0

BUDDY       446    0.0.0.0        DB2510      enabled   0

Use the show dbconn server server-name form of the command to display more information for an individual server. 

Router# show dbconn server BUDDY

                 server: BUDDY

           server state: enabled (accepting connections)

             ip-address: 0.0.0.0