|
|
This chapter highlights the tasks involved in preparing DB2 and an MVS host to accept connections through the CTRC router. If you are using direct TCP/IP to connect to the MVS host, you can skip this chapter, although you do need to configure the CTRC license and the SNA Switching Services to support the TCP/IP connections (see the "Cisco Transaction Connection" section of the
Cisco IOS Bridging and IBM Networking Configuration Guide).
Preparing DB2 on an MVS host for access through CTRC primarily involves configuring the Distributed Data Facility (DDF). DDF is the component of DB2/MVS that processes Distributed Relational Database Architecture (DRDA) requests. DDF must be active for a desktop to connect to DB2 using StarSQL or any other DRDA requestor client. If your organization has not implemented distributed database capabilities, DDF might not be configured and active.
This section highlights the tasks that are especially important for supporting a connection through CTRC:
VTAM handles network communications for MVS for direct VTAM and SNA gateway configurations. The VTAM system programmer creates a mode table entry and major node definitions in VTAM for the CTRC connection. The following sections provide information about the mode table entry and major node definitions required for CTRC. Consult the VTAM documentation for detailed information about configuring VTAM, which also may be referred to as eNetwork Communications Server for OS/390.
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 (see the "APPL Statement" section) for the LU definitions for DB2.
Following example shows a mode table entry for APPC, with a LOGMODE name of IBMRDB. Make a note of the LOGMODE name, because you need to 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 LU 6.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'
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.
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,
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. See the "Switched Major Node for Router" section for additional configuration examples.
The following example shows 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).
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
To obtain system installation parameters during startup, DB2 reads the BSDS. The DDF record in the BSDS contains information used by DDF to connect to VTAM.
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.
Record the DDF location name. You will use it for the Database Server Name during data source configuration on the desktop. You also can determine the DDF location name from the syslog. Look for a DB2 message DSNL004I (starting DDF) that contains the location name. Also record the DDF LUNAME, which you will need for SNA configuration.
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 for TCP/IP access. If you are using SNA only, then you can omit them.
//*
//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
//SYSPRINTDD SYSOUT=*
//SYSUDUMPDD SYSOUT=*
//SYSIN DD *
DDF LOCATION=DB2510,LUNAME=DSNV510,
PASSWORD=STARPASS,RESPORT=5020,PORT=446
//*
LOCATION is used as the RDB name. If your system does not require a password to connect DB2 to VTAM, replace the PASSWORD parameter with NOPASSWD. For complete information about configuring DDF, consult IBM's DB2/MVS installation documentation.
Use the following command to start DDF:
-START DDF
This command requires authority of SYSOPR or higher.
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
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, the name of this table is SYSIBM.LUNAMES. For DB2 on MVS version 4.1, the name of this table is SYSIBM.SYSLUNAMES. Table 2-1 describes the table entry parameters and indicates which are applicable to one or both versions of the table.
| Parameter | SYSLUNAMES | LUNAMES | Description |
|---|---|---|---|
LUNAME | LUNAME of the remote system. An empty string means that any LU is valid for this row. | ||
SYSMODENAME | VTAM logon 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 modetab. | ||
ENCRYPTPSWDS | 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 | 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 | 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 and 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 |
| 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 |
| 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 |
| 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', ' ');
Users of DRDA 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 pass through and APPC. CTRC's PEM support for IP pass through is provided for DB2 for OS390 V5 or later. PEM support when using Advance Program-to-Program Communications (APPC) is provided by either APPC/MVS or CICS.
There is no CTRC configuration required for PEM support as it is native in DRDA over TCP. However the DB2 host must be enabled to support the PEM. To enable PEM support on DB2 for OS390 V5 or later, you must configure and use extended security using either:
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. |
The CTRC PEM support over APPC is is implemented using SNA 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 TPs.
To allow PEM support for DB2 connections, use the dbconn pem configuration command to turn on PEM support as appropriate for the CTRC routers handling the connections. In the dbconn pem command configuration 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 TPs. Following is an example 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=APPCSNA,
DMINWNL=5,
DMINWNR=5,
DRESPL=NALLOW,
DSESLIM=10,
LMDENT=19,
PARSESS=YES,
SECACPT=CONV,
SRBEXIT=YES,
VPACING=1
CICS support for SNA TPs is provided in resource group DFHISC. You must install this group and configure CICS for CTRC support as described in Chapter 3, "Preparing CICS Connections." When you configure the CTRC router to support PEM for CICS connections, use the CICS APPLID as the rlu value in the dbconn pem command configuration statement.
Posted: Tue Nov 5 11:17:57 PST 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.