DB2 for MVS/ESA implements the DRDA application requester support as an integral part of the DB2 for MVS/ESA Distributed Data Facility (DDF). DDF can be stopped independently from the local DB2 for MVS/ESA database management facilities, but it cannot run in the absence of the local DB2 for MVS/ESA database management support.
When DB2 for MVS/ESA acts as an Application Requester, it can connect applications running on the system to remote DB2 Universal Database, DB2 for MVS/ESA, DB2 Universal Database for OS/390, DB2 Universal Database for AS/400, and DB2 for VSE & VM database servers that implement DRDA Application Server function.
For the DB2 for MVS/ESA Application Requester to provide distributed database access, you need to do the following:
Much of the processing in a distributed database environment requires exchanging messages with other locations in your network. For this processing to be performed correctly, you need to do the following:
Each program in the network is assigned a NETID and an LU name, so your DB2 for MVS/ESA Application Requester must have a NETID.LUNAME value when it connects to the network. Because the DB2 for MVS/ESA Application Requester is integrated into the local DB2 for MVS/ESA database management system, the Application Requester must also have an RDB_NAME. In the DB2 for MVS/ESA publications, DB2 for MVS/ESA refers to the RDB_NAME as a location name.
Define the DB2 for MVS/ESA Application Requester to the SNA network as follows:
Configuring the DDF BSDS: DB2 for MVS/ESA reads the BSDS during startup processing to obtain system installation parameters. One of the records stored in the BSDS is called the DDF record, because it contains the information used by DDF to connect to VTAM. This information consists of the following:
You can supply the DDF BSDS information to DB2 for MVS/ESA in two ways:
Figure 3. DB2 for MVS/ESA Installation Panel DSNTIPR
+--------------------------------------------------------------------------------+ | 1 DDF STARTUP OPTION ===> AUTO NO (DDF not startable), | | AUTO (automatic start up), or | | COMMAND (start by command) | | 2 DB2 LOCATION NAME ===> SYDNEY The name other DB2s use to | | refer to this DB2 | | 3 DB2 NETWORK LUNAME ===> LUDBD1 The name VTAM uses to refer to this DB2| | 4 DB2 NETWORK PASSWORD ===> PSWDBD1 Password for connecting to other DB2s | | 5 RLST ACCESS ERROR ===> NOLIMIT Action on non-local RLST access error | | NOLIMIT - Run without limit | | NORUN - Do not run at all | | 1-5000000 - Limit in CPU service units | | PRESS: ENTER to continue END to exit HELP for more information | +--------------------------------------------------------------------------------+ |
Figure 4 shows how to update the BSDS with location name SYDNEY, the LU name LUDBD1, and password PSWDBD1.
Figure 4. Sample Bootstrap Data Set DDF Definition
//SYSADMB JOB ,'DB2 2.3 JOB',CLASS=A //* //* CHANGE LOG INVENTORY: //* UPDATE BSDS WITH //* - DB2 LOCATION NAME FOR SYDNEY //* - VTAM LUNAME (LUDBD1) //* - DB2/VTAM PASSWORD //* //DSNBSDS EXEC PGM=DSNJU003 //STEPLIB DD DISP=SHR,DSN=DSN230.DSNLOAD //SYSUT1 DD DISP=OLD,DSN=DSNC230.BSDS01 //SYSUT2 DD DISP=OLD,DSN=DSNC230.BSDS02 //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSIN DD * DDF LOCATION=SYDNEY,LUNAME=LUDBD1,PASSWORD=PSWDBD1 //* |
When DDF is started (either automatically at DB2 for MVS/ESA startup or by the DB2 for MVS/ESA START DDF command), it connects to VTAM, passing the LU name and password to VTAM. VTAM recognizes the DB2 for MVS/ESA system by checking the LU name and password (if a VTAM password is required) with the values defined in the DB2 for MVS/ESA VTAM APPL statement. The VTAM password is used to verify that DB2 for MVS/ESA is authorized to use the specified LU name on the VTAM system. The VTAM password is not transmitted through the network, and it is not used to connect other systems in the network to DB2 for MVS/ESA.
If VTAM does not require a password, omit the PASSWORD= keyword on the change log inventory utility. The absence of the keyword indicates that no VTAM password is required.
Creating a VTAM APPL definition: After you define the VTAM LU name and password to DB2 for MVS/ESA, you need to register these values with VTAM. VTAM uses the APPL statement to define local LU names. Figure 5 shows how to define the LU name LUDBD1 to VTAM.
Figure 5. Sample DB2 for MVS/ESA APPL Definition
DB2APPLS VBUILD TYPE=APPL
*
*--------------------------------------------------------------------*
* *
* APPL DEFINITION FOR THE SYDNEY DB2 SYSTEM *
* *
*--------------------------------------------------------------------*
*
LUDBD1 APPL APPC=YES, X
AUTH=(ACQ), X
AUTOSES=1, X
DMINWNL=10, X
DMINWNR=10, X
DSESLIM=20, X
EAS=9999, X
MODETAB=RDBMODES, X
PRTCT=PSWDBD1, X
SECACPT=ALREADYV, X
SRBEXIT=YES, X
VERIFY=NONE, X
VPACING=2, X
SYNCLVL=SYNCPT, X
ATNLOSS=ALL X
|
Many keywords are available on the VTAM APPL statement. The meaning of the keywords is discussed in detail in the DB2 Administration Guide. The only keywords discussed here address topics in this book. The keywords of interest in Figure 5 are described as follows:
You do not have to automatically start all the APPC sessions between any two distributed database partners. If the AUTOSES value is less than the contention winner limit (DMINWNL), VTAM delays starting the remaining SNA sessions until they are required by a distributed database application.
If the partner cannot support the number of sessions requested on the DSESLIM, DMINWNL, or DMINWNR parameters, the CNOS process negotiates new values for these parameters that are acceptable to the partner.
It is best to always specify SECACPT=ALREADYV, because the SNA conversation security level for each DB2 for MVS/ESA partner is taken from the DB2 for MVS/ESA communications database (the USERSECURITY column of the SYSIBM.SYSLUNAMES table). SECACPT=ALREADYV gives you the most flexibility in selecting values for USERSECURITY.
DB2 for MVS/ESA does not restrict your choice for the VERIFY keyword. In a nontrusted network, VERIFY=REQUIRED is recommended. VERIFY=REQUIRED causes VTAM to reject partners that cannot perform partner LU verification. If you choose VERIFY=OPTIONAL, VTAM performs partner LU verification only for those partners that provide the support.
DSESLIM, DMINWNL, and DMINWNR allow you to establish default VTAM session limits for all partners. For partners that have special session limit requirements, the SYSIBM.SYSLUMODES table can be used to override the default session limits. For example, you might want to specify VTAM default session limits that are appropriate for your OS/2 systems. For other partners, you can create rows in the SYSIBM.SYSLUMODES table to define the desired session limits. Consider these sample values:
DSESLIM=4,DMINWNL=0,DMINWNR=4
These parameters allow each partner to create up to four sessions with DB2 for MVS/ESA, where the partner is the contention winner on each of the sessions. Because OS/2 creates the LU 6.2 conversations with DB2 for MVS/ESA, by making OS/2 the contention winner on the sessions, you gain a small performance advantage. If OS/2 has an available contention winner session, it does not have to ask for permission to start a new LU 6.2 conversation.
When a DB2 for MVS/ESA application requests data from a remote system, DB2 for MVS/ESA searches the communications database tables to find information about the remote system, including a search on:
The communications database is a group of SQL tables managed by the DB2 for MVS/ESA system administrator. As the DB2 for MVS/ESA system administrator, you must use SQL to insert rows in the communications database to describe each potential DRDA partner. The communications database consists of five tables:
This table allows DB2 for MVS/ESA to determine the LU name and TPN value for each RDB_NAME selected by a DB2 for MVS/ESA application. The columns are:
If the remote system requires a TPN value other than the default TPN value, you must supply this value here.
This table defines the network attributes of the remote systems. The columns are:
If MODESELECT contains anything other than a 'Y', the mode name IBMDB2LM is used for system-directed access requests, and the mode name IBMRDB is used for DRDA requests.
The MODESELECT column allows you to prioritize distributed database requests by specifying a VTAM class of service (COS) associated with the mode name.
This table is used to define LU 6.2 session limits (CNOS limits) for each partner system. The columns are:
The value selected in CONVLIMIT is used during CNOS to set the DMINWNR and DMINWNL values to CONVLIMIT/2.
This table allows you to specify different mode names for individual end users and DB2 for MVS/ESA applications. Because each VTAM mode name can have an associated class of service (COS), you can use this table to assign network transmission priorities to distributed database applications based on a combination of AUTHID, PLANNAME, and LUNAME. The columns are:
This table is used to manage end user names by providing passwords, name translations, and come-from checking. DB2 for MVS/ESA refers to the end user's name as an authorization ID. Most other products refer to this name as a user ID.
With this table, you can use name translation to force different values to be used for the SNA user ID and the DB2 for MVS/ESA authorization ID. The name translation process is allowed for requests to a remote system (outbound requests) and for requests coming from a remote system (inbound requests). If passwords are not encrypted, this table is the source of the end user's password when both user ID and password are sent to a remote site. The columns are:
VTAM is the Communications Manager for MVS systems. VTAM accepts LU 6.2 verbs from DB2 for MVS/ESA and converts these verbs into LU 6.2 data streams you can transmit over the network. For VTAM to communicate with the partner applications defined in the DB2 for MVS/ESA communications database, you need to provide VTAM with the following information:
When DB2 for MVS/ESA communicates with VTAM, DB2 for MVS/ESA is allowed to pass only an LU name (not NETID.LUNAME) to VTAM to identify the desired destination. This LU name must be unique within the LU names known by the local VTAM system, allowing VTAM to determine both the NETID and LU name from the LU name value passed by DB2 for MVS/ESA. When LU names are unique throughout an enterprise's SNA network, it greatly simplifies the VTAM resource definition process. However, this might not always be possible. If LU names within your SNA networks are not unique, you must use VTAM LU name translation to build the correct NETID.LUNAME combination for a nonunique LU name. This process is described in "Resource Name Translation" in the VTAM Network Implementation Guide.
The placement and syntax of the VTAM definitions used to define remote LU names are highly dependent on how the remote system is logically and physically connected to the local VTAM system.
The VTAM mode table entries you define specify RU sizes and pacing counts. Failure to define these values correctly can have a negative impact on all VTAM applications.
After choosing RU sizes, session limits, and pacing counts, it is extremely important to consider the impact these values can have on the existing VTAM network. You should review the following items when you install a new distributed database system:
If you specify the NCP MAXBFRU parameter, select a value that can accommodate the RU size plus 29 bytes. For NCP, the MAXBFRU parameter defines the number of VTAM I/O buffers that can be used to hold the PIU. If you choose an IOBUF buffer size of 441, MAXBFRU=10 processes a 4K RU correctly because 10*441 is greater than 4096+29.
When a remote system performs distributed database processing on behalf of an SQL application, it must be able to satisfy the security requirements of the Application Requester, the Application Server, and the network connecting them. These requirements fall into one or more of the following categories:
On MVS systems, end users are assigned a 1 to 8-character user ID. This user ID value must be unique within a particular MVS system, but might not be unique throughout the SNA network. For example, there can be a user named JONES on the NEWYORK system, and another user named JONES on the DALLAS system. If these two users are the same person, no conflict exists. However, if the JONES in DALLAS is a different person than the JONES in NEWYORK, the SNA network (and consequently the distributed database systems within that network) cannot distinguish between JONES in NEWYORK and JONES in DALLAS. If you do not correct this situation, JONES in DALLAS can use the privileges granted to JONES at the NEWYORK system.
To eliminate naming conflicts, DB2 for MVS/ESA provides support for end user name translation. When an application at the DB2 for MVS/ESA Application Requester makes a distributed database request, DB2 for MVS/ESA performs name translation if the communications database specifies that outbound name translation is required. If outbound name translation is selected, DB2 for MVS/ESA always forces a password to be sent with each outbound distributed database request.
Outbound name translation in DB2 for MVS/ESA is activated by setting the USERNAMES column in the SYSIBM.SYSLUNAMES table to either 'O' or 'B'. If USERNAMES is set to 'O', end user name translation is performed for outbound requests. If USERNAMES is set to 'B', end user name translation is performed for both inbound and outbound requests.
Because DB2 for MVS/ESA authorization is dependent on both the end user's user ID and the user ID of the DB2 for MVS/ESA plan or package owner, the end user name translation process is performed for the end user's user ID, the plan owner's user ID, and the package owner's user ID. 2 The name translation process searches the SYSIBM.SYSUSERNAMES table in the following sequence to find a row that matches one of the following patterns (TYPE.AUTHID.LUNAME):
If no matching row is found, DB2 for MVS/ESA rejects the distributed database request. If a row is found, the value in the NEWAUTHID column is used as the authorization ID. (A blank NEWAUTHID value indicates the original name is used without translation.)
Consider the example discussed earlier. You want to give JONES in NEWYORK a different name (NYJONES) when JONES makes distributed database requests to DALLAS. In the example, assume that the application used by JONES is owned by DSNPLAN (the DB2 for MVS/ESA plan owner), and you do not need to translate this user ID when it is sent to DALLAS. The SQL statements required to supply the name translation rules in the communications database are shown in Figure 6.
Figure 6. SQL for Outbound Name Translation
INSERT INTO SYSIBM.SYSLUNAMES
(LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', 'O');
INSERT INTO SYSIBM.SYSLOCATIONS
(LOCATION, LOCTYPE, LINKNAME, LINKATTR)
VALUES ('DALLAS', ' ', 'LUDALLAS', '');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'JONES', 'LUDALLAS', 'NYJONES', 'JONESPWD');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'DSNPLAN', 'LUDALLAS', ' ', 'PLANPWD');
|
The resulting communications database tables are shown in Figure 7:
Figure 7. Outbound Name Translation
|
After the Application Requester selects the end user names to represent the remote application, the Application Requester must provide the required LU 6.2 network security information. LU 6.2 provides three major network security features:
Because the Application Server is responsible for managing the database resources, the Application Server dictates which network security features are required of the Application Requester. You must record the conversation-level security requirements of each Application Server in the SYSIBM.SYSLUNAMES table by setting the USERNAMES column of the SYSIBM.SYSLUNAMES table to reflect the application server's requirement.
The possible SNA conversation security options are:
Because DB2 for MVS/ESA ties end user name translation to outbound conversation security, it does not allow you to use SECURITY=SAME when outbound end user name translation is activated.
Depending upon options specified in the SYSIBM.SYSLUNAMES table, DB2 for MVS/ESA obtains the end user's password from two different sources:
Figure 8 defines passwords for SMITH and JONES. The LUNAME column in the example contains blanks, so these passwords are used for any remote system SMITH or JONES attempts to access.
Figure 8. Sending Passwords to Remote Sites
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'JONES', ' ', ' ', 'JONESPWD');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'SMITH', ' ', ' ', 'SMITHPWD');
|
DB2 for MVS/ESA searches the SYSIBM.SYSUSERNAMES table to determine the user ID (NEWAUTHID value) to transmit to the remote system. This translated name is used for the RACF password extraction. If you do not want to translate names, you must create rows in SYSIBM.SYSUSERNAMES that cause names to be sent without translation. Figure 9 allows requests to be sent to LUDALLAS and LUNYC without translating the end user's name (user ID).
Figure 9. Sending Encrypted Passwords to Remote Sites
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('O', ' ', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.SYSUSERNAMES
(TYPE, AUTHID, LUNAME, NEWAUTHID, PASSWORD)
VALUES ('O', ' ', 'LUDALLAS', ' ', ' ');
|
One way the Application Requester can participate in distributed database security is through outbound name translation, as stated earlier in Selecting End User Names. You can use outbound name translation to control access to each Application Server, based on the identity of the end user making the request and the application making the request. Other ways the DB2 for MVS/ESA Application Requester contributes to the distributed system security are:
When you bind a package, use the ENABLE/DISABLE option to specify whether the package is to be used by TSO, CICS/ESA, IMS/ESA, or a remote DB2 for MVS/ESA subsystem.
The external security subsystem on MVS systems is provided by RACF and other products that provide an interface compatible with RACF. The DB2 for MVS/ESA Application Requester does not have any direct calls to the external security subsystem, with the exception of the encrypted password support described in Network Security. However, the external security subsystem is used indirectly at the Application Requester in the following situations:
DB2 for MVS/ESA is shipped with a default installation coded character set identifier (CCSID) of 500. This default is probably not correct for your installation.
When installing DB2 for MVS/ESA, you must set the installation CCSID to the CCSID of the characters generated and sent to DB2 for MVS/ESA by the input devices at your site. This CCSID is generally determined by the national language you use. If the installation CCSID is not correct, character conversion will produce incorrect results. See DB2 Connect User's Guide for a list of the supported CCSIDs for each country or national language.
You must ensure that your DB2 for MVS/ESA subsystem has the ability to convert from each application server's CCSID to your DB2 for MVS/ESA subsystem's installation CCSID. DB2 for MVS/ESA provides conversion tables for the most common combinations of source and target CCSIDs, but not for every possible combination. You can add to the set of available conversion tables and conversion routines if you need to. See the DB2 Administration Guide, for more information about DB2 for MVS/ESA character conversion.