Skip navigation.

ATMI COBOL Function Reference

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader




TPSCMT() - set when TPCOMMIT should return






TPSCMT() sets the TP-COMMIT-CONTROL characteristic to the value specified in TPCMTDEF-REC. The TP-COMMIT-CONTROL characteristic affects the way TPCOMMIT() behaves with respect to returning control to its caller. A program can call TPSCMT() regardless of whether it is in transaction mode or not. Note that if the caller is participating in a transaction that another program must commit, then its call to TPSCMT() does not affect that transaction. Rather, it affects subsequent transactions that the caller will commit.

In most cases, a transaction is committed only when a BEA Tuxedo ATMI program calls TPCOMMIT(). There is one exception: when a service is dispatched in transaction mode because the AUTOTRAN variable in the SERVICES section of the UBBCONFIG file is enabled, then the transaction completes upon calling TPRETURN(). If TPFORWAR() is called, then the transaction will be completed by the server ultimately calling TPRETURN(). Thus, the setting of the TP-COMMIT-CONTROL characteristic in the service that calls TPRETURN() determines when TPCOMMIT() returns control within a server. If TPCOMMIT() returns a heuristic error code, the server will write a message to a log file.

When a client joins a BEA Tuxedo ATMI application, the initial setting for this characteristic comes from a configuration file. (See the CMTRET variable in the RESOURCES section of UBBCONFIG(5).)

The following are the valid settings for TPCMTDEF-REC.


This setting indicates that TPCOMMIT() should return after the commit decision has been logged by the first phase of the two-phase commit protocol but before the second phase has completed. This setting allows for faster response to the caller of TPCOMMIT() although there is a risk that a transaction participant might decide to heuristically complete (that is, aborted) its work due to timing delays waiting for the second phase to complete. If this occurs, there is no way to indicate this situation to the caller since TPCOMMIT() has already returned (although BEA Tuxedo writes a message to a log file when a resource manager takes a heuristic decision). Under normal conditions, participants that promise to commit during the first phase will do so during the second phase. Typically, problems caused by network or site failures are the sources for heuristic decisions being made during the second phase.


This setting indicates that TPCOMMIT() should return after the two-phase commit protocol has finished completely. This setting allows for TPCOMMIT() to return an indication that a heuristic decision occurred during the second phase of commit.

Return Values

Upon successful completion, TPSCMT() sets TP-STATUS to [TPOK] and returns the previous value of the TP-COMMIT-CONTROL characteristic.


Under the following conditions, TPSCMT() fails and sets TP-STATUS to:




TPSCMT() was called improperly.


A BEA Tuxedo system error has occurred. The exact nature of the error is written to a log file.


An operating system error has occurred.


When using TPBEGIN(), TPCOMMIT(), and TPABORT() to delineate a BEA Tuxedo ATMI transaction, it is important to remember that only the work done by a resource manager that meets the XA interface (and is linked to the caller appropriately) has transactional properties. All other operations performed in a transaction are not affected by either TPCOMMIT() or TPABORT(). See buildserver(1) for details on linking resource managers that meet the XA interface into a server such that operations performed by that resource manager are part of a BEA Tuxedo ATMI transaction.

See Also

TPABORT(3cbl), TPBEGIN(3cbl), TPCOMMIT(3cbl), TPGETLEV(3cbl)


Skip navigation bar  Back to Top Previous Next