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

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.
Volume and Seqnce
The fifth and sixth columns together specify a file associated with each process:
• The monitor entry reflects the name of the latest MAT file to which TMF is writing
($AUDMAT.ZTMFAT.AA000056 in this example).
• Each extractor entry reflects the name of the TMF audit trail file from which it is reading
($AUDMAT.ZTMFAT.AA000056 for the master extractor and $AUDAUX1.ZTMFAT.BB000004
for the auxiliary extractor in this example).
• The receiver entries reflect the names of the current image trail files to which each receiver is
writing ($RRCV0 write control records to $MIT and image records for updater $RUPD1 to
$IMAGE0; $RRCV1 writes image records for updaters $RUPD2 and $RUPD3 to $IMAGEA1
in this example).
240 Entering RDFCOM Commands