RDF System Management Manual for H-Series and J-Series RVUs (RDF 1.9)

(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 records is missing at \C.
Because \C has the least amount of audit records, 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 records 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 records 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 records 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.
COPYAUDIT Restartability
The COPYAUDIT command is restartable.
If an error condition aborts execution of a COPYAUDIT command, you merely correct the
condition and then reissue the command. Upon restart, RDFCOM quickly checks the local system
image files it had previously created to be sure they are still correct, deletes the file it was working
198 Entering RDFCOM Commands