CA IDMS DDS System Operations › Processing Application Requests

Processing Application Requests

Processing application requests for database services in the CA IDMS DDS environment involves:

1. Identifying the target database and node
2. Routing database requests to the target node
3. Servicing database requests

Identifying the target database and node

When a request unit signs on to its host node, it names a target database and/or node. This action signals to the host node that all requests for database services are to be routed to the named node or database. If the unit names only a target node and no database, the target node selects the default database (under its control) as the one to be accessed to service requests issued by the request unit. If the request unit names the host node or a database controlled by the host node, all requests for database services are handled by the host node.

Routing database requests to the target node

After the target node has been identified, the optimum path is selected along which to route database requests from the host node to the target node. The selected path is used to transfer every database requests issued by the request unit. If the path becomes unavailable at any point during request unit processing, another path is automatically selected if one is available.

Servicing database requests

When the request unit issues a database access request, the host node signals CA IDMS DDS to transfer the request and any accompanying data to the target node. The request and data are routed along the selected path to the target node. The target node performs the requested database operation and returns a response to the host node, which in turn passes the results of the request to the request unit.

Target nodes do the work

Each database request issued by the request unit is serviced in the same manner: the host node passes a request to the target node, which services the request and returns a response to the host node. If, at any point during run-unit execution, the application program abends, the target node performs any necessary recovery of the database being accessed. When the request unit terminates normally, the application program can begin a new request unit.

When a batch to CV application accessing SYSTEM01 requests database services from SYSTEM02, the following sequence of events occurs:

1. The request is passed from the CA IDMS batch interface, called by the application program, to the host node (SYSTEM01).
2. The host node builds a database request packet and posts the CA IDMS DDS line driver to transmit the packet to the target node (SYSTEM02). Depending on the access method associated with the target node in the NODE table, that CA IDMS DDS line driver can be the CCI line driver (CCI), the SOCKET line driver (TCP/IP) or the DDS line driver (VTAM).
3. The CA IDMS DDS line driver transmits the packet to its counterpart on the target node.
4. The CA IDMS DDS line driver on the target node receives the packet, validates the message, and passes the packet to the CV executing on the target node to process the request.
5. The target node processes the request. Database access, if required, is performed by the DBMS within the target node.
6. The target node builds a response packet with the necessary data and posts the CA IDMS DDS line driver to transmit the packet back to its counterpart on the host node.
7. The CA IDMS DDS line driver on the host node receives the packet, validates the message, and passes the packet to the task executing on the host node; the response data is then passed to the application program.

The following illustration shows the process involved in executing a database request through CA IDMS DDS.

Applications executing in the CA IDMS DDS environment can execute multiple request units sequentially or concurrently. Each concurrently executing request unit can access a different database and/or node.