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

There is a special circumstance that has caused trouble for some customers. Assume you are running
RDF to protect your primary database. Now assume that someone configures a small RDF test
subsystem, starts that test subsystem, stops it, and then deletes the RDF control subvolume on the
primary and backup systems to eliminate all vestiges of that test subsystem. In doing this, the person
performing the test has omitted one critical task - issuing the UNPINAUDIT command for that
subsystem before deleting the control subvolume. Why is this a problem? Remember that when
this RDF test subsystem was started, its extractor pinned the current audit trail file, and this file
remains pinned even after that RDF subsystem was stopped. To complicate this problem further,
the control subvolume was deleted. To recover from this problem, recall that TMF generates an
event when it cannot unpin a file because of RDF and recall that the control subvolume for the RDF
subsystem that has the file pinned is named in the event. In this example, however, the control
subvolume does not even exist because it was deleted at the end of the test. If you find yourself in
this situation, then you must configure an RDF subsystem with the name of the control subvolume
listed in the TMF event. Once you have configured it, you can then issue the RDFCOM OPEN
command, specifying this control subvolume and then issue the UNPINAUDIT command.
CAUTION: To avoid problems like that described immediately above, always be sure that you
issue the UNPINAUDIT command before you delete an RDF control subvolume.
Stopping RDF
If the communications lines between the primary and backup systems are up, there are two ways
to stop RDF:
1. Issue a STOP RDF command on the primary system.
2. Issue a TMFCOM STOP TMF command on the primary system. After the RDF updaters have
reached the TMF shutdown record, RDF stops and then TMF stops.
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:
124 Critical Operations, Special Situations, and Error Conditions