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

special file on its PNETTXVOLUME volume. If the communications line to one of those primary
systems is down, and you then issue a STOP RDF command on the network master’s primary system,
the STOP RDF command could appear to hang. The reason for this is that the RDFNET process
might be trying to open a file for the system whose path is down. In such a case, the RDFNET
process waits until either the line comes back up or the Expand level-4 timer expires. If the RDFNET
process must wait for the Expand level-4 timer to expire, it will not be able to respond to the STOP
RDF or abort RDF request until the timer expires. By default, the timer is four or five minutes.
If you are waiting for the network master subsystem to shut down, and the operation does not
appear to be happening, check the communication lines to the other systems in the network. If one
of them is down and the RDFNET process is tying up the orderly shutdown of RDF, stop the RDFNET
process manually.
CAUTION: If you stop any RDF subsystem in an RDF network, you could lose large amounts of
committed data in the event of an unplanned outage.
RDF Networks and Stop-Update-to-Time Operations
Stop-update-to-time operations affect only the backup database of the particular system on which
they are initiated. If you have an RDF network, you can execute a stop-update-to-time operation
on any primary system in the network, but the operation affects only the backup database of the
system on which it is initiated (it does not affect data in any other backup database, even for
network transactions).
For example, suppose you have ten RDF subsystems in your RDF network, and most transactions
on each system touch two or more systems in the network. Thus, nearly every transaction is a
network transaction. If you execute a stop-update-to-time operation on one of these systems, that
operation only brings that particular subsystem’s backup database into a consistent state with
regard to transaction commit times on the associated primary database. It does not execute undo
operations on any other backup systems in the RDF network.
To illustrate this, assume you began a transaction (T10) at 12:00 P.M., executed ten updates on
each of two primary systems in an RDF network (\A and \B), and committed T10 at 12:05. Assume
further that you had previously issued a stop-update-to-time operation on system \A, specifying
12:01 P.M. When the stop-update-to-time operation completes, the data for T10 is backed out of
system \A’s backup database because T10 committed after 12:00 P.M. The data for T10 on
system \B’s backup database, however, remains unaffected (because a stop-update-to-time operation
only applies to the backup system associated with the primary system on which it is initiated).
It is rare for clocks on different systems to have exactly the same values, thus rendering it impossible
for stop-update-to-time operations to perform correctly across multiple backup systems.
Sample Configurations
Two sample configurations follow, one for the network master and one for a non network master.
The network attributes are highlighted in bold.
Sample Network Master Configuration
The configuration that follows is for a network master RDF subsystem running from \RDF04 to
\RDF06:
SET RDF SOFTWARELOC $SYSTEM.RDF
SET RDF LOGFILE $0
SET RDF UPDATERDELAY 10
SET RDF UPDATERTXTIME 60
SET RDF UPDATERRTDWARNING 60
SET RDF UPDATEROPEN PROTECTED
SET RDF NETWORK ON
SET RDF NETWORKMASTER ON
SET RDF UPDATEREXCEPTION OFF
288 Network Transactions