TMF Operations and Recovery Guide (G06.24+)

Recovery Methods
HP NonStop TMF Operations and Recovery Guide522417-002
7-28
Restarting TMF in a Distributed Transaction
Environment
Unless the TMF crash was due to a STOP TMF, ABRUPT command, you should
evaluate the cause and eliminate it. Left uncorrected, the problem may recur,
lengthening the current outage or causing a future outage. Examine the EMS
messages generated by TMF: they should indicate that a TMF crash occurred, and list
the primary reason for it.
If the cause of the crash is not immediately obvious, collect the following information
that may be useful in determining the state of the system at the time of the incident, for
analysis by your service provider:
Processor dumps.
TMP saveabend files.
EMS and TSM event logs.
Copies of the TMF audit-trail files currently on disk.
TMF configuration information from the TMF configuration subvolume, whose
location is listed in the $SYSTEM.ZTMFCONF.CONFVOL file. (The default
configuration subvolume is $SYSTEM.ZTMFCONF.)
Additionally, collect the information listed in Gathering Information About Errors and
Failures on page 3-23.
After a TMF crash occurs, follow these steps to clear that condition:
1. Correct the problem that caused the crash. This may not be necessary after a
STOP TMF, ABRUPT command or TMP process failure, because TMF
automatically restarts the TMP processes in those cases.
2. Issue the START TMF command.
Restarting TMF in a Distributed Transaction Environment
TMF can service two kinds of distributed transactions:
Homogeneous distributed transactions, where portions of a transaction are
processed on two or more Expand nodes.
Heterogeneous distributed transactions, where portions of a transaction are
processed under the control of multiple transaction managers: TMF and one or
more foreign transaction managers.
Restarting TMF in a Homogeneous Distributed Transaction
Environment
When TMF is restarted in a homogeneous distributed transaction environment, it
attempts to resolve any pending distributed transactions. When possible, it
communicates with the TMF systems on parent and child nodes to determine the
outcome of such transactions. TMF does not finish starting, and new transactions are
not allowed to begin, until the outcome of all in-doubt transactions is determined.