TMF Operations and Recovery Guide (G06.24+)
Recovery Methods
HP NonStop TMF Operations and Recovery Guide—522417-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.  










