tpgetrply(3c)


	BEA Home \| Events \| Solutions \| Partners \| Products \| Services \| Download \| Developer Center \| WebSUPPORT
	http://www.oracle.com/technology/documentation/index.html \| Site Map \| Search \| PDF Files \| Contact \| Glossary

Tuxedo Documentation \| C Function Reference \| Local Topics \| Previous Topic \| Next Topic \| Contents

tpgetrply(3c)

Name

tpgetrply()—Routine for getting a reply from a previous request.

Synopsis

#include <atmi.h>
int tpgetrply(int *cd, char **data, long *len, long flags)

Description

tpgetrply() returns a reply from a previously sent request. This function's first argument, cd, points to a call descriptor returned by tpacall(). By default, the function waits until the reply matching *cd arrives or a timeout occurs.

data must be the address of a pointer to a buffer previously allocated by tpalloc() and len should point to a long that tpgetrply() sets to the amount of data successfully received. Upon successful return, *data points to a buffer containing the reply and *len contains the size of the data. 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. 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 the "Introduction to the C Language Application-to-Transaction Monitor Interface" for more information about buffer management.

If *len is 0, then the reply has no data portion and neither *data nor the buffer it points to were modified.

It is an error for *data or len to be NULL.

Within any particular context of a multithreaded program:

Calls to tpgetrply(TPGETANY) and tpgetrply() for a specific handle cannot be issued concurrently.
Multiple calls to tpgetrply(TPGETANY) cannot be issued concurrently.

Any tpgetrply() call that would, if issued, cause a violation of either of these restrictions, returns -1 and sets tperrno to TPEPROTO.

It is acceptable to issue:

Concurrent calls to tpgetrply() for different handles.
A call to tpgetrply(TPGETANY) in a single context concurrently with a call to tpgetrply(), with or without TPGETANY, in a different context.

The following is a list of valid flags:

TPGETANY

This flag signifies that tpgetrply() should ignore the descriptor pointed to by cd, return any reply available and set cd to point to the call descriptor for the reply returned. If no replies exist, tpgetrply() by default will wait for one to arrive.

TPNOCHANGE

By default, if a buffer is received that differs in type from the buffer pointed to by *data, then *data'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 *data 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 *data.

TPNOBLOCK

tpgetrply() does not wait for the reply to arrive. If the reply is available, then tpgetrply() gets the reply and returns. When this flag is not specified and a reply is not available, the caller blocks until the reply arrives or a timeout occurs (either transaction or blocking timeout).

TPNOTIME

This flag signifies that the caller is willing to block indefinitely for its reply and wants to be immune to blocking timeouts. Transaction timeouts may still occur.

TPSIGRSTRT

If a signal interrupts any underlying system calls, then the interrupted system call is reissued.

Except as noted below, *cd is no longer valid after its reply is received.

In a multithreaded application, a thread in the TPINVALIDCONTEXT state is not allowed to issue a call to tpgetrply().

Return Values

Upon successful return from tpgetrply() or upon return where tperrno() is set to TPESVCFAIL, tpurcode() contains an application defined value that was sent as part of tpreturn().

Upon failure, tpgetrply() returns -1 and sets tperrno() to indicate the error condition.

Errors

Upon failure, tpgetrply() sets tperrno() as indicated below. Note that if TPGETANY is not set, then *cd is invalidated unless otherwise stated. If TPGETANY is set, then cd points to the descriptor for the reply on which the failure occurred; if an error occurred before a reply could be retrieved, then cd points to 0. Also, the failure does not affect the caller's transaction, if one exists, unless otherwise stated. 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.