TMF Application Programmer's Guide (G06.26+)

TMF Programming Environment

HP NonStop TMF Application Programmer’s Guide—522419-005

1-10

Setting the Current Transaction to Nil

A requester or server process sets its current transaction to the nil state by issuing a

RESUMETRANSACTION call with a tag value of zero. In TAL, the call is as follows:

status := RESUMETRANSACTION (0D);

After setting the current transaction to the nil state, however, you must then explicitly

reset it back to the transaction identifier of a currently active transaction. To do that,

you need to know the proper tag value for each transaction.

Within a requester, the tag for each transaction is returned by way of the

trans-begin-tag variable in the BEGINTRANSACTION TMF procedure call.

Requesters set their current transaction to a particular transaction by supplying the

appropriate tag value in a RESUMETRANSACTION TMF procedure call. In TAL, the

call is as follows:

status := RESUMETRANSACTION (tag);

Within a server, you obtain the tag for each transaction by issuing a LASTRECEIVE

TMF procedure call immediately after each READUPDATE of $RECEIVE. Servers set

their current transaction to a particular transaction by supplying the appropriate tag

value in an ACTIVATERECEIVETRANSID TMF procedure call. In TAL, the call is as

follows:

CALL ACTIVATERECEIVETRANSID (tag);

Marking an OPEN to Not Share a Transaction Identifier

A requester process can also exclude server processes from sharing its transaction

identifier by issuing a SETMODE 117 call with param1 = 1 after opening the servers.

This parameter setting is the default for process subtypes 30 and 31 (device simulators

and spoolers, respectively).

For any processes opened by the requester after such a SETMODE call, a transaction

identifier is never associated with messages sent from the requester to those

processes, even if one is in effect for the requester at the time the message is sent.

Thus, if a server terminates abnormally while working on behalf of a transaction, the

transaction itself will not be aborted because its transaction identifier was never

included in the requester’s messages.

Once this SETMODE call is issued, it remains in effect until it is explicitly reset by

issuing a SETMODE 117 call with param1 = 0.

The SETMODE 117 action is local to the process in which it is executed; no notification

is passed to any other process.

If this SETMODE is invoked within one process of a process pair, provision must be

made within the backup process to either call CHECKSETMODE or to reexecute the

SETMODE 117 call at the time of a takeover.