HP Integrity NonStop J-Series - Manual (Page 76)

Usage Guidelines
HP NonStop AutoTMF Software User’s Guide—429952-016
5-8
How AutoTMF works with Process Pairs
In the less typical case where a process pair directly accesses the database, and
AutoTMF is used to manage audited access to the data, consider the following
analysis of failure scenarios.
In a primary process, AutoTMF operates in the normal way, creating and committing
automatic transactions as required to perform audited database updates. When a
primary process fails, some automatic transactions may be active. These transactions
might not be committed, depending on the cause of the failure.

If the failure is due to a programming error, such as a trap or a call to STOP or
ABEND, AutoTMF commits all outstanding transactions before the program stops
and the backup process takes over. No transaction is lost.

If the failure is due to an environmental error, such as the loss of a CPU, then the
active transactions are unilaterally aborted. After the primary process failure, the
backup process takes over at some point in the processing, without knowing if all
the previous updates have been committed.
How AutoTMF works with Process Pairs
AutoTMF intercepts the CHECKMONITOR procedure, and initializes the AutoTMF
internal extended segment in the backup process upon startup. This enables the
backup process to properly take over if the primary fails.
However, consider the following:

No reliable way exists to checkpoint TMF transactions.

As mentioned above, a CPU failure causes non committed database updates to be
rolled back.
When the backup process takes over, AutoTMF starts generating new automatic
transactions without knowledge of the transactions that occurred in the failed primary
process. The backup process behaves as if the work had been completed and does
not reapply an update that was rolled back.
In theory, this situation could be remedied by making AutoTMF commit all active
transactions whenever the primary process does a CHECKPOINT to the backup
process. However, to commit transactions at every checkpoint requires that no record
locks or file locks be held by the program when it calls CHECKPOINT, which is not a
condition that AutoTMF can depend on.
Recommendation
To limit the scope of the recovery required in the backup process, it might help to set
MAXUPDATES 1, but only if a program does not have locked records when
checkpoints are performed. If no locks are held, the transaction is committed and, if a
failure occurs, at most one update must be recovered by the backup process.