In this mode, a CUP sends an inquiry message to an SPP and receives a response message. The CUP waits for the processing results to be returned from the SPP before executing the next processing. If the same service is called more than once, the server process is scheduled each time.

The following figure shows the processing flow of a synchronous-response RPC.

Figure 2-3 Processing flow of a synchronous-response RPC

In this mode, a CUP sends an inquiry message to an SPP but does not receive a response message. Once it has sent an inquiry message to the SPP, the CUP immediately executes the next processing without waiting for the processing results from the SPP.

In the case of a non-response type RPC, you cannot receive an error in the event of a communication error or service error.

The following figure shows the processing flow of a non-response type RPC.

Figure 2-4 Processing flow of a non-response type RPC

In this mode, a CUP that uses the remote API facility sends an inquiry message to an SPP and receives a response message. The CUP waits for the processing results to be returned from the SPP before executing the next processing. The difference from a synchronous-response RPC is that a chained RPC can fix the server process. This means that when multiple inquiry messages are sent to the same service by means of chained RPCs, the server process is not rescheduled.

Chained RPCs require fewer user processes per transaction, thereby reducing the workload of transaction processing. A chained RPC used as a transaction functions in a single global transaction.

Starting chained RPCs

To issue a service request for chained RPCs, specify DCRPC_CHAINED in the flags parameter of the rpcCall method that requests the service. When a service is requested with this value specified, the SPP identifies it for chained RPCs and acquires a process. For the second and subsequent service requests, you must also specify DCRPC_CHAINED in the flags argument.

Terminating chained RPCs

The following methods are provided for terminating chained RPCs:

• Execute the rpcCall method (synchronous-response RPC) with DCNOFLAGS specified in the flags parameter for the service group that has been executing the chained RPCs.
• Complete the global transaction that has been executing the chained RPCs by synchronization point processing (commit or rollback).

Note

If you call the closeConnection or rpcClose method without executing a synchronous-response RPC, the following occurs:

• Outside the global transaction range
  The process executing the service is locked until the chained RPC timeout occurs.
  
• Within the global transaction range
  Implicit commit occurs and the chained RPC is terminated.
  

Time monitoring of chained RPCs

A UAP whose service is requested with a chained RPC monitors the time until the next service request arrives or until transaction synchronization point processing occurs after a response is returned to the CUP. If no service request or synchronization point processing request is received within this monitoring interval, the UAP determines that an error has occurred in the CUP and terminates the SPP abnormally. You specify the monitoring interval in the watch_next_chain_time operand of the user service definition.