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

NOTE: Even when no TMF transactions are in progress, TMF periodically writes control
points to the MAT, which means that the MAT continues to fill even when no application
activity is occurring. This can cause RTD times in the status display to fluctuate.
For an alternate method of bringing the backup database to a consistent state, see Access to
Backup Databases in a Consistent State” (page 140).
When you issue a STOP RDF command from the primary system, the following events occur:
1. RDFCOM sends a STOP message to the monitor.
2. The monitor sends stop messages to the extractor(s), the receiver(s), the purger, the updater(s),
and, if there is an RDF network, the RDFNET process.
3. The monitor stops after all RDF processes have stopped.
If the communications lines between the two systems are down when you issue the STOP RDF
command, the monitor tells the extractor to stop and writes an error message for every process
running on the backup system that the monitor could not access; the monitor then stops itself.
If this situation occurs, you must use RDFCOM on the backup system to stop the remaining RDF
processes before you can restart RDF.
STOP RDF, DRAIN Operations
A STOP RDF, DRAIN command causes the following actions to occur:
All TMF audit records up to the time the command is entered, are replicated to the image
trails on the backup node.
Each updater shuts down after it has applied all audit records up to the stop point.
The purger process reports event 852, indicating all updaters have stopped and the drain
has completed.
Stopping RDF From the Backup System
If you issue a STOP RDF command on the primary system when the communications lines are
down, then you must also do so on the backup system. That is the only time you should ever
issue a STOP RDF command on the backup system.
RDF can recover from a communications line failure, as explained in “Responding to Operational
Failures” (page 124).
When you issue a STOP RDF command on the backup system, RDFCOM attempts to contact
the RDF monitor on the primary system. After discovering that the monitor is not accessible,
RDFCOM sends individual stop messages to all RDF processes on the backup system.
If RDFCOM can contact the monitor on the primary system, the STOP RDF command is aborted.
To stop the RDF processes on the backup system, RDFCOM must be able to locate the RDF
control subvolume (whose name is the same as that of the control subvolume on the primary
system). You must explicitly specify the control subvolume name when you start the RDFCOM
session. For example, if the associated primary system is named \DALLAS and you did not
specify a suffix in the INITIALIZE RDF command, start the RDFCOM session on the backup
system:
>RDFCOM DALLAS; STOP RDF
If the associated primary system is named \DALLAS and you specified the suffix “3” in the
INITIALIZE RDF command, start the RDFCOM session on the backup system:
>RDFCOM DALLAS3; STOP RDF
An alternative way to stop RDF on the backup system is to enter the following command through
TACL:
132 Managing RDF