After the function dc_rpc_call() is called, a synchronous-response-type RPC waits for the processing results of the server UAP. To use the synchronous-response-type RPC, set DCNOFLAGS (or DCRPC_CHAINED) into flags of the function dc_rpc_call().

(a) Time monitoring of a synchronous-response-type RPC

The response time after using the function dc_rpc_call() is monitored in one of the following values:

• TP1/Server Base:
  Value specified for watch_time in the user service definition
  
• TP1/LiNK:
  180 minutes
  

If a long server UAP processing time prevents the response from being returned within the specified monitoring time, the function dc_rpc_call() returns with an error.

The server UAP is aware of the response wait time on the client UAP. Therefore, when the function dc_rpc_call() returns with an error, the server UAP discards services that were scheduled after timeout occurred on the client UAP and does not process them. It also aborts processing of the service that was being run and does not return a response. You can instruct the server UAP to output a message indicating that the service request was discarded due to timeout on the client UAP. To do this, specify set rpc_extend_function=00000008 in the user service definition for the server UAP.

If the server UAP terminates abnormally, the function dc_rpc_call() returns with an error immediately. In any of the following cases, this function returns with an error after the specified monitoring time has elapsed:

• If the entire portion of OpenTP1 for the node at which the server UAP exists terminates abnormally
• If an error occurs before the server UAP receives service request data, or after the server UAP completes processing and before the client UAP receives the processing results

The figure below shows the synchronous-response-type RPC.

Figure 2-4 Synchronous-response-type RPC

After the function dc_rpc_call() is called, an asynchronous-response-type RPC continues processing without waiting for the processing results of the server UAP. RPC parallel processing can be executed by using more than one asynchronous-response-type RPC.

The function dc_rpc_call() (DCRPC_NOWAIT set in flags) of an asynchronous-response-type RPC returns after requesting a service. The UAP proceeds to processing after the function returns.

An asynchronous-response-type RPC returns without checking the acceptance of the service request by the server. When a client UAP requests services through two or more asynchronous-response-type RPCs to a service group, the server may not accept the services in the order which these RPCs were issued.

(a) Receiving asynchronous-response-type RPC response

The asynchronous-response-type RPC receives the processing results of the server UAP asynchronously by using the function dc_rpc_poll_any_replies() [CBLDCRPC('POLLANYR')]. The processing results can be received only when the function dc_rpc_poll_any_replies() is called.

When asynchronous-response-type RPC responses are being received, a particular response to be received can be identified. To identify a response, the positive integer (descriptor) returned by the function dc_rpc_call() for the request of the service through asynchronous-response-type RPC must be specified as the argument to the function dc_rpc_poll_any_replies(). With this specification, an asynchronous-response-type RPC response identified by the descriptor is received.

If no particular response is identified, the responses are received in the order of their returns. When the function dc_rpc_poll_any_replies() returns normally if no response is identified, the same value as the descriptor of the received asynchronous response is returned.

An error is returned if the call count of the function dc_rpc_poll_any_replies() is greater than the call count of the function dc_rpc_call() of the asynchronous-response-type RPC.

If an error occurs upon a service request, an error is returned to the function dc_rpc_poll_any_replies().

Assume that you call the function dc_rpc_call() for which DCRPC_NOWAIT is set in flags and then you call a function that executes transaction synchronization point processing before the response to the function dc_rpc_call() has been received. In such a case, when you subsequently call the function dc_rpc_poll_any_replies(), it returns with the error DCRPCER_ALL_RECEIVED and no response can be received. When an asynchronous-response type RPC is used, the response must be received before you execute transaction synchronization point processing for that process, regardless of whether or not the RPC was executed within the transaction.

(b) Time monitoring of an asynchronous-response-type RPC

When an asynchronous-response-type RPC is used, the value specified in watch_time of the user service definition is not referenced. For the argument timeout, specify the maximum response wait time from when the function dc_rpc_poll_any_replies() is called to when a response is returned.

If a long server UAP processing time prevents the response from being returned within the specified monitoring time, the function dc_rpc_poll_any_replies() returns with an error.

If the server UAP terminates abnormally, the function dc_rpc_poll_any_replies() returns with an error immediately. In any of the following cases, this function returns with an error after the specified monitoring time has elapsed:

• If the entire portion of OpenTP1 for the node at which the server UAP exists terminates abnormally
• If an error occurs before the server UAP receives service request data, or after the server UAP completes processing and before the client UAP receives the processing results

The figure below shows the asynchronous receiving of processing results.

Figure 2-5 Asynchronous-response-type RPC (asynchronous receiving of processing results)

(c) Rejecting the receiving of processing results

If you do not want to receive any more replies (which have not been returned) when an asynchronous-response-type RPC is used, call the function dc_rpc_discard_further_replies() [CBLDCRPC ('DISCARDF')] for rejecting the receiving of processing results. Replies returned after this function is called are discarded instead of being received. Call this function for rejecting the receiving of processing results when not receiving the results of an asynchronous-response-type RPC. Otherwise, the function dc_rpc_poll_any_replies() of another asynchronous-response-type RPC might receives unnecessary replies.

Use the function dc_rpc_discard_further_replies() in the following cases:

• After a response wait timeout occurs, you want to release the buffer for shutting down results before proceeding to the next processing.
• You want only the first response when having issued more than one asynchronous-response-type RPCs.

If you do not want to receive a selected response among responses which have not been returned when an asynchronous-response-type RPC is used, call the function dc_rpc_discard_specific_reply() [CBLDCRPC('DISCARDS')] for rejecting reception of selected processing results. Responses which have the same descriptor as the specified descriptor among the responses returned after this function is called are discarded instead of being received.

The figure below shows the rejection of receiving processing results.

Figure 2-6 Asynchronous-response-type RPC (rejection of receiving processing results)

(d) Relationship between an asynchronous-response-type RPC and a synchronization point

If an asynchronous-response-type RPC is called in a transaction, replies cannot be received asynchronously after synchronization point processing is executed. For details on the relationship between a synchronization point and an asynchronous-response-type RPC, see 2.3.4 Relationship between remote procedure call modes and synchronization points.

A nonresponse-type RPC does not return the processing results of the server UAP to the client UAP. The client UAP cannot receive the processing results of the server UAP.

Nonresponse-type RPC time is not monitored.

The function dc_rpc_call() (DCRPC_NOREPLY set in flags) of the nonresponse-type RPC returns after requesting a service. The UAP proceeds to processing after the function returns. The processing results of the server UAP cannot be received.

A nonresponse-type RPC returns without checking the acceptance of the service request by the server. Therefore, if the service request is lost because of an error (e.g., communication failure), the client UAP cannot recognize this. When a client UAP requests services through two or more nonresponse-type RPCs to a service group, the server may not accept the services in the order which these RPCs were issued.

The figure below shows the nonresponse-type RPC.

Figure 2-7 Nonresponse-type RPC