Connectivity Supplement

Setting Up the Application Server

The application server support in DB2 for OS/390 allows DB2 for OS/390 to act as a server for DRDA application requesters. The Application Requester connected to a DB2 for OS/390 Application Server can be:

A DB2 for OS/390 requester
DB2 Connect
DB2 Universal Database Enterprise Edition V5 or DB2 Universal Database Extended - Enterprise Edition with DB2 Connect support enabled.
A DB2 Version 2 requester, which can run on AIX, HP-UX, OS/2, Solaris, Windows 3.1, Windows 3.11 for Workgroups, Windows 95, or Windows NT, as wells as Macintosh, SCO, SGI, or SINIX. Distributed Database Connection Services (DDCS) Multi-user gateway Version 2.3, DDCS Single-user Version 2.3, and DDCS for Windows Version 2.4 provide this function.
A OS/400 requester
An DB2 for VM requester
Any product that supports the DRDA Application Requester protocols

For any Application Requester connected to a DB2 for OS/390 Application Server, the DB2 for OS/390 Application Server supports database access as follows:

The Application Requester is permitted to access tables stored at the DB2 for OS/390 application server. The Application Requester must create a package at the DB2 for OS/390 Application Server before the application can be run. The DB2 for OS/390 Application Server uses the package to locate the application's SQL statements at execution time.
The Application Requester can inform the DB2 for OS/390 Application Server that access must be restricted to read-only activities if the DRDA requester-server connection does not support the two-phase commit process. For example, a DDCS V2R3 requester with a CICS front end would inform the DB2 for OS/390 application server that updates are not allowed.
The Application Requester can also be permitted to access tables stored at other DB2 for OS/390 systems in the network using system-directed access. System-directed access allows the application requester to establish connections to multiple database systems in a single unit of work.

Provide Network Information

For the DB2 for OS/390 Application Server to properly process distributed database requests, you must take the following steps:

Define the application server to the local Communications Manager.
Define each potential secondary server destination so the DB2 for OS/390 application server can reroute SQL requests to their final destination.
Provide the necessary security.
Provide for data representation.

Defining the Application Server (SNA)

For the Application Server to receive distributed database requests, it must be defined to the local Communications Manager and have a unique RDB_NAME. The following discussion relates to SNA connections. You must take the following steps to properly define the Application Server:

Select the LU name and RDB_NAME to be used by the DB2 for OS/390 Application Server. The process to record these names in DB2 for OS/390 and VTAM is the same process described in "Defining the Local System (SNA)". The RDB_NAME you choose for DB2 for OS/390 must be supplied to all end users and Application Requesters that require connectivity to the Application Server.
Register the NETID.LUNAME value for the DB2 for OS/390 Application Server with each Application Requester requiring access, so the Application Requester can route SNA requests to the DB2 for OS/390 server. This is true even in cases where the Application Requester is able to perform dynamic network routing, because the Application Requester must know the NETID.LUNAME before dynamic network routing can be used.
Provide the DRDA default TPN (X'07F6C4C2' ) to each Application Requester because DB2 for OS/390 automatically uses this value.
Create an entry in the VTAM mode table for each mode name that is requested by an Application Requester. These entries describe the RU sizes, pacing window size, and class of service for each mode name.
Define session limits for the Application Requesters that connect with the DB2 for OS/390 Application Server. The VTAM APPL statement defines default session limits for all partner systems. If you want to establish unique defaults for a particular partner, you can use the SYSIBM.LUMODES table of the communications database (CDB).
See "Setting RU Sizes and Pacing" about how to review your VTAM network.

Create entries in the DB2 for OS/390 CDB to identify which Application Requesters are allowed to connect to the DB2 for OS/390 Application Server. Two basic approaches to define the CDB entries for the Application Requesters in the network are:

You can insert a row in SYSIBM.LUNAMES that provides default values to use for any LU not specifically described in the CDB (the default row contains blanks in the LUNAME column). This approach allows you to define specific attributes for some of the LUs in your network, while establishing defaults for all other LUs.

