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

4. After one minute, STOP RDF again
5. Restart RDF with UPDATE OFF; this causes the receiver to rollover to a new image file on each
image trail.
6. On the image trail for the updater generating the 813 events, move the next file in sequence
(the one after the file identified in step 1) to a different subvolume. For example, if the updater
is reading file AA000100, then move AA000101.
7. START UPDATE. The updater starts reporting 892 events after it completes reading the current
Image trail file AA000100.
8. Move the file AA000101 back to the image trail subvolume.
Completing Step 6 - Step 8 ensures that the updater does not read any further than the file it is
currently processing. On completing Step 8, the updater can continue with the next image file,
allowing the purger to purge the previous file.
Remember that all of this can be avoided by keeping your audit files balanced so that you do not
have more than 3,000 on any single RDF-protected volume.
Responding to Operational Failures
RDF can recover from any of the following events, as described in detail in the following pages:
• Communications line failure on the primary or backup system
• System failure that does not require an RDF Takeover operation
• Processor failure on the primary or backup system
• Failure of a TMF audited volume on the primary system
• TMF subsystem failure after which the TMF volume recovery is successful
• TMF file recovery operation on the primary system that is not to a timestamp, first purge, or
TOMATPOSITION position.
• TMF ABORT TRANSACTION with the AVOIDHANGING option on the primary system
RDF cannot recover from the following events:
• TMF file recovery operation to a timestamp, first purge, or TOMATPOSITION on the primary
system.
• TMF subsystem failure after which TMF cannot perform a successful volume recovery operation
After a TMF file recovery to a timestamp, first purge, or TOMATPOSITION, or after a TMF subsystem
failure for which volume recovery cannot succeed, the databases or the affected files on the primary
and backup systems must be resynchronized.
Communication Line Failures
RDF can recover from communication line failures. When the extractor detects that a communication
line to the backup system is down, it reports the error to the EMS event log. The extractor attempts
to resend data every minute until the line to the backup system is reenabled.
Unless you are running the ZRDF/ZLT product, the failure of the communications line will lead to
the loss of committed transactions if you also lose your primary system and you must perform an
RDF Takeover operation before the extractor was able to catch up. This risk is eliminated with the
RDF/ZLT product and a proper configuration for CommitHold. For further details see, “Zero Lost
Transactions (ZLT)” (page 329).
If you stop RDF on the primary system when the communication line to the backup system is down,
the monitor tries to send a stop message to the processes on the backup system and reports that
the line is down. All of the processes on the backup system continue to run until a STOP RDF
command is issued at the backup system.
Responding to Operational Failures 115