General Communication Call Errors


	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 \| Programming BEA Tuxedo ATMI Applications Using COBOL \| Local Topics \| Previous Topic \| Next Topic \| Contents

General communication call errors can occur during any communication calls, regardless of whether those calls are synchronous or asynchronous. Any of the following errors may be returned in TP-STATUS: TPESVCFAIL, TPESVCERR, TPEBLOCK, or TPGOTSIG.

TPESVCFAIL and TPESVCERR Errors

If the reply portion of a communication fails as a result of a call to TPCALL or TPGETRPLY, the system returns TPESVCERR or TPSEVCFAIL to TP-STATUS. The system determines the error by the arguments that are passed to TPRETURN and the processing that is performed by this call.

If TPRETURN encounters an error in processing or handling arguments, the system returns an error to the original requester and sets TP-STATUS to TPESVCERR. The receiver determines that an error has occurred by checking the value of TP-STATUS. The system does not send the data from the TPRETURN call, and if the failure occurred on TPGETRPLY, it renders the call handle invalid.

If TPRETURN does not encounter the TPESVCERR error, then the value returned in TP-RETURN-VAL determines the success or failure of the call. If the application specifies TPFAIL in the TP-RETURN-VAL, the system returns TPESVCFAIL in TP-STATUS and sends the data message to the caller. If TP-RETURN-VAL is set to TPSUCCESS, the system returns successfully to the caller, TP-STATUS is not set, and the caller receives the data.

TPEBLOCK and TPGOTSIG Errors

The TPEBLOCK and TPGOTSIG error codes may be returned at the request or the reply end of a message and, as a result, can be returned for all communication calls.

The system returns TPEBLOCK when a blocking condition exists and the process sending a request (synchronously or asynchronously) indicates, by setting TPPNOBLOCK that it does not want to wait on a blocking condition. A blocking condition can exist when a request is being sent if, for example, all the system queues are full.

When TPCALL indicates a no blocking condition, only the sending part of the communication is affected. If a call successfully sends a request, the system does not return TPEBLOCK, regardless of any blocking situation that may exist while the call waits for the reply.

The system returns TPEBLOCK for TPGETRPLY when a call is made TPNOBLOCK and a blocking condition is encountered while TPGETRPLY is awaiting the reply. This may occur, for example, if a message is not currently available.

The TPGOTSIG error indicates an interruption of a system call by a signal; this situation is not actually an error condition. If TPSIGRSTRT is set, the calls do not fail and the system does not return the TPGOTSIG error code in TP-STATUS.