Table Of Contents
Configuring Cisco Transaction Connection
Technology Overview
Using CTRC for CICS Access
Using CTRC for DB2 Access
Configuration CTRC Tasklist
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 II. 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 Tasklist
•
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
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
•
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 web site on Cisco Connection Online (CCO) at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
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 transmit 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 Tasklist" 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 "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)
Configuration CTRC Tasklist
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, which are described in more detail on the pages referenced:
•
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:
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.
•
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
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,
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
CTRCCIP PATH GRPNM=G02E20A,CALL=IN
CTRCBOX LU LOCADDR=00, INDEPENDENT LU
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).
CICSB APPL AUTH=(ACQ,SPO,PASS,VPACE),
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.
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:
DFHCNV TYPE=INITIAL,SRVERCP=037,CLINTCP=437
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.
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.
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 DDF record in the Bootstrap Data Set (BSDS) as described in the next section.
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
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:
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 8 describes the table entry parameters and indicates which are applicable to one or both versions of the table.
Table 8 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 appropriate 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
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. Use the following global configuration command to configure a destination:
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. Use the following global configuration command to configure a CTRC server process to communicate with CICS:
Command
|
Purpose
|
Router(config)# txconn server server-name destination
destination-name [access cics | comti][ccsid
number][ipaddress ip-address] [port port-number]
[client-timeout minutes] [host-timeout minutes] [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 [ipaddress
ip-address] [port port-number] [rdbname rdbname] [rlu
remote-lu] [mode mode] [tpname tp-name] [idle-timeout
minutes] [window-size bytes][wlm [off|on]]
|
Configures a CTRC server for APPC communications with DB2.
|
Router(config)# dbconn tcpserver server-name [ip
ip-address] [port port-number] [rdbname
rdbname remote-hostname remote-hostname|remote-ip
remote-ipaddress [remote-port remote-port] [idle-timeout
minutes] [window-size bytes][wlm [off|on]]
|
Configures a CTRC server for TCP/IP communications with DB2. You must specify either the remote-hostname or the remote-ip parameters.
|
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:
To configure basic SNASw, complete the following steps beginning in global configuration mode:
| |
Command
|
Purpose
|
Step 1
|
Router(config)# snasw cpname netid.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]
[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]
|
Associates an SNASw link with an SNASw port. If the partner node is initiating the connection, a link definition is not necessary as the link will be built dynamically when the partner node initiates the connection. Links are typically defined to configure upstream connections to SNA data hosts, services, and DLUS nodes.
|

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
----------------- ------------------ ----------- --------
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 state: enabled (accepting connections)
number of transactions: 0
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
----------------- ----------------- ----------------
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 communciations, skip to Step 4.
e.
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 state: enabled (accepting connections)
database server name: (unknown)
database product id: (unknown)
f.
For each dbconn server shown in the previous step, enter the dbconn ping command to verify that the router can communicate with the DB2 systems associated with that server.
Router# dbconn ping BUDDY
RDB named DB2510 on database server BUDDY successfully contacted!
Elapsed time was 00:00:00
Step 4
Verify that the CTRC license configuration matches the number of licensed connections that you purchased. Enter either the show dbconn license command or the show txconn license command as shown below.
Router# show txconn license
Router# show dbconn license
The command displays information about the license, as shown in the following example:
CTRC is licensed for 4990 connections, no licensed connections in use
This is a permanent license
Configuring CTRC Clients
This section provides information about setting up DRDA client connections for DB2 access, and for setting up the supported CICS clients.
Setting Up DB2 DRDA Client Connections
To configure a connection between a DRDA-based client and a DB2 database, you must define a data source to the ODBC driver. For each DB2 database that will be accessed, you need to specify the following data source information to configure the DRDA requestor to use the CTRC router:
•
The RDB name of the DB2 database you want to access. This value must match the rdbname that you specify with the dbconn server command to configure the CTRC router for communicating with DB2 (see the "Configuring CTRC for DB2 Communications" section). The RDB name also must match the DDF location defined on the DB2 host (see the "Configuring DDF" section).
•
The router's host name or the IP address of the interface that will accept the connection requests.
•
The port number on which the CTRC router is listening for connection requests. The default is 446.
The procedures for configuring a data source are specific to the client implementation. Refer to the documentation for your DRDA client for details.
Setting Up CICS Clients
CTRC supports IBM CICS Universal Client, IBM TXSeries, and Microsoft COMTI clients. These clients connect to the Cisco router via TCP/IP.
Setting Up CICS Universal Client Connections
To set up the CICS Universal Client, perform the following tasks:
Step 1
Install the Universal Client for your platform.
Step 2
Choose TCP/IP as your network connection.
Step 3
To have the Universal Client connect to your CTRC server, add an entry in the Server section of the CICSCLI.INI file to define the CTRC server. The following example entry defines a server named CTRCSERV with a TCP/IP hostname (NetName) of CTRCBOX. Substitute the LU name of your router for the NetName.
Description = TCP/IP Server
Step 4
If necessary, stop and restart the Universal Client to have the changes take effect and connect to the CTRC server.
To connect through multiple servers, increase the MaxServers value in the Client section of the CICSCLI.INI file from the default of 1. If you have multiple servers configured in CICSCLI.INI, some applications may display a list of servers from which to choose. If security is turned on in CICS, a user/password dialog may appear after selecting a CICS Server.
If you have specified UseDfltUser=NO and AttachSec=Verify in your APPC CONNECTION definition on CICS (see the "Defining APPC Connections to CTRC" section), a userid and password will be required to use the CICS Terminal. If you are using ECI, pass the userid and password using a command such as:
<