RDF System Management Manual for H-Series and J-Series RVUs (RDF 1.9)

When you shut down RDF by issuing a TMFCOM STOP TMF command, you can use successive
STATUS RDF commands to determine when all of the RDF processes have stopped.
Stopping RDF From the Primary System
When you issue the STOP RDF command on the primary system, all RDF processes stop
immediately without processing to the end-of-file mark in the MAT (except the updaters, which
might continue for a short while to finish up their work in progress).
While RDF is running, the database on the backup system is always in an inconsistent state
because updaters apply audit asynchronously with regard to one another. When you stop RDF
by issuing an STOP RDF command, the updaters stop immediately and they leave the backup
database in an inconsistent state. This is also true whenever you issue the STOP UPDATE
command.
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 150).
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 125).
134 Critical Operations, Special Situations, and Error Conditions