For example, you can allow the DALLAS system (another DB2 for OS/390 system) to send already-verified distributed database requests (LU 6.2 SECURITY=SAME), while requiring database manager systems to send passwords. Furthermore, you might not want to record an entry in the CDB for each database manager system, especially if there is a large number of these systems. Figure 25 shows how the CDB can be used to specify SECURITY=SAME for the DALLAS system, while enforcing SECURITY=PGM for all other requesters.

Figure 25. Establishing Defaults for Application Requester Connections (SNA)

INSERT INTO SYSIBM.LUNAMES (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' '); INSERT INTO SYSIBM.LUNAMES (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES (' ', ' ', 'C', 'N', 'N', ' ');

You can use the CDB to individually authorize each Application Requester in the network, by setting the CDB in one of these ways:

Do not record a default row in SYSIBM.LUNAMES. When the default row (the row containing a blank LU name) is not present, DB2 for OS/390 requires a row in SYSIBM.LUNAMES containing the LU name for each application requester that attempts to connect. If the matching row is not found in the CDB, the Application Requester is denied access.
Record a default row in SYSIBM.LUNAMES that specifies come-from checking is required (USERNAMES column set to 'I' or 'B'). This causes DB2 for OS/390 to limit access to Application Requesters and end users identified in the SYSIBM.USERNAMES table, as described in "Come-From Checking" . You might want to use this approach if your name translation rules require a row with a blank LU name in SYSIBM.LUNAMES, but you do not want DB2 for OS/390 to use this row to allow unrestricted access to the DB2 for OS/390 Application Server.

In Figure 26, no row contains blanks in the LUNAME column, so DB2 for OS/390 denies access to any LU other than LUDALLAS or LUNYC.

Figure 26. Identifying Individual Application Requester Connections (SNA)

INSERT INTO SYSIBM.LUNAMES (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUDALLAS', ' ', 'A', 'N', 'N', ' '); INSERT INTO SYSIBM.LUNAMES (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS, MODESELECT, USERNAMES) VALUES ('LUNYC', ' ', 'A', 'N', 'N', ' ');

Defining the Application Server (TCP/IP)

For the Application Server to receive distributed database requests over TCP/IP connections, it must be defined to the local TCP/IP subsystem, and have a unique RDB_NAME. Additionally, the DB2 for OS/390 Bootstrap Dataset must include the necessary parameters, and you may need to make updates to the DB2 for OS/390 Communications Database (CDB).

For information about setting up TCP/IP at the AS, see DB2 for OS/390 Installation Reference. How to set up the AR is described in DB2 Connect Enterprise Edition Quick Beginnings, and DB2 Connect Personal Edition Quick Beginnings.
An example Bootstrap Dataset definition is shown in Figure 18.
No CDB updates are required if you will only use inbound database connections, so that if you plan to use DB2 for OS/390 only as a server, you do not need to populate the CDB, and default values can be used. A simple example of how to update SYSIBM.IPNAMES follows.
If you want to permit inbound database connection requests for TCP/IP nodes, you can use an SQL command such as the following to update this table:
```
       INSERT INTO SYSIBM.IPNAMES (LINKNAME) VALUES('        ')                                   
```

Provide Security

When an Application Requester routes a distributed database request to the DB2 for OS/390 Application Server, the following security considerations can be involved:

Come-from checking
Selection of end user names
Network security parameters
Database manager security
Security enforced by an external security subsystem

Come-From Checking

When the DB2 for OS/390 Application Server receives an end user name from the Application Requester, the Application Server can restrict the end user names received from a given Application Requester. This is accomplished through the use of come-from checking. Come-from checking allows the Application Server to specify that a given user ID is only allowed to be used by particular partners. For example, the Application Server can restrict JONES to "come from" DALLAS. If another Application Requester (other than DALLAS) attempts to send the name JONES to the Application Server, the Application Server can reject the request because the name did not come from the correct network location.

DB2 for OS/390 implements come-from checking as part of inbound end user name translation, which is described in the next section.
Note: Inbound and come-from checks are not done for TCP/IP inbound requests.

Selecting End User Names

The user ID passed by the Application Requester might not be unique throughout the entire SNA network. The DB2 for OS/390 Application Server might need to perform inbound name translation to create unique end user names throughout the SNA network. Similarly, the DB2 for OS/390 Application Server might need to perform outbound name translation to provide a unique end user name to the secondary servers involved in the application (see "Provide Security" for information concerning outbound end user name translation).

Inbound name translation is enabled by setting the USERNAMES column of the SYSIBM.LUNAMES or SYSIBM.IPNAMES table to 'I' (inbound translation) or 'B' (both inbound and outbound translation). When inbound name translation is in effect, DB2 for OS/390 translates the user ID sent by the Application Requester and the DB2 for OS/390 plan owner's name (if the Application Requester is another DB2 for OS/390 system).

If the Application Requester sends both a user ID and a password on the APPC ALLOCATE verb, the user ID and password are validated before the user ID is translated. The PASSWORD column in SYSIBM.USERNAMES is not used for password validation. Instead, the user ID and password are presented to the external security system (RACF or a RACF-equivalent product) for validation.

When the incoming user ID on the ALLOCATE verb is verified, DB2 for OS/390 has authorization exits you can use to provide a list of secondary AUTHIDs and perform additional security checks. See the DB2 for OS/390 Version 5 Administration Guide, for details.

The inbound name translation process searches for a row in the SYSIBM.USERNAMES table, which must fit one of the patterns shown in the following precedence list (TYPE.AUTHID.LINKNAME):

I.AUTHID.LINKNAME--A specific end user from a specific Application Requester
I.AUTHID.blank--A specific end user from any Application Requester
I.blank.LINKNAME--Any end user from a specific Application Requester

If no row is found, remote access is denied. If a row is found, remote access is allowed and the end user's name is changed to the value provided in the NEWAUTHID column, with a blank NEWAUTHID value indicating that the name is unchanged. Any DB2 for OS/390 resource authorization checks (for example, SQL table privileges) made by DB2 for OS/390 are performed on the translated end user names, rather than on the original user names.

When the DB2 for OS/390 Application Server receives an end user name from the Application Requester, several objectives can be accomplished by using the DB2 for OS/390 inbound name translation capability:

You can change an end user's name to make it unique. For example, the following SQL statements translate the end user name JONES from the NEWYORK application requester (LUNAME LUNYC) to a different name (NYJONES).

INSERT INTO SYSIBM.LUNAMES
     (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
              MODESELECT, USERNAMES)
  VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
     (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
  VALUES ('I', 'JONES', 'LUNYC', 'NYJONES', ' ');

You can change the end user's name so that a group of end users are all represented by a single name. For example, you might want to represent all users from the NEWYORK Application Requester (LUNAME LUNYC) with the user name NYUSER. This allows you to grant SQL privileges to the name NYUSER and to control the SQL access given to users from NEWYORK.
```
INSERT INTO SYSIBM.LUNAMES
     (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
              MODESELECT, USERNAMES)
  VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
     (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
  VALUES ('I', ' ', 'LUNYC', 'NYUSER', ' ');
```

You can restrict the end user names transmitted by a particular Application Requester. This use of end user name translation accomplishes the come-from check described in "Come-From Checking". For example, the SQL statements that follow allow only SMITH and JONES as end user names from the NEWYORK Application Requester. Any other name is denied access, because it is not listed in the SYSIBM.USERNAMES table.

INSERT INTO SYSIBM.LUNAMES
     (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
              MODESELECT, USERNAMES)
  VALUES ('LUNYC', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
     (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
  VALUES ('I', 'SMITH', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.USERNAMES
     (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
  VALUES ('I', 'JONES', 'LUNYC', ' ', ' ');

You can restrict the Application Requesters allowed to connect to the DB2 for OS/390 Application Server. This is yet another feature of come-from checking. The following example accepts any end user name sent by the NEWYORK Application Requester (LUNYC) or the CHICAGO Application Requester (LUCHI). Other Application Requesters are denied access, because the default SYSIBM.LUNAMES row specifies inbound name translation for all inbound requests.
```
INSERT INTO SYSIBM.LUNAMES
     (LUNAME, SYSMODENAME, SECURITY_IN, ENCRYPTPSWDS,
              MODESELECT, USERNAMES)
  VALUES (' ', ' ', 'A', 'N', 'N', 'I');
INSERT INTO SYSIBM.USERNAMES
     (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
  VALUES ('I', ' ', 'LUNYC', ' ', ' ');
INSERT INTO SYSIBM.USERNAMES
     (TYPE, AUTHID, LINKNAME, NEWAUTHID, PASSWORD)
  VALUES ('I', ' ', 'LUCHI', ' ', ' ');
```

Provide Network Security

For SNA connections LU 6.2 provides three major network security features:

Session-level security
Conversation-level security
Encryption

"Network Security" discusses how to specify session-level security and encryption with DB2 for OS/390. The DB2 for OS/390 Application Server uses session-level security and encryption in exactly the same manner as the DB2 for OS/390 Application Requester.

The only remaining network security consideration is SNA conversation-level security. Some aspects of conversation-level security are unique for a DB2 for OS/390 Application Server. The DB2 for OS/390 Application Server plays two distinct roles in network security:

As a requester to secondary servers, the DB2 for OS/390 Application Server is responsible for issuing APPC requests that contain the SNA conversation-level security parameters required by the secondary servers. The DB2 for OS/390 Application Server uses the USERNAMES column of the SYSIBM.LUNAMES table and the SYSIBM.USERNAMES table to define the SNA conversation level security requirements for each secondary server. The details of these definitions are identical to those in "Network Security".
As the server for the Application Requester, the DB2 for OS/390 Application Server dictates the SNA conversation level security requirements for the Application Requester. DB2 for OS/390 uses the USERSECURITY column of the SYSIBM.LUNAMES table to determine the conversation security required from each Application Requester in the network. The following values are used in the USERSECURITY column:

C
This indicates that DB2 for OS/390 requires the Application Requester to send a user ID and password (LU 6.2 SECURITY=PGM) with each distributed database request. If the ENCRYPTPSWDS column in SYSIBM.LUNAMES contains 'Y', DB2 for OS/390 assumes the password is already in RACF encrypted format (this is only possible for a DB2 for OS/390 Application Requester). If the ENCRYPTPSWDS column does not contain 'Y', DB2 for OS/390 expects the password in the standard LU 6.2 format (EBCDIC character representation). In either case, DB2 for OS/390 passes the user ID and password values to the security subsystem for validation. You must have a security subsystem that provides APPC user ID and password verification; for example, RACF has the capability to verify APPC user IDs and passwords. If the security subsystem rejects the user ID-password pair, distributed database access is denied.
Any other value
This indicates the Application Requester is allowed to send either an already-verified user ID (LU 6.2 SECURITY=SAME) or a user ID and password (LU 6.2 SECURITY=PGM). If a user ID and password are sent, DB2 for OS/390 processes them as described for 'C' above. If the request contains only a user ID, the security subsystem is called to authenticate the user unless the sysusernames table is used to manage inbound user IDs.

If a security violation is discovered, LU 6.2 requires the DB2 for OS/390 Application Server to return the SNA security failure sense code ('080F6051'X) to the Application Requester. Because this sense code does not describe the cause of the failure, DB2 for OS/390 provides two methods for recording the cause of distributed security violations:

A DSNL030I message is produced, which provides the requester's LUWID and a DB2 reason code describing the failure. DSNL030I also includes the AUTHID, if known, that was sent from the application request that was rejected.
An alert is recorded in the NETVIEW hardware monitor database, which contains the same information provided in the DSNL030I message.

Database Manager Security

As the owner of database resources, the DB2 for OS/390 Application Server controls the database security functions for SQL objects residing at the DB2 for OS/390 Application Server. Access to DB2 for OS/390-managed objects is controlled by privileges, which are granted to users by the DB2 for OS/390 administrator or the owners of individual objects. The two basic classes of objects that the DB2 for OS/390 Application Server controls are:

Packages-- Individual end users are authorized to create, replace, and run packages with the DB2 for OS/390 GRANT statement. When an end user owns a package, that user can automatically run or replace the package. Other end users must be specifically authorized to run a package at the DB2 for OS/390 Application Server with the GRANT statement. USE can be granted to individual end users or to PUBLIC, which allows all end users to run the package.
When an application is bound to DB2 for OS/390, the package contains the SQL statements contained in the application program. These SQL statements are classified as:

Static SQL
Static SQL means that the SQL statement and the SQL objects referenced by the statement are known at the time the application is bound to DB2 for OS/390. The person creating the package must have authority to execute each of the static SQL statements contained in the package.
When end users are granted authority to execute a package, they automatically have authority to execute each of the static SQL statements contained in the package. Thus, end users do not need any DB2 for OS/390 table privileges if the package they execute contains only static SQL statements.
Dynamic SQL
Dynamic SQL describes an SQL statement that is not known until the program executes. In other words, the SQL statement is built by the program and dynamically bound to DB2 for OS/390 with the SQL PREPARE statement. When an end user executes a dynamic SQL statement, the user must have the table privileges required to execute the SQL statement. Because the SQL statement is not known at the time the plan or package is created, the end user is not automatically given the required authority by the package owner.
SQL objects-- These are tables, views, synonyms, or aliases. DB2 for OS/390 users can be granted various levels of authority to create, delete, change, or read individual SQL objects. This authority is required to bind static SQL statements or to execute dynamic SQL statements.

When you create a package, the DISABLE/ENABLEoption allows you to control which DB2 for OS/390 connection types can run the package. You can use RACF and DB2 for OS/390 security exit routines to selectively allow end users to use DDF. You can use RLF to specify limits on processor time for remote binds and dynamic SQL executions.

Consider a DB2 for OS/390 package named MYPKG, which is owned by JOE. JOE can allow SAL to execute the package by issuing the DB2 for OS/390 GRANT USE statement. When SAL executes the package, the following occurs:

DB2 for OS/390 verifies that SAL was given USE authority for the package.
SAL can issue every static SQL statement in the package because JOE had the required SQL object privileges to create the package.
If the package has dynamic SQL statements, SAL must have SQL table privileges of her own. For example, SAL cannot issue SELECT * FROM JOE.TABLE5 unless she is granted read access to JOE.TABLE5.

Security Subsystem

The DB2 for OS/390 Application Server use of the security subsystem (RACF or a RACF-equivalent product) is dependent on how you define the inbound name translation function in the SYSIBM.LUNAMES table:

If you specify 'I' or 'B' for the USERNAMES column, inbound name translation is active, and DB2 for OS/390 assumes that the DB2 for OS/390 administrator is using inbound name translation to perform part of the system security enforcement. The external security subsystem is called only if the Application Requester sends a request containing both user ID and password (SECURITY=PGM). You must have a security subsystem that provides APPC user ID and password verification; for example, RACF has the capability to verify APPC user IDs and passwords.
If the request from the Application Requester contains only a user ID (SECURITY=SAME), the external security system is not called at all, because the inbound name translation rules define which users are allowed to connect to the DB2 for OS/390 Application Server.
If you specify something other than 'I' or 'B' for the USERNAMES column, the following security subsystem checks are performed:
- When a distributed database request is received from the Application Requester, DB2 for OS/390 calls the external security system to validate the end user's user ID (and password if it is provided).
- The external security system is called to verify that the end user is authorized to connect to the DB2 for OS/390 subsystem.
In either case, an authorization exit is driven to provide a list of secondary authorization IDs. For more information, see the DB2 for OS/390 Version 5 Administration Guide.

Represent Data

You must ensure that your DB2 for OS/390 subsystem has the ability to convert from each application requester's CCSID to your DB2 for OS/390 subsystem's installation CCSID. Refer to "Represent Data" for more information.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]