RDF System Management Manual for H-Series RVUs (RDF 1.8)

command on the system that is behind, specifying the name of the other backup system and its
RDF control subvolume.
For the following discussion, assume that you have established these two RDF configurations:
RDF Configuration #1:
\A ------------------> \B
(The RDF control subvolume is A1 on both systems.)
RDF Configuration #2:
\A ------------------> \C
(The RDF control subvolume is A2 on both systems.)
Assume you have lost the original primary system (\A), you have successfully completed a
takeover on both backup systems (\B and \C), and the MAT positions displayed by the respective
735 messages are:
\B: 735 LAST MAT POSITION: Sno 10, Rba 100500000
\C: 735 LAST MAT POSITION: Sno 10, Rba 100000000
500 kilobytes of audit information is missing at \C.
Because \C has the least amount of audit information, you must issue the following command
on \C:
COPYAUDIT , REMOTESYS \B, REMOTECONTROLSUBVOL A1
For each image trail, RDFCOM on \C reads its own context file to determine the MAT position
of the last audit record in the trail. RDFCOM then searches the corresponding trail on \B to find
that audit record and performs large block transfers to move all audit records beyond that point
to the trail on \C. As it does this, RDFCOM issues messages to let you know which image trail
it is currently processing.
NOTE: When it begins copying missing audit records from one system to the other, RDFCOM
never alters any of the existing image trail files on the local system. Instead, it creates a brand
new image file on the local system even if the starting point of the missing audit information on
the other system is within a file with a different sequence number. This means that, upon
completion of the COPYAUDIT operation, the local system will almost always have more image
trail files (one or two per image trail) than the other system. This is expected behavior.
Because a takeover has already completed previously on \C, RDFCOM must now update the
context records of the affected updaters and the receiver on \C (again, RDFCOM issues a message
to let you know it is doing this). RDFCOM must update the context records because it just added
new audit information to the image trails, and the updaters must have a chance to apply that
information upon successful completion of a subsequent (required) takeover.
Each updater has an exception file containing information about all of the audit records it could
not apply because the abort/commit status of the associated transaction was unknown at the
time of the original takeover. Because RDFCOM added more audit information to the image
trail, there is a chance that the outcome of some of these transactions is now known. Therefore,
RDFCOM repositions the updater’s restart location back to the first record that it could not
previously apply. (If there were no exception records, then RDFCOM leaves the updater’s restart
location unchanged.)
Finally, RDFCOM turns off the receiver’s takeover completed flag and issues a message telling
you that the COPYAUDIT operation has completed successfully and you must initiate another
takeover on \C. Issue a TAKEOVER command on \C. If the takeover completes successfully
(the receiver logs an RDF message 724 followed by a 735 message containing the same detail as
in the 735 message associated with the takeover on \B), the two databases are logically identical.
At that point you can initialize, configure, and start RDF on both systems, and then resume
application processing on the new primary system with full RDF protection.
184 Entering RDFCOM Commands