ATMI COBOL Function Reference
TPSCMT()
- set when TPCOMMIT
should return
01
TPCMTDEF-REC
.
COPY TPCMTDEF.
01TPSTATUS-REC
.
COPY TPSTATUS.
CALL "TPSCMT" USINGTPCMTDEF-REC
TPSTATUS-REC
.
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.
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:
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.
TPABORT(3cbl)
, TPBEGIN(3cbl)
, TPCOMMIT(3cbl)
, TPGETLEV(3cbl)