DB2 for VM implements the DRDA Application Requester support as an integral part of the resource adapter that resides on the end user virtual machine with the application. You can use the Application Requester support even when the virtual machine of the local database managers is not active. You can activate the DRDA application requester support by running the SQLINIT EXEC with protocol(auto) or protocol(drda) (see Options for Preprocessing or Running an Application).
When DB2 for VM acts as an Application Requester, it can connect to a DB2 for VM Application Server or any other product server that supports the DRDA architecture. For the DB2 for VM Application Requester to provide distributed database access, you need to know how to do the following:
Much of the processing in a distributed database environment requires messages to be exchanged with other locations in your network. To perform this process correctly, take the following steps:
The DB2 for VM application requester and the DB2 for VM application server are independent of each other. The DB2 for VM application requester directs connection requests directly to local or remote application servers. It does not, however, define itself as the target of inbound connection requests. Only the DB2 for VM application server can accept (or reject) inbound connection requests. Therefore, the DB2 for VM application requester does not identify an RDB_NAME and TPN for itself, as DB2 Universal Database for OS/390 does.
Define the DB2 for VM application requester to the SNA network as follows:
The application requester must have defined gateway names (for example, the LU names) to route its outbound requests into the network. Figure 30 shows an example of this. These statements reside on the VTAM virtual machine. When VTAM starts, the gateways are identified to the network but are not activated until the controlling AVS virtual machine starts. Each AVS virtual machine can define multiple gateways on a VM host.
Figure 30. Example of an AVS Gateway Definition
VBUILD TYPE=APPL
*************************************************************
* *
* Gateway Definition for Toronto DB2 for VM System *
* *
*************************************************************
TORGATE APPL APPC=YES, X
AUTHEXIT=YES, X
AUTOSES=1, X
DMINWNL=10, X
DMINWNR=10, X
DSESLIM=20, X
EAS=9999, X
MAXPVT=100K, X
MODETAB=RDBMODES, X
PARSESS=YES, X
SECACPT=ALREADYV, X
SYNCLVL=SYNCPT, X
VPACING=2
|
The following list describes the VTAM APPL statement keywords that are applicable to topics in this manual. (The VTAM APPL statement supports many more keywords than are shown here).
SECURITY=NONE, a request containing no security information. DB2 for VM rejects DRDA requests using this security level.
SECURITY=PGM, a request containing the requester's user ID and password. DB2 for VM accepts DRDA requests using this security level.
SECURITY=SAME indicates an already-verified request that contains only the requester's user ID.
DB2 for VM does not restrict your choice for the VERIFY keyword, but the VTAM version you are running can influence this choice. In a nontrusted network, DB2 for VM recommends coding VERIFY=REQUIRED. If you choose VERIFY=OPTIONAL, VTAM performs partner LU verification only for those partners that provide the support. VERIFY=REQUIRED causes VTAM to reject partners that cannot perform partner LU verification.
Gateway enabling is performed from the AVS virtual machine operating on the same host (or other hosts within the same TSAF collection) as the DB2 for VM Application Requester. Include an AGW ACTIVATE GATEWAY GLOBAL command in the AVS machine's profile or issue this command interactively from the AVS machine console to automatically enable the gateway each time AVS is started.
Ensure that the MAXCONN value in the CP directory of the AVS gateway machine is large enough to support the total number of sessions required.
Issue the AGW DEACTIVE GATEWAY command from the AVS virtual machine to disable the gateway. The gateway definition remains. The gateway can be enabled again at any time using the AGW ACTIVATE GATEWAY GLOBAL command.
See the VM/ESA Connectivity Planning, Administration and Operation for AVS command formats.
The NETID of the host (or other hosts within the same TSAF collection) where the Application Requester resides is supplied by VTAM as the request enters the network. The NETID is stored in the CMS file SNA NETID and resides in the DB2 for VM production disk accessed by the Application Requester. The Application Requester uses this NETID for the generation of the LUWID that flows with each conversation.
You must define the remote systems by registering the LU names that enable VTAM to locate the desired network destination. When AVS starts, it identifies the global gateway names (the LU names) available for routing SQL requests into the network to VTAM. A gateway name must be unique within the set of LU names recognized by the local VTAM system so that both inbound and outbound requests are routed to the proper LU name. This is the best way to ensure gateway name uniqueness throughout the user network. This in turn simplifies the VTAM resource definition process.
When a DB2 for VM application requests data from a remote system, DB2 for VM searches the CMS Communications Directory for the following information relating to the remote system:
The CMS Communications Directory is a CMS file with file type NAMES, which is created and managed by a DB2 for VM system administrator. As the administrator, you can use XEDIT to create this file and add the desired entries to identify each potential DRDA partner. Each entry in the directory is a set of tags and their associated values. Figure 31 shows a sample entry. When a search is performed, the search key is compared to the :dbname tag value of each entry in the file until a match is found or the end of the file is reached. In the example in Figure 31, the sales manager in Toronto wants to create a monthly sales report for the Montreal branch by accessing data remotely from the MONTREAL_SALES database.
Figure 31. A sample entry in a CMS Communications Directory
+--------------------------------------------------------------------------------+ | SCOMDIR NAMES A1 V 132 Trunc=132 Size=10 Line=1 Col=1 Alt=8 | |====> | |00001 :nick.MTLSALES | |00002 :tpn.SALES | |00003 :luname.TORGATE MTLGATE | |00004 :modename.BATCH | |00005 :security.PGM | |00006 :userid.SALESMGR | |00007 :password.GREATMTH | |00008 :dbname.MONTREAL_SALES | |00009 | +--------------------------------------------------------------------------------+ |
The :tpn tag identifies the transaction program name that activates the Application Server. The first part of the :luname tag identifies the AVS gateway (local LU) used to gain access to the SNA network. The second part identifies the remote LU name. The :modename tag identifies the VTAM mode that defines the characteristics of the sessions allocated between the local and remote LUs. Request unit (RU) size, pacing, and class of service (COS) are examples of such characteristics. The :security tag indicates the level of security to use on the conversation connecting the Application Requester to the Application Server.
The CMS Communications Directory is on a public system disk accessible to all application requesters in a particular VM system. Any program or product that requires remote access through VTAM can use the CMS Communications Directory.
You can access two levels of the CMS Communications Directory: system-level and user-level. For example, you can create a system-level directory on a public system disk accessible to all Application Requesters in a particular VM system. You can also create your own user-level directory to override existing entries or introduce new entries not appearing in the system-level directory. The user-level directory is searched first, and if the search fails, then the system-level directory is searched. The system-level directory is an extension of the user-level directory; it is searched only if the values are not found in the user-level directory.
Each of these directories is identified to the application and activated through the CMS SET COMDIR command. For example, you can use the following command sequence to identify both system and user-level directories (on the S and A minidisks respectively) but choose to activate only the system-level directory for searches:
SET COMDIR FILE SYSTEM SCOMDIR NAMES S SET COMDIR FILE USER UCOMDIR NAMES A SET COMDIR OFF USER
The CMS Communications Directory is described in detail in VM/ESA Connectivity Planning, Administration and Operation. The CMS SET COMDIR command is described in VM/ESA CMS Command Reference.
In the VM environment, a combination of components performs communication management. The components involved in the communication among unlike DRDA systems are APPC/VM, CMS Communications Directory, TSAF, AVS, and VTAM.
APPC/VM is the LU 6.2 assembler-level API that the DB2 for VM Application Requester uses to request communications services. The CMS Communications Directory provides the routing and security information of the distributed partner system. AVS activates the gateway and translates outbound APPC/VM flows into APPC/VTAM flows, and inbound APPC/VTAM flows into APPC/VM flows.
APPC/VM, TSAF, and AVS rely on the CMS Communications Directory, VTAM, and *IDENT to route requests to the proper DRDA partner.
For VTAM to communicate with the partner applications identified in the CMS Communications Directory, you must provide the following information:
AVS session limit considerations:
When an application requester uses AVS to communicate with a remote application server, a connection is initiated. If this connection causes the established session limit to be exceeded, AVS defers the connection to a pending state until a session becomes available. When a session becomes available, AVS allocates the pended connection on the session, and control is returned to the user application. To avoid this situation, plan for peak usage by increasing session limit to allow for some additional connections. Ensure that the MAXCONN value in the CP directory of the AVS machine is large enough to support peak usage by the APPC/VM connections.
The entries you define in the VTAM mode table specify request unit (RU) sizes and pacing counts. Failure to define these values correctly can have an adverse effect on all VTAM applications.
After choosing request unit (RU) sizes, session limits, and pacing counts, consider the impact these values can have on your existing SNA 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 your RU size plus 29 bytes. For NCP, the MAXBFRU parameter defines the number of VTAM I/O buffers that can 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 DB2 for VM application requester may not have DRDA support installed. Follow the following steps to prepare the DB2 for VM application requester for DRDA communications:
See the DB2 for VM System Administration manual for details.
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:
In both SQL and LU 6.2, end users are assigned a 1- to 8-character user ID. This user ID value must be unique within a particular operating system, but is not necessarily unique throughout the SNA network. For example, there can be a user named JONES in the TORONTO system and another user named JONES on the MONTREAL system. If these two users are the same person, no conflict exists. However, if the JONES in TORONTO is not the same person as the JONES in MONTREAL, the SNA network (and consequently the distributed database systems within that network) cannot distinguish between JONES in TORONTO and JONES in MONTREAL. If no steps are taken to prevent this situation, JONES in TORONTO can use the privileges granted to JONES in MONTREAL and vice versa.
To eliminate naming conflicts, DB2 for VM provides support for end user name translation. However, the system does not enforce translation of user IDs. If system-enforced translation is required, you should ensure that proper inbound translation is performed at the application server.
Outbound translation is performed using the CMS Communications Directory. An entry in the CMS Communications Directory must specify :security.PGM. In this case, the corresponding values in the :userid and :password tags flow to the remote site (Application Server) in the connection request.
By creating the entry shown in Figure 32, the user with ID JONES on the local (TORONTO) system is mapped to user ID JONEST when he connects to the MONTREAL_SALES_DB Application Server on the MONTREAL system. In this way, the user ID ambiguity is eliminated.
Figure 32. Outbound Name Translation
+--------------------------------------------------------------------------------+ | UCOMDIR NAMES A1 V 132 Trunc=132 Size=10 Line=1 Col=1 Alt=8 | |====> | |00001 :nick.MTLSALES | |00002 :tpn.SALES | |00003 :luname.TORLU MTLGATE | |00004 :modename.BATCH | |00005 :security.PGM | |00006 :userid.JONEST | |00007 :password.JONESPW | |00008 :dbname.MONTREAL_SALES_DB | |00009 | +--------------------------------------------------------------------------------+ |
Having selected the end user name that represents the application requester at the remote site (Application Server), the application requester must provide the required LU 6.2 network security information. LU 6.2 provides three major network security mechanisms:
Because the application server is responsible for managing the database resources, the application server dictates which network security mechanisms the application requester must provide. You must record the application server's security requirements in the application requester's communications directory by setting the appropriate value in the :security tag.
The SNA conversation-level security options supported by DRDA are:
DB2 for VM does not support password encryption. The password can be specified in the :password tag, or it can be stored in the end user's CP directory entry using an APPCPASS directory statement. The APPCPASS statement is recommended if you want to maximize the security of the password. If the password is not specified in the CMS Communications Directory entry, the user's system (VM) directory entry is searched for an APPCPASS statement.
VM provides the APPCPASS statement to maximize the security of the user ID and password used by the Application Requester to connect to an Application Server. The APPCPASS is flexible in that it allows you to store security information in one of the following ways:
Figure 33 illustrates the case where the user ID is stored in the user's communications directory and the password is stored in the user's VM directory entry. In the communications directory entry, the user ID is set to MTLSOU, but the password is not set. The password is stored in the user's VM directory entry.
Figure 33. Example of a communications directory entry without a password
+--------------------------------------------------------------------------------+ | UCOMDIR NAMES A1 V 132 Trunc=132 Size=8 Line=1 Col=1 Alt=8 | |====> | |00001 :nick.MTLSALES | |00002 :tpn.SALES | |00003 :luname.TORGATE MTLGATE | |00004 :modename.BATCH | |00005 :security.PGM | |00006 :userid.MTLSOU | |00007 :password. | |00008 :dbname.MONTREAL_SALES_DB | |00009 | +--------------------------------------------------------------------------------+ |
When APPC/VM initiates the connection between the Application Requester and the Application Server using conversation SECURITY=PGM, it reads the :userid and :password tag values and passes them to the Application Server. If one or both of these tags is set to blanks, it searches the user's VM directory entry for the missing information. In this case, you must have an APPCPASS statement in the VM directory entry as follows:
APPCPASS TORGATE MTLGATE MTLSOU Q6VBN8XP
This statement tells APPC/VM that the user (Application Requester) requesting the connection via the (local) AVS gateway TORGATE, the partner LU named MTLGATE, and the user ID MTLSOU should send the password Q6VBN8XP to the Application Server. The user is known by these two pieces of identification at the Application Server.
Placing the APPCPASS statement in the VM directory is not an end user task. The end user must place a request with the VM systems programmer to do this.
For more information on conversation-level security and the APPCPASS statement refer to VM/ESA Connectivity Planning, Administration, and Operation.
As part of the overall distributed database security framework in DRDA, the Application Requester can play a role in controlling which end users are allowed to make distributed database requests. In DB2 for VM, the Application Requester can participate in distributed database security in three ways:
The external security subsystem on VM systems is provided by either RACF or equivalent products that provide an interface compatible with RACF. The DB2 for VM Application Requester does not interface directly to the external security subsystem. The external security subsystem is not used to provide passwords for conversation-level security. If you choose to use session-level security, the external security subsystem is called by VTAM to validate the identity of the remote LU name during partner LU verification.
The application requester must have the appropriate default CHARNAME and CCSID values. Choosing the correct values ensures the integrity of character data representation and reduces performance overhead associated with CCSID conversion.
For example, if your DB2 for VM application requester is generated with code page 37 and character set 697(CP/CS 37/697) for US ENGLISH characters, then the application requester should set the default CHARNAME to ENGLISH. This is because CP/CS 37/697 corresponds to the CCSID of 37, which corresponds to the CHARNAME of ENGLISH.
The default CHARNAME of a newly installed or migrated system is INTERNATIONAL and the CCSID is 500. This is probably not correct for your installation. To display the values of the current default CCSIDs, use the following command:
SQLINIT QUERY
The appropriate CCSID value for the application requester might be one that is not supported by conversion tables at the application server. If this is the case, you can establish the connection by doing one of the following:
An application requester uses a controller defined with CP/CS 37/697. The application server does not support a conversion from CCSID 37, but does support a conversion from CCSID 285 (this is CHARNAME UK-ENGLISH for SQL/DS).
If the application requester is changed to use a default CHARNAME of UK-ENGLISH (and CCSID of 285) then data integrity will not be maintained. For example, where a British pound sign character (¶) is meant by the application server, the application requester displays a dollar sign ($). Other characters might also be different.
To change the CCSID value of a DB2 for VM application requester, you must specify the CHARNAME parameter of the SQLINIT EXEC. See the DB2 for VM System Administration manual for more detailed information.
The appropriate CCSID value for the application server might be one that is not supported by conversion tables at the application requester. If this is the case, you can establish the connection by doing one of the following:
The following checklist summarizes the steps needed to enable a DRDA Application Requester 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.