All main RDF processes (monitor, extractor, rdfnet, receiver, purger, and updater) run as process
pairs. If the primary processor of one of these RDF processes fails, the backup process takes
over with no interruption in service. By convention, when the failed processor comes back up, the
RDF process creates its backup in this processor and then does a switch in order the return the
primary process to the primary processor in the RDF configuration.
One RDF process does not follow this convention. When a processor failure stops the primary
process, the backup process takes over, assumes the role of the primary process, and does not
give up its new role as the primary even though the failed processor has come back up and a
backup process has been created in this processor.
Which RDF process is this?

The RDF primary system has failed following multiple hardware failures.
The system has been restored, and TMF has been started. Volume recovery was unable to
recover several files and marked them with an flag.
What is the best way to proceed?

RDFCOM STATUS RDF reports errors for several of the updater processes. Which step should
be taken first?

STATUS RDF shows that both receiver and updater RTD times are increasing. Perusing the EMS
event log, you notice that the RDF extractor is generating event 705 (file Open Error 250 $RCVR
once every minute). What is the best action to take?

TMF on the RDF primary system is unable to perform audit dumps due to problems with the tape
silo. The operator has added three TMF OVERFLOWVOLS to house the excess audit trail files
until the silo can be repaired.
Which action is required for RDF?