RDF System Management Manual for H-Series RVUs (RDF 1.8)

If the communications lines between the two systems are down and you want to stop RDF, you
must issue the STOP RDF command on both the primary and backup systems.
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.
130 Managing RDF