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

1. The network configuration record must point to the network master of the RDF network.
2. You must ensure that the updater responsible for the PNETTXVOLUME is also configured
to the same image trail as that listed in the network master’s network configuration record.
Otherwise, validation will fail and you will be unable to start the newly configured subsystem.
NOTE: If you must change the PNETTXVOLUME, the imagetrail, or the RDFVOLUME
of any subsystem in your RDF network, then you must stop and reinitialize all of the RDF
subsystems in that network.
RDF Networks and ABORT or STOP RDF Operations
If no network transactions are active, you can stop RDF on any subsystem at any time without
affecting the other systems in an RDF network. The same is true with regard to an RDF monitor
process aborting its RDF subsystem.
There is, however, one exceptional situation. The RDFNET process runs on the network master’s
primary system. For every primary system in the RDF network, the RDFNET process maintains
a 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).
304 Network Transactions