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

Table 9 RDF States (continued)
DescriptionStatus
UPDATERNSASUSPEND attribute). You must consult the RDF LOG for
either the RDF event 905 or 908 to determine if it is safe for you to
perform the DDL operation on the backup system.
The monitor is either stopped or is running but unable to respond. The
latter situation can happen for several reasons, such as the STATUS
* Monitor Unavailable *
RDF command having been issued from the backup system when the
Expand connection to the primary system is done. Another example
of this can happen as a result of a STOP RDF, REVERSE operation that
includes a REVERSE trigger that starts RDF with the WAIT option. If this
state persists and if Expand is up, then you should check the status of
the Monitor via a TACL status command. If the monitor is gone but the
other RDF processes are still present, then the process was probably
either manually stopped from TACL or perhaps is was stopped by a
double CPU failure. If you can confirm that the monitor is stopped and
the other RDF processes are running, you should manually stop all
surviving RDF processes by issuing the following TACL command on
both the primary and backup systems: STATUS *, PROG
$SYSTEM.RDF.*, STOP. This example assumes the location of the RDF
software is $SYSTEM.RDF.
Main STATUS RDF Display
The rest of the display provides current information about each RDF process configured.
For extractors, receivers, and image trails, the configured ATINDEX value is displayed in parentheses
following the object name. In the preceding example, the extractor $REXT0 and receiver $RRCV0
are associated with the MAT, while the extractor $$REXT1 and receiver $RRCV1 are associated
with auxiliary audit trail AUX01.
Because of insufficient space, however, ATINDEX values are not displayed explicitly for updaters.
To determine the ATINDEX value of a particular updater, see the ATINDEX value of the updater's
specific image trail.
In this example, a monitor process and two extractor processes are configured on the primary
system, and two receiver processes and three updater processes are configured on the backup
system. For each process, the following items appear, indicated by column headings near the top
of the display:
• RDF Process identifies the type of process. Notice that each updater process is identified
by the name of the primary volume the updater is protecting and the corresponding volume
on the backup system. In this example, each volume being updated on the backup system has
the same name as the corresponding volume on the primary system (for example, updates to
the volume $DATA07 on the primary system are replicated by the updater process $RUPD2
to the volume $DATA07 on the backup system).
• Name denotes the name assigned to the process.
• RTD Time specifies the current Relative Time Delay (RTD) value for the extractor process,
receiver process, and all updater processes. These values can help you determine how far
behind the applications each process is running.
In every audit trail, there are different timestamps that are observed by the extractor reading
that trail. The RTD value of an extractor corresponds to the difference between the last
modification timestamp of the latest audit trail file in the audit trail being read by the extractor
and the latest timestamp that extractor encountered within the audit trail. The extractor also
stores the latest timestamp taken from the audit trail in each audit record, which is then defined
as an image record.
The receiver RTD time virtually always mirrors that of the extractor sending to it. The only time
it varies is during a receiver restart condition. The value of this RTD time has to a large part
Performing Routine Operational Tasks 103