Each DB2 for VM database manager can manage one or more databases (one at a time) and is typically referred to by the name of the database it manages currently. This relational database name is unique within a set of interconnected SNA networks.
The various DRDA and VM components involved in distributed database processing are described below. These components enable the DB2 for VM database managers to access local relational databases and to communicate with remote DRDA systems in the SNA network.
On the application requester side, a user must be authorized to connect through an AVS gateway before the requests can be sent. On the application server side, the receiving AVS gateway must also be authorized to connect to the DB2 for VM server machine before AVS can pass on the user's requests. The authorization is done by providing the appropriate IUCV directory control statements in the user machine, the database machine, and the sending and receiving AVS machines. For details on how to do this, refer to the VM/ESA Connectivity Planning, Administration, and Operation manual.
DB2 for VM uses the COMDIR tag :dbname to resolve the RDB_NAME to its corresponding routing data.
This special file and its communication function are described in the VM/ESA Connectivity Planning, Administration, and Operation.
GCS supervises the execution of VTAM applications such as AVS in a VM environment. Virtual machines running under the supervision of GCS do not use CMS.
DB2 for VM uses TSAF to route distributed database requests to other DB2 for VM machines within the TSAF collection. If the local VM system does not have an AVS virtual machine, DB2 for VM uses TSAF to route DRDA requests to a VM system that does have an AVS virtual machine. AVS allows the request to be forwarded to other TSAF collections and non-DB2 for VM systems.
A TSAF collection is viewed as one or more logical units in the SNA network. Resources defined as global within a TSAF collection can be accessed by remote APPC programs residing anywhere in the collection.
Typically, a TSAF collection operates in stand-alone fashion, independent of VTAM and the SNA network. However, it can cooperate with AVS and VTAM to make its global resources accessible by remote APPC programs residing anywhere in the SNA network. This requires that an AVS machine and a VTAM machine are operating on one or more of the TSAF members. TSAF is described in the VM/ESA Connectivity Planning, Administration, and Operation manual.
The following example shows how each component plays a role in establishing communications between a VM Application Requester and a remote DRDA server. Figure 27 shows how the application requester connects to AVS and uses VTAM to access the SNA network. Access to remote resources is not routed through the local DB2 for VM application server.
Figure 27. Requesting Access to a Remote Resource
|
Suppose a DB2 for VM Application Requester that operates in a TSAF collection is to access remote data managed by a DRDA Application Server. By definition, this implies a TSAF machine is operating on the local VM host where the Application Requester resides. Also, an AVS component and a VTAM machine are operating on a VM system in this TSAF collection. AVS and VTAM might also reside on the same system as the Application Requester and the Application Server.
After the VTAM machine starts, it defines the local AVS gateway to the SNA network and activates one or more sessions to use later for establishing conversations.
After the AVS machine starts, it negotiates session limits between the local AVS gateway and the potential partner LUs.
The Application Server might or might not be active. The operator must start it before it can process requests from a like or unlike Application Requester.
The application requester issues an APPC/VM CONNECT statement to establish an LU 6.2 conversation with the Application Server. The CONNECT function uses the CMS Communications Directory to resolve the relational database name into its associated LU name and TPN that comprise the address of the Application Server in the SNA network. The CMS Communications Directory also determines the level of conversation security and security tokens, such as user ID and password, to pass to the remote site for authorization purposes. If SECURITY=PGM is used, the Application Requester must pass a user ID and password to the Application Server. You can specify the user ID and password in the CMS Communications Directory or in the APPCPASS record defined with the application requester user's CP directory. If SECURITY=SAME is used, then only the VM logon ID of the application requester user is sent to the application server, and no extra password is required.
For example, if you use SECURITY=SAME, the host checks if an AVS machine is operating locally. If it is not, the host establishes a connection between the application requester and the local TSAF machine. The local TSAF machine polls the other TSAF machines in the TSAF collection for the AVS machine and then establishes a connection to it.
The AVS component in the TSAF collection converts the APPC/VM connection request to its APPC/VTAM equivalent function call. AVS then uses an existing session or allocates a new session between its gateway (LU) and the remote LU. AVS then establishes a conversation with the remote LU and passes it the LU name, TPN, security level, and user ID. If the remote LU is also a VM system, the session and conversation are handled by the AVS component running on that system.
The following example shows how each component plays a role in establishing communications between a remote Application Requester and a local DB2 for VM DRDA server. Figure 28 shows that VTAM routes the inbound connection to the specific AVS gateway and then to the Application Server.
Figure 28. Gaining Access to a Remote Resource
|
Suppose a DB2 for VM Application Server operates in a TSAF collection. By definition, this implies a TSAF machine is operating on the local VM host where the Application Server resides. Also, an AVS component and a VTAM machine are operating on a VM system in this TSAF collection. AVS and VTAM might also reside on the same system as the Application Requester and the Application Server.
After the VTAM machine starts, it defines the local AVS gateway to the SNA network and activates one or more sessions to use later for establishing conversations.
After the AVS machine starts, it negotiates session limits between the local AVS gateway and the potential partner LUs.
The Application Server might or might not be active. The operator must start it before it can process requests from a like or unlike Application Requester. After the Application Server starts, it uses the *IDENT service to register the resource ID that it manages with the host VM system. Each registration creates an entry in an internal resource table maintained by the VM system.
After the local AVS component establishes the session with its partner LU, it accepts the conversation and passes the TPN, user ID, and password to the VM host for validation. VM searches for the TPN in its internal resource table. This table contains an entry for each resource ID registered through the *IDENT system service. If the TPN search is successful, VM validates the user ID and password with its directory, or RACF or a similar security product. If the validation is successful, AVS establishes a connection to the Application Server and passes it the user ID for database authorization purposes.
If the table search is unsuccessful, AVS rationalizes that the TPN might reside in another VM system in the TSAF collection and establishes a connection to the local TSAF machine, passing it the user ID, password, and TPN. The TSAF machine polls the other TSAF machines in the TSAF collection. If one of these machines acknowledges the existence of the TPN in its resource table, the local TSAF machine connects to the remote TSAF machine and passes it the user ID and password to be verified with its VM directory. If the validation is successful, the remote TSAF machine connects to the Application Server and passes it the user ID for database authorization.
If the Application Requester wishes to take advantage of DRDA distributed unit of work support, it establishes a protected conversation (such as, SYNCLEVEL=SYNCPT) with the DB2 for VM Application Server. Before CMS presents the connection to DB2 for VM, it creates a CMS work unit for the protected conversation on the DB2 for VM machine. DB2 for VM then uses this CMS work unit whenever it performs work for the requester. When DB2 for VM begins doing work for the requester, it registers this CMS work unit with the CRR sync point manager. Then, when DB2 receives a "take commit" or "take rollback" indication on the protected conversation, it asks the CRR sync point manager to commit or roll back the unit of work. The CRR sync point manager then drives the commit or rollback, asking the CRR Recovery Server to perform sync point logging when necessary.
Depending on the routing complexity of the connection, the APPC conversation between the Application Requester and Application Server can involve additional systems. However, all the intermediate connections are managed by VM and are transparent to the Application Requester or the user application. The APPC/VM interface lets DB2 for VM Application Servers communicate with APPC application programs located in:
