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

$volume-name.subvolume-name.ZRDFNETX
where volume-name is the configured PNETTXVOLUME network attribute and
subvolume-nameis the configured REMOTECONTROLSUBVOLUME network attribute.
RDF Network Control Files
These control files exist in the Master Image Trail (MIT) subvolume of all RDF subsystems that
are configured for replication of network transactions: ZRDFLCMT, ZRDFLCM2, and
ZNETUNDO. Additionally, the network master has three more files: ZRDFNMTX, ZRDFNMT2,
ZRDFNMT3. These files contain internal information that RDF needs to correctly execute takeover
operations involving an RDF network. The files are empty until you actually initiate a takeover
operation on a backup system within an RDF network.
Normal RDF Processing Within a Network Environment
Each RDF subsystem within an RDF network conducts its processing individually, as though it
were not involved in an RDF network. That is, for a given RDF subsystem, the extractors read
the MAT and auxiliary audit trails and send data to the receivers. The updaters read their data
from their image trails and apply it to their UpdateVolumes. During normal processing, no RDF
subsystem (except the RDFNET process within the network master primary system) interacts
with any other RDF subsystem in the RDF network. Therefore, the performance of an individual
RDF subsystem is unaffected by its inclusion within an RDF network.
RDF Takeovers Within a Network Environment
With RDF/ZLT, no committed data from any primary system in the RDF network is lost. The
discussions that follow regarding loss of data in a network takeover only apply to non-RDF/ZLT
environments.
If you have configured an RDF network and must initiate a takeover on a backup system in the
network, then you must execute a takeover on all the backup systems in the network. You do
that by issuing an RDFCOM TAKEOVER command on each individual backup system. When
a takeover occurs within an RDF network, each subsystem’s takeover operation consists of three
phases of operation:
1. A local undo phase
2. A file undo phase
3. A network undo phase
Takeover Phase 1 – Local Undo
This phase is identical to a normal RDF takeover (one that is totally unrelated to an RDF network).
It consists of determining what transaction data has already been applied to the backup database
but whose outcomes are unknown. Once the transactions have been identified, all updates
associated with them are undone. The purger process determines what transactions must be
undone and it writes the list into the ZTXUNDO file in the MIT.
For example, suppose you began a transaction on your primary system, you executed ten updates,
and you committed the transaction, but the extractor process was only able to transmit the first
five updates to the backup system before being terminated by an unplanned outage. In such a
case, the RDF subsystem recognizes it is missing data for the particular transaction (because it
does not know how the transaction ended), and it undoes the five updates it had previously
applied to the backup database.
In summary, phase 1 of a takeover operation undoes data associated with transactions whose
complete data did not make it to the backup system at the time the primary system failed.
278 Network Transactions