The application server support in DB2 for VM allows DB2 for VM to act as a server for DRDA application requesters. The application requester connected to an DB2 for VM application server can be one of the following:
For any application requester connected to a DB2 for VM application server, the DB2 for VM application server allows the application requester to access database objects (such as tables) stored locally at the DB2 for VM application server. The application requester must create a package containing the application's SQL statements at the DB2 for VM application server before the connection can be established.
For the DB2 for VM Application Server to process distributed database requests, you must take the following steps:
For the Application Server to receive distributed database requests, define the Application Server to the local communications subsystem and assign a unique RDB_NAME.
Follow these steps to define the application server:
The NETID is defined to VTAM as a startup parameter, and all distributed requests from the Application Requester are routed to it correctly. The DB2 for VM Application Server does not set the NETID.
The DB2 for VM Application Server does not determine which gateway to use to route the inbound distributed requests from the Application Requester. The Application Requester always controls this. In the case of an DB2 for VM Application Requester, the CMS Communications Directory specifies it using the :luname and :tpn tags.
In order for the DB2 for VM Application Server to support distributed unit of work activity, the Application Requester must select an AVS gateway that has been defined to VTAM using the SYNCLVL=SYNCPT parameter. Make sure that the AVS gateway has been defined to support distributed units of work.
After choosing RU sizes, session limits, and pacing counts, consider the impact these values have on the VTAM IOBUF pool.
Mapping the server name to a RESID:
A resource ID (RESID) is the VM term for transaction program name. In the VM environment, it is commonly defined as an alphanumeric name up to 8 bytes long. You normally define a RESID that is identical to the server name, to keep administration easy. Figure 34 shows a sample RESID names file.
Figure 34. Example of a RESID names file
+--------------------------------------------------------------------------------+ | RESID NAMES A1 V 132 Trunc=132 Size=4 Line=1 Col=1 Alt=3 | |====> | |00001 :nick.MTLTPN | |00002 :dbname.MONTREAL_SALES_DB | |00003 :resid.SALES | |00004 | +--------------------------------------------------------------------------------+ |
See Figure 33 for the Communications Directory entry that defines this dbname and RESID (as the TPN). If the application server name cannot be the same as the RESID, then the DB2 for VM application server uses a RESID NAMES file to provide the mapping. This mapping is needed if you:
During installation, the default is to use the server name specified on the SQLDBINS EXEC as the RESID. To create a mapping entry in the RESID NAMES file, specify the RESID parameter on SQLDBINS.
When you start up the database using SQLSTART DB(server_name), DB2 for VM looks up the corresponding RESID and informs VM that this is the resource that VM is to control. If an entry is not found in the RESID NAMES file, DB2 for VM assumes the RESID is the same as the server name and tells VM so. For more information, see the DB2 for VM System Administration manual.
The DB2 for VM application server may not have DRDA support installed. Follow the following steps to prepare the DB2 for VM application server for DRDA communications:
See the VM/ESA System Administration manual for details.
When an Application Requester routes a distributed database request to the DB2 for VM application server, the following security considerations can apply:
In both SQL and LU 6.2, end users are assigned a 1- to 8-byte user ID. This user ID must be unique within a particular operating system, but does not need to be unique throughout the SNA network. To eliminate naming conflicts, DB2 for VM can optionally use the user ID translation function provided by AVS, but only under the following conditions:
If a connection is routed to a server through AVS using the SECURITY=SAME option, then AVS user ID translation is required. The AGW ADD USERID command, issued from the AVS machine, must provide security clearance to the connecting users coming from a specific remote LU or AVS gateway. A mapping must exist for all inbound LUs and user IDs that connect using SECURITY=SAME. The command is flexible; you can accept all user IDs from a particular LU or all remote LUs generically. Or you can accept only a specific set of user IDs from a specific LU.
If you use the AGW ADD USERID command to authorize the inbound (already-verified) user IDs at the local AVS machine, no validation is performed by the host. This means that the authorized ID does not necessarily exist on the host, but the connection is accepted anyway.
Two ways to change the current AVS user ID authorization are:
As an example, the case of identical user IDs in different cities shows how the AVS translation function can resolve a naming conflict. Suppose a user exists with an ID of JONES in the Toronto system, and another user exists with the same ID in the Montreal system. If JONES in Montreal wants to access data in the Toronto system, the following actions at the Toronto system eliminate the naming conflict and prevent JONES in Montreal from using the privileges granted to JONES at the Toronto system:
These actions can also be performed at the Montreal system to ensure JONES in Toronto does not use privileges granted to JONES in Montreal when accessing remote data at the Montreal system.
The AVS commands that support user ID translation are described in VM/ESA Connectivity Planning, Administration and Operation.
LU 6.2 provides three major network security features:
See Network Security for the discussion on how to specify session-level security for DB2 for VM. The DB2 for VM Application Server uses session-level security the same way the DB2 for VM Application Requester does.
The Application Requester can send either an already-verified user ID (SECURITY=SAME) or a user ID and password (SECURITY=PGM). If a user ID and password are sent, CP, RACF, or an equivalent validates them with the VM directory at the Application Server host. If validation fails, the connection request is rejected; otherwise it is accepted. If the request contains only a user ID, DB2 for VM accepts the request without validating the user ID.
| Note: | DB2 for VM does not provide encryption capability because VM/ESA does not support encryption. |
The DB2 for VM Application Server verifies if the user ID given by VM has CONNECT authority to access the database, and then rejects the connection if it does not have authority.
As the owner of database resources, the DB2 for VM Application Server controls the database security functions for SQL objects residing at the DB2 for VM Application Server. Access to objects managed by DB2 for VM is controlled through a set of privileges, which are granted to users by the DB2 for VM system administrator or the owner of the particular object. The DB2 for VM Application Server controls two classes of objects:
When an application is preprocessed on DB2 for VM, the package contains the SQL statements contained in the application program. These SQL statements are classified as:
When an end user is granted the privilege to execute a package, the end user automatically has the authority to execute each of the static SQL statements contained in the package. Thus, end users do not need any DB2 for VM table privileges if the package contains only static SQL statements.
The use of this subsystem by the DB2 for VM application server is optional. If the application server needs to check the identity of the application requester LU name, VTAM calls the security subsystem to perform the partner LU verification exchange. The decision to perform partner LU verification is made depending on the value specified in the VERIFY parameter of the VTAM APPL statement for the gateway that the DB2 for VM application server uses to receive inbound distributed database requests.
The security subsystem can also be called by CP to validate the user ID and password sent from the application requester. If the security subsystem is RACF and you do not have a RACF system profile, the validation is performed by RACF. If you do have a RACF system profile, for example, RACFPROF, use the following instructions to request this validation from RACF:
RALTER VMXEVENT RACFPROF DELMEM (APPCPWVL/NOCTL
RALTER VMXEVENT RACFPROF ADDMEM (APPCPWVL/CTL
SETEVENT REFRESH RACFPROF
You must choose the most appropriate default CHARNAME and CCSID for your installation. Using the most appropriate values ensures the integrity of the character data representation and reduces the performance overhead associated with CCSID conversion.
For example, if your DB2 for VM application server is accessed only by local users whose terminal controllers are generated with code page 37 and character set 697 (CP/CS 37/697) for the US ENGLISH characters, then you should set the application server default CHARNAME to ENGLISH. This is because CP/CS 37/697 corresponds to the CCSID of 37, which corresponds to the CHARNAME of ENGLISH.
To eliminate unnecessary CCSID conversion, choose an application server default CCSID to be the same as the CCSID of the application requesters that access your application server most often.
Following is an example of how these two goals can be in conflict:
An application server has less than five application requesters that are local (for VM application requesters, the protocol parameter would be set to SQL/DS) and many (around 100) application requesters that access the application server using the DRDA protocol. The local application requesters have controllers that are defined with CP/CS 37/697. The remote application requesters use CCSID 285.
If the application server default CHARNAME is set to ENGLISH, this keeps the data integrity for the local application requesters, but incurs CCSID conversion overhead for all the remote application requesters.
If the application server default CHARNAME is set to UK-ENGLISH, this avoids the CCSID conversion overhead incurred for all the remote application requesters, but causes data integrity problems for the local application requesters--certain characters are not displayed correctly at the local application requesters; for example, a British pound sign is displayed as a dollar sign.
To display the current CCSID of the system, query the SYSTEM.SYSOPTIONS table. The application server default CCSID is usually the value of CCSIDMIXED. If this value is zero, then the system default CCSID is the value of CCSIDSBCS. The CHARNAME, CCSIDSBCS, CCSIDMIXED, and CCSIDGRAPHIC values in this table are updated to the values used as the system defaults every time the database is started. The values in this table might not always be the system defaults. A user with DBA authority might have changed these values, though this is not recommended. To change the application server default CCSID, you must specify the CHARNAME parameter of the SQLSTART EXEC the next time the application server is started. See the VM/ESA System Administration manual for more detailed information.
For a newly installed database, the application server default CHARNAME is INTERNATIONAL, and the application server default CCSID is 500. This is probably not correct for your system. The default CHARNAME for a migrated system is ENGLISH, and the default CCSID is 37.
The following checklist summarizes the steps needed to enable a DRDA Application Server for DRDA communications, starting with the assumption that your VM system is installed with ACF/VTAM as its teleprocessing access method, and that VTAM definitions needed to communicate with the remote systems, such as NCP definitions are completed.