OpenTP1 Version 7 Programming Guide

[Contents][Index][Back][Next]

5.1.3 Request/response service paradigm

XATMI-interfaced communication based on the request/response service paradigm is explained below.

Organization of this subsection
(1) Types of request/response service
(2) Time monitoring involved in communication based on request/response service paradigm
(3) Relationship between communication based on request/response service paradigm and transaction
(4) Responses to blocking

(1) Types of request/response service

The following types of request/response service based communication are available:

(a) Communication with synchronous response reception

A request for a service is issued, then a response is awaited. The function tpcall() [TPCALL] is used to request a service.

Time monitoring:
Communication with synchronous response reception involves monitoring of times taken before a response returns. The maximum response waiting interval is specified in the OpenTP1 definition. For details on the definition, see the manual OpenTP1 System Definition.
If the process which calls the function tpcall() is under a transaction, the maximum response waiting interval is the value assigned to trn_expiration_time in the definition. In this case, the process terminates abnormally when the maximum response waiting interval expires (tpcall() does not return with an error).
If the process which calls the function tpcall() is not under a transaction, the maximum response waiting interval is the value assigned to watch_time in the definition. In this case, the function tpcall() returns with an error when the maximum response waiting interval expires.

The figure below shows the communication with synchronous response reception based on the request/response service paradigm.

Figure 5-1 Communication with synchronous response reception based on request/response service paradigm

[Figure]

(b) Communication with asynchronous response reception

A service is requested, then processing continues without waiting for a response. Then, a function is issued to receive a response. The function tpacall() [TPCALL] is used to request service and the function tpgetrply() [TPGETRPLY] is used to receive a response.

Time monitoring:
Communication with asynchronous response reception involves a process in which the communication party waits until the function tpgetrply() receives a response. The maximum response waiting interval is specified in the OpenTP1 definition. For details on the definition, see the manual OpenTP1 System Definition.
If the process which calls the function tpacall() or tpgetrply() is under a transaction, the maximum response waiting interval is the value assigned to trn_expiration_time in the definition. In this case, the process terminates abnormally when the maximum response waiting interval expires (tpgetrply() does not return with an error).
If the process which calls the function tpacall() or tpgetrply() is not under a transaction, the maximum response waiting interval is the value assigned to watch_time in the definition. In this case, the function tpgetrply() returns with an error when the maximum response waiting interval expires.

The figure below shows the communication with asynchronous response reception based on the request/response service paradigm.

Figure 5-2 Communication with asynchronous response reception based on request/response service paradigm

[Figure]

(c) Communication without response reception

The result of the service request is not returned. With this type of communication, TPNOREPLY is specified for flags of the function tpacall(). Note that TPNOTRAN must also be specified for flags of the function tpacall().

When a service request is used through this type of communication, no response is returned. The UAP which requested that service continues processing.

The figure below shows the communication without response reception based on the request/response service paradigm.

Figure 5-3 Communication without response reception based on request/response service paradigm

[Figure]

(2) Time monitoring involved in communication based on request/response service paradigm

In communication based on the request/response service paradigm, time monitoring is always performed according to the values specified in the OpenTP1 definition. For details on the definition, see the manual OpenTP1 System Definition.

There are two types of timeout: transaction timeout and blocking timeout. The transaction timeout is a timeout that is encountered during the transaction process, whereas the blocking timeout is caused by a wait in blocking status. If a transaction timeout occurs, the process terminates abnormally.

The process may wait beyond the specified timeout value (because the OpenTP1 monitoring timer is reset even if a response other than the appropriate data is returned). If TPNOTIME is specified for flags, the timeout value is infinite. Note that the transaction timeout occurs regardless of whether this flag is set.

(3) Relationship between communication based on request/response service paradigm and transaction

The transaction is controlled by a transaction control function available with OpenTP1 (function dc_trn_~ or tx_~). Whether a transaction under OpenTP1 is settled or is in rollback_only status is determined from the result of the service function or the transaction control function. In communication based on the request/response service paradigm, however, the transaction branch concerned enters rollback_only status if one of the following errors occurs:

(a) Transaction control involved in communication with synchronous response reception

If the caller process is under a transaction, whether the called service is treated as a transaction is determined by the parameter set in the flags argument to the function tpcall(). Set TPNOTRAN only when the called service is not to be treated as a transaction. A transaction timeout may occur even if TPNOTRAN is set.

(b) Transaction control involved in communication with asynchronous response reception

If the caller process is under a transaction, whether the called service is treated as a transaction is determined by the parameter set in the flags argument to the function tpacall(). Set TPNOTRAN only when the called service is not to be treated as a transaction. A transaction timeout may occur even if TPNOTRAN is set.

(c) Transaction control involved in communication without response reception

In communication without response reception, no service can be treated as a transaction. TPNOTRAN must always be specified for the flags argument to the function tpacall().

(4) Responses to blocking

Functions for communication based on the request/response service paradigm have the TPNOBLOCK flag that indicates the necessary action against blocking. The function tpgetrply() with this flag returns with an error if it detects blocking. If this flag is not set, the function waits until blocking is removed or a blocking timeout occurs (if TPNOTIME is set, however, no blocking timeout error occurs). Under OpenTP1, this flag has effect only on the function tpgetrply(). Even if this flag is set for the function tpcall() or tpacall(), it is ignored.