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

To stop the RDF and put the primary and backup databases into logically identical states (the data
is the same although the physical structure of the files may differ between primary and backup),
you must execute the following steps:
• Issue a TMFCOM DISABLE BEGINTRANS command on the primary system. This command
prevents the applications from initiating any new transactions until you issue a TMFCOM
ENABLE BEGINTRANS command.
CAUTION: If the starting of new transactions is disabled, applications could abort unless
they have been coded to handle that situation.
• Issue TMFCOM STATUS TRANSACTIONS commands and wait until the display shows no
transactions in progress.
• Issue STATUS RDF commands and wait until all of the RDF Time Delay (RTD) times are zero.
• Issue the STOP RDF command.
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
occurs. 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 with Stable Access” (page 141).
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.
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 117).
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:
126 Critical Operations, Special Situations, and Error Conditions