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

\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 on at the
time of the error condition, and then resumes copying. Because it keeps track of where it was in
the COPYAUDIT operation, RDFCOM does not have to recopy the previously copied image files.
RDFCOM abends if it encounters network problems while searching the remote image trails for
missing audit records. If that happens, RDFCOM logs a message to the EMS event log, but not to
the home terminal.
RDFCOM Commands 187