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

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.
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 115).
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:
>STATUS *, PROG RDF-software-loc.*, STOP
CAUTION: Issuing this command in this situation is only safe, however, if this is the backup system
for a single RDF environment.
Stopping RDF Using STOP RDF, DRAIN
As stated, stopping TMF shuts down RDF and it guarantees that the backup database is then
logically identical to the primary database. If, however, you have several different applications
running on your primary system, each working on its own database, and if not all are protected
by the one RDF subsystem, then you may not want to stop TMF just to shutdown the RDF subsystem.
In this situation, you can use the STOP RDF, DRAIN command, but you must observe the following
sequence of steps.
1. Stop the application that is updating your RDF-protected database.
2. Enter the STOP RDF, DRAIN command.
In response to the DRAIN command, the extractor marks its location in the audit trail when it receives
notice of the operation, and the updaters do not shut down until they have processed all audit up
to that location. Finally, the purger process generates RDF event 852 to notify you that the operation
has completed. Since your application has previously stopped, your backup database is now
logically identical to your primary database that is protected by this RDF subsystem, and you have
124 Critical Operations, Special Situations, and Error Conditions