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

Stopping RDF leaves the backup database in an inconsistent state and also leaves the audit trail
file last opened by the extractor pinned.
CAUTION: If the primary system crashes, RDF processes on the backup system remain running.
If you do not execute a takeover and are able to bring the primary system back up, you must stop
the RDF processes on the backup system before you restart RDF on the primary system. While the
primary is down issue STOP RDF on backup. Otherwise, issue the following TACL command on
the backup system: STATUS *, PROG, $SYSTEM.RDF.*, STOP (assuming the RDF SOFTWARELOC
is $SYSTEM.RDF).
For each shutdown procedure, the RDF receiver and updater processes write their current context
information to the RDF context file before stopping. If you restart but do not reinitialize RDF, the
product retrieves the context information from the context file. The context information enables the
RDF processes to resume processing where they stopped before the shutdown, unless an audit trail
file that RDF needs has been purged and cannot be restored to disk.
Stopping RDF by Stopping TMF
The reason for stopping RDF by stopping TMF is to ensure that the primary and backup databases
are logically identical when the shutdown is complete (RDF has applied all changes to the backup
database). That will be the case, of course, only if all the updater processes stopped at the shutdown
record (if an updater experiences a double CPU failure, the databases will not be identical). The
disadvantage of this approach is that all applications on the primary system that use TMF must be
stopped also.
Stopping TMF also automatically unpins all audit trail files that were pinned on behalf of RDF.
When you issue a TMFCOM STOP TMF command, the following events occur:
1. TMF writes a shutdown record to the MAT. When the master extractor reads the shutdown
record, it notifies the monitor that TMF has stopped.
NOTE: If the extractor process falls way behind TMF because the communications lines to
the backup system have been down and come up again, it can take some time for the extractor
to get to the TMF shutdown record. The extractor stops processing the audit trail files when it
cannot communicate with the receiver and resumes processing when the communications lines
are restored.
2. The master extractor stops as soon as the master receiver replies that it has processed the TMF
shutdown record.
3. The RDFNET process (if there is an RDF network) does not wait for any other process to stop;
it merely stops when informed to do so.
4. If updating is enabled, each updater process stops when it reaches the TMF shutdown record
in its image trail.
5. The purger stops after all the updaters have stopped.
6. The receiver(s) stop when the purger has stopped.
7. The monitor stops after all the other RDF processes have stopped.
If you stop TMF and then restart it before RDF can read the shutdown record, RDF stops when it
encounters the shutdown record. If that happens, you need to issue a START RDF command to
restart RDF.
NOTE: TMF does not start RDF, which means that if you start TMF, you must then explicitly start
RDF.
If the communications lines are down when you stop TMF, the extractor continues to run, but it will
not recognize that TMF is shut down because the extractor does not read the data in the MAT until
122 Critical Operations, Special Situations, and Error Conditions