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

updaters; if UPDATEREXCEPTION is ON, then each update of the batch needs to be undone
and an exception record written.
• Auxiliary Audit and a Comm Problem
If your RDF environment includes extractor-receiver pairs associated with auxiliary audit trails,
then if one extractor-receiver pair has fallen way behind because of a communications
problems, then all affected transactions must be undone by all affected updaters, and this can
lead to a lot of audit being undone with exception records.
• RDF Network
If you have an RDF Network and one primary system suffers an unplanned outage, then the
amount of undo required by all backup systems is proportional to how long it takes you to
stop all transaction processing on the surviving primary systems. If this is not done quickly,
then all these transactions might need to be undone in order to guarantee business consistency
after the RDF takeover operation completes, which could also generate a large volume of
exceptions records.
When all the updater processes shut down, the purger checks to see if each completed its takeover
processing. If yes, the purger logs RDF event 724. If some updaters stopped prematurely (for
example, double CPU failure), it logs RDF event 725. In the latter case, you only need to be sure
all CPUs are available and then reissue the TAKEOVER command.
It is conceivable that one or more transactions could get committed on the primary database
immediately prior to the TAKEOVER operation but that their commit records did not reach the
backup system before the primary system failure. If that happens, the audit data for the affected
transactions is not committed on the backup system and is instead written to the exception file if
you have RDF UPDATEREXCEPTION ON.
Updater Exception files can be read by the RDFSNOOP utility. For information about using
RDFSNOOP, see Appendix B (page 340).
If your primary system is recovered and comes back online, See Chapter 5 (page 113) for how to
recover it and use its database as a backup to the database on your backup system where your
application processing is not taking place.
For further related considerations, see also Exception File Optimization in Chapter 5 (page 113).
Limitation
When building the undo list for an RDF takeover operation, the purger has a limit of 655,360
transactions. If this limit is exceeded, the purger process logs an RDF event 853 and abends. In
this situation, contact your service provider. With some special settings, there is no limit to the
number of transactions that can be undone during a takeover operation.
Example
This command sequence initiates RDF TAKEOVER processing in which the backup system
\TORONTO takes over processing from the primary system \SANFRAN.
1. From the TACL command interpreter on the backup system (\TORONTO), enter:
>RDFCOM SANFRAN
2. From within the RDFCOM session, enter:
]TAKEOVER
3. RDF displays this prompt message:
*** TAKEOVER assumes a disaster on \SANFRAN has occurred.
Are you sure you want to TAKEOVER?
To proceed with the TAKEOVER operation, enter Y or YES.
To stop the TAKEOVER operation, enter N or NO.
RDFCOM Commands 245