DB2 Universal Database for OS/390 implements the DRDA application requester support as an integral part of the DB2 Universal Database for OS/390 Distributed Data Facility (DDF). DDF can be stopped independently from the local DB2 Universal Database for OS/390 database management facilities, but it cannot run in the absence of the local DB2 Universal Database for OS/390 database management support.
When DB2 Universal Database for OS/390 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 Universal Database for OS/390 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:
See either Defining the Local System (SNA), or Defining the Local System (TCP/IP).
Each program in the SNA network is assigned a NETID and an LU name, so your DB2 Universal Database for OS/390 Application Requester must have a NETID.LUNAME value (assigned through VTAM) when it connects to the network. Because the DB2 Universal Database for OS/390 Application Requester is integrated into the local DB2 Universal Database for OS/390 database management system, the Application Requester must also have an RDB_NAME. In the DB2 Universal Database for OS/390 publications, DB2 Universal Database for OS/390 refers to the RDB_NAME as a location name.
Define the DB2 Universal Database for OS/390 Application Requester to the SNA network as follows:
Configuring the DDF BSDS: DB2 Universal Database for OS/390 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 Universal Database for OS/390 in two ways:
Figure 15. DB2 Universal Database for OS/390 Installation Panel DSNTIPR
+--------------------------------------------------------------------------------+ | | | DISTRIBUTED DATA FACILITY =| |==> _ | | | | Enter data below: | | | | 1 DDF STARTUP OPTION ===> AUTO NO, AUTO, or COMMAND | | 2 DB2 LOCATION NAME ===> NEW_YORK3 The name other DB2s use to | | refer to this DB2 | | 3 DB2 NETWORK LUNAME ===> NYM2DB2 The name VTAM uses to refer to this DB2 | | 4 DB2 NETWORK PASSWORD ===> PSWDBD1 Password for DB2's VTAM application | | 5 RLST ACCESS ERROR ===> NOLIMIT NOLIMIT, NORUN, or 1-5000000 | | 6 RESYNC INTERVAL ===> 3 Minutes between resynchronization period| | 7 DDF THREADS ===> ACTIVE (ACTIVE or INACTIVE) Status of a | | database access thread that commits or | | rolls back and holds no database locks | | or cursors | | 8 DB2 GENERIC LUNAME ===> Generic VTAM LU name for this DB2 | | subsystem or data sharing group | | 9 IDLE THREAD TIMEOUT ===> 120 0 or seconds until dormant server ACTIVE| | thread will be terminated (0-9999) | | 10 EXTENDED SECURITY ===> YES Allow change password and descriptive | | security error codes. YES or NO. | | PRESS: ENTER to continue RETURN to exit HELP for more information | | | +--------------------------------------------------------------------------------+ |
Figure 16 shows how to update the BSDS with location name NEW_YORK3, the LU name NYM2DB2, and password PSWDBD1.
Figure 16. Sample Bootstrap Data Set DDF Definition (for VTAM)
//SYSADMB JOB ,'DB2 5.1 JOB',CLASS=A //* //* CHANGE LOG INVENTORY: //* UPDATE BSDS WITH //* - DB2 LOCATION NAME FOR NEW_YORK3 //* - VTAM LUNAME (NYM2DB2) //* - DB2/VTAM PASSWORD //* //DSNBSDS EXEC PGM=DSNJU003 //STEPLIB DD DISP=SHR,DSN=DSN510.DSNLOAD //SYSUT1 DD DISP=OLD,DSN=DSNC510.BSDS01 //SYSUT2 DD DISP=OLD,DSN=DSNC510.BSDS02 //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //SYSIN DD * DDF LOCATION=NEW_YORK3,LUNAME=NYM2DB2,PASSWORD=PSWDBD1 //* |
When DDF is started (either automatically at DB2 Universal Database for OS/390 startup or by the DB2 Universal Database for OS/390 START DDF command), it connects to VTAM, passing the LU name and password to VTAM. VTAM recognizes the DB2 Universal Database for OS/390 system by checking the LU name and password (if a VTAM password is required) with the values defined in the DB2 Universal Database for OS/390 VTAM APPL statement. The VTAM password is used to verify that DB2 Universal Database for OS/390 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 Universal Database for OS/390.
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 Universal Database for OS/390, you need to register these values with VTAM. VTAM uses the APPL statement to define local LU names. Figure 17 shows how to define the LU name NYM2DB2 to VTAM.
Figure 17. Sample VTAM APPL Definition for DB2 Universal Database for OS/390
DB2APPLS VBUILD TYPE=APPL
*
*--------------------------------------------------------------------*
* *
* APPL DEFINITION FOR THE NEW_YORK3 DB2 SYSTEM *
* *
*--------------------------------------------------------------------*
*
NYM2DB2 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 Universal Database for OS/390 Administration Guide. The only keywords discussed here address topics in this book. The keywords of interest in Figure 17 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 Universal Database for OS/390 partner is taken from the DB2 Universal Database for OS/390 CDB (the USERSECURITY column of the SYSIBM.LUNAMES table). SECACPT=ALREADYV gives you the most flexibility in selecting values for USERSECURITY.
DB2 Universal Database for OS/390 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.LUMODES 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.LUMODES 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 Universal Database for OS/390, where the partner is the contention winner on each of the sessions. Because OS/2 creates the LU 6.2 conversations with DB2 Universal Database for OS/390, 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.
For your convenience the information in this section has been summarized from DB2 Connect Enterprise Edition for OS/2 and Windows NT Quick Beginnings. For more detailed information, please see DB2 Universal Database for OS/390 Version 5 Installation Reference, and DRDA Support for TCP/IP with DB2 Universal Database for OS/390 Version 5 and DB2 Universal Database Version 6.
The steps required to define TCP/IP communications with DB2 Universal Database for OS/390 are as follows:
Figure 18. Sample Bootstrap Data Set DDF Definition (for TCP/IP)
//SYSADMB JOB ,'DB2 5.1 JOB',CLASS=A
//*
//* CHANGE LOG INVENTORY:
//* UPDATE BSDS WITH
//* - DB2 LOCATION NAME FOR NEW_YORK3
//* - VTAM LUNAME (NYM2DB2)
//* - DB2/VTAM PASSWORD
//*
//* - GENERIC LU NAME
//* - TCP/IP PORT FOR DATABASE CONNECTIONS
//* - TCP/IP PORT FOR RESYNCH OPERATIONS
//*
//DSNBSDS EXEC PGM=DSNJU003
//STEPLIB DD DISP=SHR,DSN=DSN510.DSNLOAD
//SYSUT1 DD DISP=OLD,DSN=DSNC510.BSDS01
//SYSUT2 DD DISP=OLD,DSN=DSNC510.BSDS02
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSIN DD *
DDF LOCATION=NEW_YORK3,LUNAME=NTYM2DB2,PASSWORD=PSWDBD1,
GENERICLU=name,PORT=446,RESPORT=5001
/*
//*
|
When a DB2 Universal Database for OS/390 application requests data from a remote system, it searches the Communications Database (CDB) tables to find information about the remote system. The CDB is a group of SQL tables managed by the DB2 Universal Database for OS/390 system administrator. As the DB2 Universal Database for OS/390 system administrator, you can use SQL to insert rows in the CDB to describe each potential DRDA partner. A complete description of the CDB and how it is used can be found in DB2 Universal Database for OS/390 Version 5 SQL Reference, and DB2 Universal Database for OS/390 Version 5 Installation Guide.
References to the CDB search for information including:
Populating The Communications Database: No CDB updates are required if you will only use inbound TCP/IP database connections, so that if you plan to use DB2 Universal Database for OS/390 only as a TCP/IP server, you do not need to populate the CDB, and default values can be used. However, if you will use inbound SNA connections, you must at least provide a single blank row in SYSIBM.LUNAMES. For example, to permit SNA database connection requests to be accepted from any incoming DB2 Connect LU, use an SQL command such as the following:
INSERT INTO SYSIBM.LUNAMES (LUNAME) VALUES (' ')
When you will use DB2 Universal Database for OS/390 as a requester the CDB must always be updated. You will need to insert rows in into the SYSIBM.LOCATIONS table, and either the SYSIBM.LUNAMES table (for SNA connections), or the SYSIBM.IPNAMES table (for TCP/IP connections).
Further, if you want to control inbound security requirements or inbound user-id translation for SNA connections, additional CDB updates may be required. Additional examples are provided as follows: Provide Security describes how to define user security when setting up an application requester, and Provide Security describes setting up an application server.
The DB2 Universal Database for OS/390 Administration Guide discusses the requirements for updating CDB tables in more detail. After you populate the CDB, you can write queries that access data at remote systems. DB2 Universal Database for OS/390 Installation Reference also provides further information about updating the CDB.
How the Communications Database Handles Requests: When sending a request, DB2 Universal Database for OS/390 uses the LINKNAME column of the SYSIBM.LOCATIONS catalog table to determine which network protocol to use for the outbound database connection. To receive VTAM requests, you must select an LUNAME in DB2 Universal Database for OS/390 installation panel DSNTIPR. To receive TCP/IP requests, you must select a DRDA port and a resynchronization port in DB2 Universal Database for OS/390 installation panel DSNTIP5. TCP/IP uses the server's port number to pass network requests to the correct DB2 subsystem.
If the value in the LINKNAME column is found in the SYSIBM.IPNAMES table, TCP/IP is used for DRDA connections. If the value is found in SYSIBM.LUNAMES table, SNA is used. If the same name is in both SYSIBM.LUNAMES and SYSIBM.IPNAMES, TCP/IP is used to connect to the location.
| Note: | A requester cannot connect to a given location using both SNA and TCP/IP protocols. For example, if your SYSIBM.LOCATIONS specifies a LINKNAME of LU1, and if LU1 is defined in both the SYSIBM.IPNAMES and SYSIBM.LUNAMES table, TCP/IP is the only protocol used to connect to LU1 from this requester. |
Communications Database Tables: The CDB consists of the following tables:
This table allows DB2 Universal Database for OS/390 to determine the SNA or TCP/IP address information required when accessing each RDB_NAME selected by a DB2 Universal Database for OS/390 application for outbound requests. 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 remote systems accessed using SNA connections. The columns are:
If the USERNAMES column contains 'I' or 'B', RACF is not invoked to validate incoming connection requests that contain only a userid.
The authorization ID used for an outbound request is either the DB2 user's authorization ID or a translated ID, depending upon the value of the USERNAMES column.
The USERNAMES column must specify 'B' or 'O'.
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 provide VTAM with LU 6.2 session limits (CNOS limits) for partner systems using APPC (SNA) connections. 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 Universal Database for OS/390 applications. It is only used for SNA connections. 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 Universal Database for OS/390 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 user IDs connections and the DB2 Universal Database for OS/390 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:
I signifies inbound connections, O signifies outbound connections.
Use "O" for TCP/IP connections (inbound ID translation and come-from checking are not done for TCP/IP requests).
If a nonblank LINKNAME is specified, one or both of the following statements must be true:
Inbound name translation and come-from checking are not performed for TCP/IP clients.
This table is used for TCP/IP nodes.
The authorization ID used for an outbound request is either the DB2 user's authorization ID or a translated ID, depending upon the value of the USERNAMES column.
The USERNAMES column must specify "O."
No translation or "come from" checking is performed on inbound IDs.
VTAM is the Communications Manager for OS/390 systems. VTAM accepts LU 6.2 verbs from DB2 Universal Database for OS/390 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 Universal Database for OS/390 CDB, you need to provide VTAM with the following information:
When DB2 Universal Database for OS/390 communicates with VTAM, it 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 Universal Database for OS/390. 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.
The considerations are as indicated previously (see Defining the Local System (TCP/IP)).
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 OS/390 systems, end users are assigned a 1 to 8-character user ID. This user ID value must be unique within a particular OS/390 system, but might not be unique throughout the 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 Universal Database for OS/390 provides support for end user name translation. When an application at the DB2 Universal Database for OS/390 Application Requester makes a distributed database request, DB2 Universal Database for OS/390 performs name translation if the communications database specifies that outbound name translation is required. If outbound name translation is selected, DB2 Universal Database for OS/390 always forces a password to be sent with each outbound distributed database request.
Outbound name translation in DB2 Universal Database for OS/390 is activated by setting the USERNAMES column in the SYSIBM.LUNAMES or SYSIBM.IPNAMES 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 Universal Database for OS/390 authorization is dependent on both the end user's user ID and the user ID of the DB2 Universal Database for OS/390 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. 3 The name translation process searches the SYSIBM.USERNAMES table in the following sequence to find a row that matches one of the following patterns (TYPE.AUTHID.LINKNAME):
If no matching row is found, DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 CDB are shown in Figure 19.
Figure 19. SQL for Outbound Name Translation (SNA)
INSERT INTO SYSIBM.LUNAMES
(LUNAME, SYSMODENAME, SECURITY_OUT, ENCRYPTPSWDS, MODESELECT, USERNAMES)
VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', 'O');
INSERT INTO SYSIBM.LOCATIONS
(LOCATION, LINKNAME, LINKATTR)
VALUES ('DALLAS', 'LUDALLAS', '');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'JONES', 'LUDALLAS', 'NYJONES', 'JONESPWD');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'DSNPLAN', 'LUDALLAS', ' ', 'PLANPWD');
|
The resulting CDB tables are shown in Figure 20:
Figure 20. Outbound Name Translation
|
Figure 21 shows a more simple example for connecting to a DB2 Universal Database DRDA AS using an SNA connection.
Figure 21. SQL for Outbound Name Translation (simple example for SNA).
INSERT INTO SYSIBM.LUNAMES (LUNAME,
SECURITY_OUT,
ENCRYPTPSWDS,
USERNAMES)
VALUES ('NYX1GW01','P','N','O');
INSERT INTO SYSIBM.LOCATIONS (LOCATION,LINKNAME,TPN)
VALUES('TASG6',
'NYX1GW01','NYSERVER');
INSERT INTO SYSIBM.USERNAMES (TYPE,AUTHID,LINKNAME,NEWAUTHID,PASSWORD)
VALUES ('O',' ','NYX1GW01','SVTDBM6','SG6JOHN');
|
Figure 22 shows a simple example for connecting to a DB2 Universal Database DRDA AS using a TCP/IP connection.
Figure 22. SQL for Outbound Name Translation (simple example for TCP/IP).
-- DB2 for Solaris1 - UNIX
DELETE FROM SYSIBM.IPNAMES WHERE LINKNAME = 'SOLARIS1' ;
INSERT INTO SYSIBM.IPNAMES ( LINKNAME
, SECURITY_OUT
, USERNAMES
, IBMREQD
, IPADDR)
VALUES ( 'SOLARIS1'
, 'P'
, 'O'
, 'N'
, '9.21.45.4')
;
INSERT INTO SYSIBM.LOCATIONS ( LOCATION
, LINKNAME
, IBMREQD
, PORT
, TPN)
VALUES ( 'TCPDB1'
, 'SOLARIS1'
, 'N'
, '30088'
, '')
;
INSERT INTO SYSIBM.USERNAMES ( TYPE
, AUTHID
, LINKNAME
, NEWAUTHID
, PASSWORD
, IBMREQD)
VALUES ( 'O'
, ''
, 'SOLARIS1'
, 'svtdbm5'
, 'svt5dbm'
, 'N')
;
|
After the Application Requester selects the end user names to represent the remote application, the Application Requester must provide the required network security information.
For SNA connections, 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.LUNAMES or SYSIBM.IPNAMES tables by setting the USERNAMES column to reflect the application server's requirement.
The possible SNA conversation security options are:
Because DB2 Universal Database for OS/390 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.LUNAMES table, DB2 Universal Database for OS/390 obtains the end user's password from two different sources:
Figure 23 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 23. Sending Passwords to Remote Sites (SNA)
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'JONES', ' ', ' ', 'JONESPWD');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('O', 'SMITH', ' ', ' ', 'SMITHPWD');
|
DB2 Universal Database for OS/390 searches the SYSIBM.USERNAMES 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.USERNAMES that cause names to be sent without translation. Figure 24 allows requests to be sent to LUDALLAS and LUNYC without translating the end user's name (user ID).
Figure 24. Sending Encrypted Passwords to Remote Sites (SNA)
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
VALUES ('O', ' ', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.USERNAMES
(TYPE, AUTHID, LINKNAME, 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 Universal Database for OS/390 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 Universal Database for OS/390 subsystem.
The external security subsystem on OS/390 systems is usually provided by RACF or another product that provide an interface compatible with RACF. The DB2 Universal Database for OS/390 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 Universal Database for OS/390 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 Universal Database for OS/390, you must set the installation CCSID to the CCSID of the characters generated and sent to DB2 Universal Database for OS/390 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 Universal Database for OS/390 subsystem has the ability to convert from each application server's CCSID to your DB2 Universal Database for OS/390 subsystem's installation CCSID. DB2 Universal Database for OS/390 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 Universal Database for OS/390 Version 5 Administration Guide, for more information about DB2 Universal Database for OS/390 character conversion.