|
|
This chapter describes how to configure the Cisco Database Connection feature. For a complete description of the Database Connection commands in this chapter, refer to the "Cisco Database Connection Commands" chapter of the Bridging and IBM Networking Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
The Database Connection feature enables Cisco routers to implement IBM's distributed relational database architecture (DRDA) level 3 over the Transmission Control Protocol/Internet Protocol (TCP/IP). The Cisco router with Database Connection exists in the TCP/IP network, and clients use the Database Connection IP address and port on the router to connect to the IBM host system that exists in the Systems Network Architecture (SNA) network.
When Database Connection is configured on a router, client-based Open Database Connectivity (ODBC) applications can connect to IBM's family of IBM D2 relational databases, which include:
Figure 153 illustrates how the Cisco router configured with the Database Connection feature enables the exchange of database information between ODBC client applications running DRDA in a TCP/IP network and a DRDA-based IBM system that accesses DB2 relational data.
When configured on a router, the Database Connection feature enables desktop applications to access data in remote databases located on IBM hosts. Database Connection receives database access messages from the client over a TCP/IP link. Database Connection converts the messages to SNA and transmits them to the host using APPC services provided by the Cisco IOS Advanced Peer-to-Peer Networking (APPN) software.
Figure 154 shows a user working with a spreadsheet application on a PC and accessing database information from a remote relational database management system (RDBMS) on an IBM host. When the user seeks data from the RDBMS system on the IBM host, the spreadsheet application sends SQL statements to the remote host system and retrieves the data.
To use the Database Connection feature, the following prerequisites must be met:
The following DB2 software packages are supported:
The Database Connection feature is supported on the following platforms and is available in the specified Cisco IOS Release software images:
To configure the Database Connection feature on a Cisco router, perform the tasks in the following sections:
See the end of this chapter for Database Connection Configuration Examples.
To define an APPN control point, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
appn control-point netid.cpname | Define an APPN control point. |
Entering this command takes you from global configuration mode into APPN control point configuration mode.
| Command | Purpose |
|---|---|
appn port portname interface | Define an APPN port associated with an interface. |
A link station is a representation of the connection or potential connection to another node. In many cases, if the partner node is initiating the connection, a link station definition is not necessary. It will be built dynamically when the partner node initiates the connection. You must define a link station if you want this node to initiate APPN connections with other nodes. In addition, you may define a link station to specify attributes of an APPN connection regardless of which node initiates the connection.
To define an APPN logical link, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
appn link-station linkname | Define an APPN logical link. |
Entering this command takes you from global configuration mode into APPN link station configuration mode. From the APPN link station configuration mode, you must associate the link station with an APPN port that it will use.
To associate a link station, use the following command in APPN link station configuration mode:
| Command | Purpose |
|---|---|
port portname | Associate a link station with the APPN port that it will use. |
Use an APPN mode definition to associate a mode name received on an APPN search or session request with a class of service known to this node. Most APPN nodes will supply the class of service to their network node server, so mode definition may not be required in many APPN networks. However, if the node is providing network node services to an end node that does not supply a class of service, or if the node is providing network node services for a low-entry networking (LEN) node, mode definitions may be required for each mode that is used by the partner node.
Cisco provides standard predefined mode definitions for modes that are commonly used in an APPN network. The predefined mode names are:
You can change a predefined mode or define a new mode.
To define an APPN mode, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
appn mode modename | Define an APPN mode. |
Entering this command takes you from global configuration mode into APPN mode configuration mode. Within this mode, you must assign a class of service to the mode definition.
To assign a class of service to the mode definition, use the following command in APPN mode configuration mode.
| Command | Purpose |
|---|---|
class-of-service cosname | Associate a class of service with the defined mode. |
Use the following commands to allow for the addition, removal, or completion of configuration items within the APPN mode configuration mode:
| Command | Purpose |
|---|---|
no command | Negate or restore the default value for a configuration command. |
complete | Complete the APPN mode definition, return to global configuration mode, and update the APPN subsystem. |
no complete | Allow modifications to a previously completed APPN mode definition. |
exit | Exit APPN class of service definition dialog without completing the definition and without updating the APPN subsystem. |
Defining the APPN partner logical unit (LU) location is optional for the Database Connection feature. The APPN directory stores names of resources and their owners. Usually this information is learned dynamically via APPN searches. However, you may wish to manually define the location of specific resources. Doing so can improve network performance by allowing directed APPN searches to travel straight to the owning control point, without the need for an initial broadcast search for the resource. However, APPN is known for its dynamic capabilities, not its need for system definition. For this reason, and for easier manageability, it is good practice to define location names only when necessary.
If you do not use APPN in your SNA environment, you must configure an APPN partner LU location and specify the destination LU and D2 for Database Connection in the router configuration.
When a LEN node is attached to an APPN network node, all destination resources that reside on the LEN node must be defined on the network node to be reachable via the APPN network.
To define a partner LU location, use the following command in global configuration mode:
| Command | Purpose |
|---|---|
appn partner-lu-location netid.luname | Specify the partner resource name. |
Specifying the partner resource name takes you from the global configuration mode into the APPN partner LU location configuration mode.
You must configure an owning control point for each partner LU configured. The owning control point is the control point name for the LEN, end node, or network node on which the resource resides.
To specify the name of the control point owning the partner LU, use the following command in APPN partner LU location configuration mode:
| Command | Purpose |
|---|---|
owning-cp netid.cpname | Specify the name of the control point owning the partner LU. |
If this node is not the network node server for the resource, you may also configure the network node server name. To reduce APPN searching, the network node server operand must be coded and must be the current server for the resource.
If this node is the network node server for the resource being defined, do not configure a network node server.
To specify the name of the network node server for the resource, use the following command in APPN partner LU location configuration mode:
| Command | Purpose |
|---|---|
serving-nn netid.cpname | Specify the name of the network node server for the resource. |
A partial name wildcard partner LU is a definition that applies to all resources that match a partial name. For example, a definition for location NETA.PE, which is specified as a wildcard definition, serves as an entry for NETA.PEANUT and NETA.PENNY, but not NETA.PUMKIN. Be careful when using partial name wildcards because they can easily cause network problems if resources that match the partial name do not actually exist in the specified location.
A full wildcard partner LU definition is specified by defining a partner LU location without specifying a resource name and specifying the wildcard option. Full wildcards answer positively to any search for any resource in the network. Only one full wildcard definition can exist in an APPN network. Full wildcards are sometimes used when the APPN subnetwork is small and an attached LEN node is the gateway to a large connected network. Full wildcard definitions reduce APPN performance and can cause a variety of network problems. Hence, use of full wildcard definitions should be avoided.
To specify a partial name or full wildcard partner LU, use the following command in APPN partner LU location configuration mode:
| Command | Purpose |
|---|---|
Specify the entry as a partial-name wildcard or a full wildcard. |
Use the following commands to allow for the addition, removal, or completion of configuration items within the APPN partner LU location configuration mode:
| Command | Purpose |
|---|---|
no command | Negate or restore the default value for a configuration command. |
complete | Complete the APPN partner LU definition, return to global configuration mode, and update the APPN subsystem. |
no complete | Allow modifications to a previously completed APPN partner LU definition. |
exit | Exit APPN partner LU definition dialog without completing the definition and without updating the APPN subsystem. |
To configure a Database Connection server on a Cisco router, use the following command in privileged EXEC mode:
| Command | Purpose |
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] | Configure a Database Connection server. |
When a client attempts to connect to a Database Connection server, the server's port, IP address, and remote database name (RDB name) determine whether that connection is accepted or not. By default, the port for Database Connection servers is 446. There is no limit on the number of Database Connection Servers.
You can configure Database Connection servers and specify any of the options used by the servers when accepting connections.
If you are using StarSQL or StarSQL Pro software, use the following command in privileged EXEC mode to configure the Database Connection license for StarSQL clients:
| Command | Purpose |
dbconn license license-key | Configure a Database Connection license key. |
The license key is available from StarQuest Software, Inc. Skip this task if you are not using StarSQL or StarSQL Pro products.
APPN port and link station definitions are started automatically when the APPN subsystem starts. However, configuration commands will not take effect on an APPN port or link when it is active. To start or stop an APPN port or link station, use the following commands in privileged EXEC mode:
| Command | Purpose |
|---|---|
appn stop link-station linkname | Deactivate the specified APPN link. |
appn stop port portname | Deactivate the specified APPN port. |
appn start link-station linkname | Activate the specified APPN link. |
appn start port portname | Activate the specified APPN port. |
To monitor and maintain Database Connection configured on a router, use one or more of the following commands:
| Command | Purpose |
|---|---|
Display a summary of each Database Connection server. | |
show dbconn server server-name | Display a detailed status of the specified Database Connection server. |
show dbconn connection | Display the status of each connection. |
show dbconn connection connection-id | Display a detailed status of the specified Database Connection connection. |
show dbconn connection server server-name | Display the status of the Database Connection connection server. |
show dbconn connection user userid | Display the status of a user connected to the Database Connection. |
show dbconn connection rdbname rdb-name | Display a status of each connection that matches the specified RDB name. |
show dbconn ports | Display information on all ports through which Database Connection servers are accepting connections. |
Display the status of dbconn license for StarSQL. | |
clear dbconn connection connection-id | Break the specified client connection to the server. |
dbconn ping server-name [rdbname rdbname] [userid userid] [password password] | Connect to the relational database on the IBM system for troubleshooting. |
debug dbconn {appc | config | drda | event | tcp | all} | Enable debugging. |
Displays current status of debugging for Database Connection. |
The following sections provide Database Connection configuration examples:
Figure 155 shows a Database Connection configuration where the Database Connection servers are configured to listen on port 446 (by default) for IP addresses specified for these servers in the router's configuration for Database Connection. When a client attempts to make a connection, a Database Connection server accepts the connection if the IP address specified in its configuration matches the IP address to which the client wants to connect.
In this illustration, Servers A and B are configured with IP addresses 172.0.10.2 and 172.0.45.3. Servers A and B accept any connection that targets their IP addresses. Server C accepts any connection that targets any IP address of router on the target port of 446 and an RDB name of IOWA.
The following are the configurations for servers Server A, Server B, and Server C in the Cisco router's configuration:
dbconn server SERVERA ip-address 172.0.10.2 rdbname nevada dbconn server SERVERB ip-address 172.0.45.3 dbconn server SERVERC rdbname iowa
When a client request comes in for a server, and multiple servers are configured in the router, the three configured attributes of IP address, RDB name, and port determine which server is chosen for the connection. When a server is selected for a connection, the client remains associated with that server for the duration of that connection. The APPC attributes configured for that server are used to connect to the IBM system. If a server is unconfigured while active connections exist, the active connections with that server will break.
Only one Database Connection server can be configured with a unique combination of IP address, port, and RDB name. If a situation arises where multiple servers in a router meet the criteria for accepting a client connection, the Database Connection server that meets the most specific criteria accepts the connection. For example, Servers A and B in Figure 156 are listening on port 446 for client connections that match their IP address of 161.55.122.80. Server A is configured to accept RDB name NEVADA and Server B is configured to accept any RDB name. A client connecting to port 446 for RDB name NEVADA matches the criteria for both servers. In this situation, Server A is selected to accept the connection because its configuration includes a specific RDB name NEVADA as compared to Server B whose configuration accepts any RDB name.
The IP address and port specified for a server in a router's configuration also determine which server accepts a connection. For example, Server C is configured to listen on any local IP address on port 446 and RDB name IOWA. Server D is configured to listen for IP address 145.56.180.34 on port 446 and RDB name IOWA. When a client attempts to connect to IP address 145.56.180.34 on port 446 for RDB name IOWA, both servers meet the criteria in accepting the connection. In this case, Database Connection selects a connection based on the IP address first, then the port, and finally, the RDB name.
If multiple servers in a router meet the criteria for accepting a client connection, the Database Connection server that meets the most specific criteria accepts the connection. In Figure 157, the Cisco router contains four server configurations. All four servers listen for client connections on port 446 by default. Both Servers A and B are configured with the same IP address, 161.55.122.80. Servers A and C are configured to accept RDB name NEVADA. Servers B and D are configured to accept any RDB name.
If a client connects to IP address 161.55.122.80 on port 446 and sends RDB name NEVADA in the DRDA data stream, all four servers match the criteria for accepting the client connection. However, Server A will be selected to accept the connection because it meets the most specific criteria for IP address, RDB name, and port. If Server A was not configured, Server B would be the second choice because it meets the criteria for the IP address and port. The IP address specified in a server always has the highest precedence when matching a connection to a server.
The following is the configuration for Servers A, B, C, and D in the Cisco router:
hostname routera ! enable password allie dbconn server SERVERA ip-address 161.55.122.80 rdbname NEVADA dbconn server SERVERB ip-address 161.55.122.80 dbconn server SERVERC rdbname NEVADA dbconn server SERVERD
Figure 158 illustrates a Cisco router with a Channel Interface Processor (CIP) that is configured with Database Connection. The CIP is networked and connected to VTAM on the mainframe. DB2 is configured on VTAM.
The configuration in Figure 158 uses router commands to configure APPN over CIP and CSNA via RSRB. Note that the source-bridge ring-group of 100 matches the source bridge of 10 2 100 for interface Channel 13/2 to enable APPN to run over RSRB. In addition, the destination LAN address used by the APPN link station MVS1 corresponds to the virtual MAC address used by the adapter for Channel 13/2.
In the VTAM host definitions, the variable CONNTYPE=APPN is optional but recommended if you use APPN in your SNA environment. If CP to CP is set to YES and CONNTYPE is set to APPN, this configuration enables the Cisco router to establish CP to CP sessions with VTAM. By allowing CP to CP sessions, you gain the benefit of APPN's dynamic features such as the availability of directory and topology for locating resources and calculating optimal routes.
! version 11.3 service password-encryption service udp-small-servers service tcp-small-servers ! hostname smoke ! enable password 7 11051807 ! microcode CIP flash slot0:cip22-14 microcode reload ip subnet-zero no ip routing ! dbconn server BUDDHA rdbname DB2510 rlu STARW.DSNV510 mode LU62STAR ! interface TokenRing0/0 mac-address 4000.2222.0501 ip address 10.10.22.1 255.255.255.0 no ip route-cache no ip mroute-cache early-token-release ring-speed 16 multiring all ! interface TokenRing0/1 mac-address 4000.1111.0501 ip address 198.147.235.196 255.255.255.224 no ip route-cache no ip mroute-cache early-token-release ring-speed 16 multiring all ! source-bridge ring-group 100 ! interface Channel13/0 no ip address no keepalive shutdown ! interface Channel 13/1 no ip address no keepalive csna F010 38 ! interface Channel 13/2 no ip address no keepalive lan TokenRing 1 source bridge 10 2 100 adapter 1 4000.0190.2001 ! appn control-point STARW.SMOKECP xid-block-number 05E xid-id-number 00002 complete ! appn mode LU62STAR class-of-service #INTER complete ! appn port TOK1 TokenRing0/1 complete ! appn port TOK0 TokenRing0/0 complete ! appn port SRB rsrb rsrb-virtual-station 4000.2222.3333 50 1 100 complete ! appn link-station MVS1 port SRB lan-dest-address 4000.0190.2001 adjacent-cp-name NETA.MVS1 complete ! appn link-station BUDDHA port TOK1 lan-dest-address 4000.0200.0448 retry-limit infinite complete ! appn partner-lu-location STARW.DSNV510 / DB2 APPL owning-cp STARW.BUDDHA / VTAM NetID complete ! appn routing ip default-gateway 198.147.235.12 no ip classless logging monitor informational ! line con 0 exec-timeout 0 0 line aux 0 transport input all line vty 0 4 exec-timeout 0 0 password 7 11051807 login !
>Switched Major Node 000042 P0202 PU ADDR=C1, Router SMOKE X 000043 IDBLK=05E, X 000044 IDNUM=00002, X 000045 PUTYPE=2, X 000046 MAXDATA=1456, X 000047 USSTAB=STARSNA, X 000048 MODETAB=AGWTAB, X 000049 CPNAME=SMOKECP, X 000050 CONNTYPE=APPN 000051 * 000052 L02T0201 LU LOCADDR=000, Independent LU X 000053 MODETAB=AGWTAB, X 000054 MAXSESS=1024, X 000055 DLOGMOD=LU62STAR,PACING=1,VPACING=1
DB2 APPL 000100 DSNAPPL VBUILD TYPE=APPL 000200 DSNV510 APPL APPC=YES, X 000300 AUTH=ACQ, X 000400 AUTOSES=1, X 000500 DMINWNL=2048, X 000600 DMINWNR=2048, X 000700 DSESLIM=4096, X 000800 EAS=65535, X 000900 MODETAB=AGWTAB, X 001000 SECACPT=ALREADYV, X 001100 SRBEXIT=YES, X 001200 VERIFY=NONE, X 001300 VPACING=1, X 001400 SYNCLVL=SYNCPT, X 001500 ATNLOSS=ALL
|
|