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

14 Network Transactions
The RDF/IMPX and RDF/ZLT products are able to guarantee backup database consistency for
transactions that update data residing on more than one RDF primary system. RDF/IMPX and
RDF/ZLT can map the volumes being protected to both the MAT and auxiliary audit trails.
NOTE: Network transaction processing is currently not supported in configurations that use the
triple contingency feature. You must use RDF/IMPX or RDF/ZLT to protect all databases open to
network transactions.
Without planning for network transaction support, the RDF product cannot guarantee database
consistency among the associated backup systems following the failure of one of the primary
systems.
Support for network transactions requires two major external changes.
1. If you have a distributed database spread over several RDF primary systems, you must configure
an RDF network wherein each primary system residing on its own, mutually exclusive node
has its own RDF subsystem that replicates its local data to its own backup system. This is
referred to as an RDF network because each RDF subsystem knows the names of the systems
protected by all other RDF subsystems in the network. One, and only one, RDF subsystem
within the network is configured as the network master.
2. If you lose one or more RDF primary systems in the RDF network, you must execute RDF takeover
operations on all backup systems in the network.
For those primary systems still alive, you must first quiesce all application activity (both local
and remote) so that no further database updates are being performed, and then bring down
the communication lines between the primary and backup systems before initiating the takeover.
With network transaction support, you must now be more careful when creating Enscribe files that
have alternate key files. Specifically, when you create an Enscribe file with an altkey file you must
ensure that both files reside on the same primary system and that both are protected by the same
RDF subsystem. If you do not do so, then the updater responsible for creating the file on the backup
system will not create the file; rather, it will report an error 740 when it determines that the altkey
file is not protected by its RDF subsystem.
For RDF/ZLT configurations, all nodes that participate in a network transaction need to be configured
in the RDF network for RDF/ZLT protection.
Configuration Changes
To support network transactions, several configuration attributes and a configuration record have
been added to the RDF configuration file.
NETWORK Attribute
This attribute, located in the RDF configuration record, specifies whether or not you are configuring
an RDF network.
To set this attribute, use this RDFCOM command:
SET RDF NETWORK {ON | OFF}
When this attribute is set to OFF (the default value), RDF takeover operations execute just as they
have in the past, and database consistency is not guaranteed for transactions that spanned more
than one primary system.
When this attribute is set to ON, the RDF subsystem can guarantee backup database consistency
across multiple RDF systems configured within an RDF network.
Configuration Changes 279