ATMI C Function Reference
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
tpcall()
—Routine for sending service request and awaiting its reply.
int tpcall(char *svc, char *idata, long ilen, char **odata, long \
*olen, long flags)
tpcall()
sends a request and synchronously awaits its reply. A call to this function is the same as calling tpacall()
immediately followed by tpgetrply()
. tpcall()
sends a request to the service named by svc
. The request is sent out at the priority defined for svc
unless overridden by a previous call to tpspri()
. The data portion of a request is pointed to by idata
, a buffer previously allocated by tpalloc()
. ilen
specifies how much of idata
to send. Note that if idata
points to a buffer of a type that does not require a length to be specified, (for example, an FML
fielded buffer), then ilen
is ignored (and may be 0). Also, idata
may be NULL, in which case ilen
is ignored. The type and subtype of idata
must match one of the types and subtypes recognized by svc
.
odata
is the address of a pointer to the buffer where a reply is read into, and olen
points to the length of that reply. *odata
must point to a buffer originally allocated by tpalloc()
. If the same buffer is to be used for both sending and receiving, odata
should be set to the address of idata
. FML
and FML32
buffers often assume a minimum size of 4096 bytes; if the reply is larger than 4096, the size of the buffer is increased to a size large enough to accommodate the data being returned. Also, if idata
and *odata
were equal when tpcall()
was invoked, and *odata
is changed, then idata
no longer points to a valid address. Using the old address can lead to data corruption or process exceptions. As of release 6.4, the default allocation for buffers is 1024 bytes. Also, historical information is maintained on recently used buffers, allowing a buffer of optimal size to be reused as a return buffer.
Buffers on the sending side that may be only partially filled (for example, FML or STRING buffers) will have only the amount that is used send. The system may then enlarge the received data size by some arbitrary amount. This means that the receiver may receive a buffer that is smaller than what was originally allocated by the sender, yet larger than the data that was sent.
The receive buffer may grow, or it may shrink, and its address almost invariably changes, as the system swaps buffers around internally. To determine whether (and how much) a reply buffer changed in size, compare its total size before tpgetrply()
was issued with *len
. See Introduction to the C Language Application-to-Transaction Monitor Interface for more information about buffer management.
If *olen
is 0 upon return, then the reply has no data portion and neither *odata
nor the buffer it points to were modified. It is an error for *odata
or olen
to be NULL.
The following is a list of valid flags
:
If the caller is in transaction mode and this flag is set, then when svc
is invoked, it is not performed on behalf of the caller's transaction. Note that svc
may still be invoked in transaction mode but it will not be the same transaction: a svc
may have as a configuration attribute that it is automatically invoked in transaction mode. A caller in transaction mode that sets this flag is still subject to the transaction timeout (and no other). If a service fails that was invoked with this flag, the caller's transaction is not affected.
By default, if a buffer is received that differs in type from the buffer pointed to by *odata
, then *odata
's buffer type changes to the received buffer's type so long as the receiver recognizes the incoming buffer type. When this flag is set, the type of the buffer pointed to by *odata
is not allowed to change. That is, the type and subtype of the received buffer must match the type and subtype of the buffer pointed to by *odata
.
The request is not sent if a blocking condition exists (for example, the internal buffers into which the message is transferred are full). Note that this flag applies only to the send portion of tpcall()
: the function may block waiting for the reply. When TPNOBLOCK
is not specified and a blocking condition exists, the caller blocks until the condition subsides or a timeout occurs (either transaction or blocking timeout).
This flag signifies that the caller is willing to block indefinitely and wants to be immune to blocking timeouts. However, if the caller is in transaction mode, this flag has no effect; it is subject to the transaction timeout limit. Transaction timeouts may still occur.
In a multithreaded application, a thread in the TPINVALIDCONTEXT
state is not allowed to issue a call to tpcall()
.
Upon successful return from tpcall()
or upon return where tperrno
is set to TPESVCFAIL
, tpurcode()
contains an application defined value that was sent as part of tpreturn()
.
Upon failure, tpcall()
returns -1 and sets tperrno
to indicate the error condition. If a call fails with a particular tperrno
value, a subsequent call to tperrordetail()
, with no intermediate ATMI calls, may provide more detailed information about the generated error. Refer to the tperrordetail(3c)
reference page for more information.
Upon failure, tpcall()
sets tperrno
to one of the following values. (Unless otherwise noted, failure does not affect the caller's transaction, if one exists.)
Cannot send to svc
because it does not exist, or it is a conversational service, or the name provided begins with a dot (.).
Either the type and subtype of the reply are not known to the caller; or, TPNOCHANGE
was set in flags
and the type and subtype of *odata
do not match the type and subtype of the reply sent by the service. Neither *odata
, its contents, nor *olen
is changed. If the service request was made on behalf of the caller's current transaction, then the transaction is marked abort-only since the reply is discarded.
This error code indicates that either a timeout has occurred or tpcall()
has been attempted, in spite of the fact that the current transaction is already marked rollback only.
If the caller is in transaction mode, then either the transaction is already rollback only or a transaction timeout has occurred. The transaction is marked abort-only. If the caller is not in transaction mode, a blocking timeout has occurred. (A blocking timeout cannot occur if TPNOBLOCK
and/or TPNOTIME
is specified.) In either case, no changes are made to *odata
, its contents, or *olen
.
If a transaction timeout has occurred, then, with one exception, any attempts to send new requests or receive outstanding replies will fail with TPETIME
until the transaction has been aborted. The exception is a request that does not block, expects no reply, and is not sent on behalf of the caller's transaction (that is, tpacall()
with TPNOTRAN
, TPNOBLOCK
, and TPNOREPLY
set).
When a service fails inside a transaction, the transaction is put into the TX_ROLLBACK_ONLY
state. This state is treated, for most purposes, as though it were equivalent to a timeout. All further ATMI calls for this transaction (with the exception of those issued in the circumstances described in the previous paragraph) will fail with TPETIME
.
The service routine sending the caller's reply called tpreturn()
with TPFAIL
. This is an application-level failure. The contents of the service's reply, if one was sent, is available in the buffer pointed to by *odata
. If the service request was made on behalf of the caller's current transaction, then the transaction is marked abort-only. Note that regardless of whether the transaction has timed out, the only valid communications before the transaction is aborted are calls to tpacall()
with TPNOREPLY
, TPNOTRAN
, and TPNOBLOCK
set.
A service routine encountered an error either in tpreturn(3c)
or tpforward(3c)
(for example, bad arguments were passed). No reply data is returned when this error occurs (that is, neither *odata
, its contents, nor *olen
is changed). If the service request was made on behalf of the caller's transaction (that is, TPNOTRAN
was not set), then the transaction is marked abort-only. Note that regardless of whether the transaction has timed out, the only valid communications before the transaction is aborted are calls to tpacall()
with TPNOREPLY
, TPNOTRAN
, and TPNOBLOCK
set. If either SVCTIMEOUT
in the UBBCONFIG
file or TA_SVCTIMEOUT
in the TM_MIB
is non-zero, TPESVCERR
is returned when a service timeout occurs.
tpacall(3c)
,tpalloc(3c)
, tperrordetail(3c)
, tpforward(3c)
, tpfree(3c)
, tpgprio(3c)
, tprealloc(3c)
, tpreturn(3c)
, tpsprio(3c)
, tpstrerrordetail(3c)
, tptypes(3c)
![]() ![]() |
![]() |
![]() |