RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

2. Recover the database on your former primary system. How you do this depends upon whether
local disks or remote mirrors received the most audit records (which you determined in the
preceding step).
CommitHoldMode ON
If all of the remote mirrors (MAT and all auxiliary audit trails) have more or the same number
of audit records as the local disks (this typically happens if CommitHoldMode was configured
and enabled on the primary system when the outage occurred):
a. Issue SCF STOP $audit-vol on the former primary system (this stops the local disk).
b. Issue SCF STOP $audit-vol on the ZLT standby system (this stops the remote mirror on
the ZLT standby system).
c. Issue SCF START $audit-vol -M (this starts only the remote mirror).
d. Once the remote mirror is started, issue SCF START $audit-vol (which causes the revive
from -M to -P)
e. Start TMF. When startup is complete, the database on the primary system contains the
same data that the database on the backup system had at the conclusion of the RDF
takeover operation.
CommitHoldMode OFF or Disabled
If any local disk (the MAT or any auxiliary audit trail) has more audit records than the
corresponding remote mirror (this can only happen if CommitHold was not configured or was
configured but disabled on the primary system when the outage occurred):
1. Issue SCF STOP $audit-vol on the ZLT standby system (this stops the remote mirror on
the ZLT standby system).
2. Connect the remote mirror to the former primary system.
3. Issue SCF START $audit-vol (this causes a revive from -P to -M).
4. Start TMF.
5. Initiate TMF file recovery with the MAT position option, where the position you specify is
the MAT position reported in the RDF 888 event on the backup system. The RDF event
888 is logged when the takeover operation completes.
3. For information about how to return your application processing to the former primary system,
see “Carrying Out a Planned Switchover” (page 127).
ZLT and RDF Networks
If you have an RDF network and also want ZLT protection on any of the nodes in that network,
then every node that participates in a user transaction must be configured for ZLT protection.
For example, assume that systems \A and \B are both configured as nodes within an RDF network,
and that system \B is also configured for ZLT protection.
If system \A starts a transaction and any updates associated with that transaction are done on
system \B, then system \A also must be configured for ZLT protection.
STOP TMF Operations
Within an RDF environment that is configured for ZLT processing, STOP TMF operations are handled
as follows:
During Normal Operations
If updating is off, the TMF shutdown audit-record is not stored in image trails, and the monitor,
extractor(s), receiver(s), and purger RDF processes stop.
If updating is on, the shutdown audit-record is stored in image trails, and all RDF processes stop.
328 Zero Lost Transactions (ZLT)