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

Name
The second column specifies the name of each process. Because the secondary image trails
$IMAGE0 and $IMAGEA1 are not processes, they do not have process names or RTD times. In
the second example above, observe that the monitor no longer has the configured process name.
The reason for this is that the monitor started on the backup system for a takeover operation is
started with a Guardian-generated name.
RTD Time
The third column (labeled 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 application program each process is running. Please note that an RTD time is
not a precise indication of how far an RDF process is behind. An RTD time is only relative and is
an approximation. The more accurate RTD time is that of the extractor. An updater's RTD is even
more relative because it may show 20 seconds one instance and then show 0 seconds in the next
instance. The reason for this is that the updater applies audit through an exceptionally efficient
low-level interface direct to the disk process and it can take only a fraction of 1 second to apply
what was generated on the primary system in 20 seconds.
On the primary system, TMF attaches a timestamp to every commit and abort status record generated
for the application program. The extractor process, in turn, attaches the most recent TMF
commit/abort timestamp to all data modification image records.
The RTD value for the master extractor is the difference between the “last modified time” of the
latest file in the TMF Master Audit Trail (MAT) and the timestamp of the last commit or abort record
seen by this extractor. For an extractor associated with an aux trail, its RTD value is the difference
between the “last modified time” of the latest file in the specific audit trail and the general time
when the last audit record processed by this extractor was added to this audit trail.
As each receiver processes image records, it stores them in image trail buffers and writes those
buffers to disk as the need arises. The receiver's RTD only has value on a receiver restart condition
(for example, primary CPU failure), where the receiver process has had to go to disk to get its
context and then begin operations anew, just as if it were just started by RDFCOM. The RTD reflects
only how long it takes to complete its restart, and in this sense a receiver's RTD has no consequence
because the extractor's RTD is of critical importance. In the takeover situation reflected in the second
example, the RTD is replaced by dots to indicate there is no RTD.
The RTD value reported for each updater process is the difference between the “last modified time”
of that updater's audit trail on the primary system and the timestamp added to the image record
by the extractor before sending it to the receiver. As is the case with the receiver during an RDF
takeover operation, the RTD is replaced by dots to indicate there is no RTD.
On a finely tuned RDF backup node, the RTD for an updater can regularly lag 1 to 15 seconds
behind TMF processing. However, this 15-second delay does not mean that 15 seconds are needed
to catch up; that operation might take only a few seconds.
If RDFCOM cannot connect to a particular process, RDFCOM displays dots (...) in the RTD Time,
Sequence, and Rel Byte No fields, and an appropriate file-system error number in the Error field.
Pri
The fourth column specifies the priority at which each process is running. In the RDF takeover
situation, the priority of the monitor is not reported.
236 Entering RDFCOM Commands