![]() |
![]() |
e-docs > Tuxedo > ATMI C Function Reference > Section 3c - C Functions |
ATMI C Function Reference
|
Name
tpcall()—Routine for sending service request and awaiting its reply.
Synopsis
int tpcall(char *svc, char *idata, long ilen, char **odata, long \
*olen, long flags)
Description
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:
In a multithreaded application, a thread in the TPINVALIDCONTEXT state is not allowed to issue a call to tpcall().
Return Values
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.
Errors
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.)
See Also
tpacall(3c),tpalloc(3c), tperrordetail(3c), tpforward(3c), tpfree(3c), tpgprio(3c), tprealloc(3c), tpreturn(3c), tpsprio(3c), tpstrerrordetail(3c), tptypes(3c)
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |