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

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.
If RDFCOM encounters network problems during any other phase of COPYAUDIT execution, it
does not abend. Instead, it logs a message to the home terminal and aborts the COPYAUDIT
command.
Using ZLT to Achieve Triple Contingency Protection for Auxiliary Audit
Trails
The COPYAUDIT command does not support auxiliary audit trails.
With the RDF/ZLT product, however, you can achieve the same protection without using a
COPYAUDIT command, and thereby protect RDF environments that include auxiliary audit trails.
Triple Contingency Without ZLT
The triple contingency feature builds upon the ability to replicate to multiple backup systems. With
this feature, you establish two essentially identical RDF configurations:
RDF Subsystem #1
\A ---------> \B
RDF Subsystem #2
\A ---------> \C
Because the two subsystems run independently of one another, if system \A fails and you execute
TAKEOVER commands on systems \B and \C, the two backup databases might not be synchronized
with one another. The extractor for the \A-to-\B subsystem, for example, might have replicated
audit data to system \B, but, before the extractor for the \A-to-\C subsystem could replicate the
same data to system \C, system \A failed. To correct this situation, you issue a COPYAUDIT
command to transfer the extra audit data from system \B to system \C. You then reissue the
TAKEOVER command on system \C, and the two backup databases are logically identical. At this
point you can then continue application processing from system \B to system \C or from system
\C to system \B within minutes of losing system \A.
Using ZLT to Achieve the same Protection
While the COPYAUDIT command does not work for RDF configurations that include auxiliary audit,
you can achieve Triple Contingency with auxiliary audit by using the ZRDF/ZLT product because
the ZLT functionality supports auxiliary audit. To achieve the same result using the RDF/ZLT product
you configure system \B as the ZLT standby node for both RDF subsystems #1 and #2. Upon losing
system \A, you connect the remote mirrors to system \B and issue TAKEOVER commands on both
systems \B and \C. Since, as part of the ZLT takeover, each subsystem fetches the final audit data
from the remote mirrors connected to system \B, both backup databases receive the same data.
268 Triple Contingency