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

either for block splits or during FUP RELOAD operations, and all audits generated by the RDF
updaters.
The extractor always tries to fill the buffer to be sent to the receiver. The buffer never contains
partial records; if the buffer is nearly full and the next record to be transmitted does not fit in its
entirety, the extractor transmits the current buffer and puts that next record at the beginning of the
next buffer. The extractor never waits for more than one second to send data to the receiver. If its
current buffer is not filled within a second, the extractor transmits the buffer (even though it is not
filled).
Although the extractor runs as a process pair, the primary process does not maintain restart
information nor checkpoint this information to its backup. Instead, the receiver maintains all restart
information for the extractor, ensuring that the extractor can be restarted without any loss of data.
The restart point is based on the MAT position of the last record safely stored in the image trail on
the backup system.
Whenever you start RDF, the extractor requests its starting position in the audit trail from the receiver.
Because this position is based on the audit trail position of the last image record safely stored in
the image trail by the receiver, this method guarantees that no audit is mistakenly omitted. If the
primary extractor process fails, the backup process requests from the receiver a new starting position
in the audit trail, ensuring a correct restart position. This extractor-receiver protocol also provides
protection against messages from the extractor erroneously arriving out-of-order: if a message
arrives out-of-order, the receiver directs the extractor to restart.
When the extractor reads from an audit trail file, it pins the file by sending a message to TMF.
Once pinned, an audit trail file remains pinned until the extractor unpins it or if you issue the
RDFCOM UNPINAUDIT command at the primary system.
CAUTION: Before deleting an RDF configuration, always issue an UNPINAUDIT command to
unpin any audit trail files that might be pinned by the configuration. If you delete the configuration
without first doing so, then you will be unable to unpin the files afterward.
If you unpin files, RDF cannot be restarted if the files required by the extractor cannot be made
available. When you unpin audit trail files, be sure that these files are dumped to disk or tape. If
they are not dumped, and the TMP renames the file or files required by the extractor, you will have
to reinitialize RDF and resynchronize the primary and backup databases.
In response to the UNPINAUDIT command, RDFCOM issues a prompt asking you to confirm your
request.
If the files are unpinned successfully, RDFCOM issues an informational message to that effect.
If an error occurs while attempting to unpin the audit trail files, the command is ignored, and
RDFCOM issues a message indicating the error.
Receiver Process
A receiver process is a process pair that runs on the backup system. There is one receiver for each
configured extractor. A receiver process accepts audit records from its extractor, sorts them, and
then writes them to the appropriate RDF image trail, as shown in Figure 6. (The restartability of a
receiver ensures the receiver's correctness at process takeover or under any conditions requiring
resynchronization with its extractor.)
A receiver determines which updater will apply a given image record, and it sorts that record into
the image trail used by that updater. The records in the image trails are subsequently used by
updater processes to update the backup database.
Each receiver creates its own image trail files, preallocates extents, initiates rollovers, and manages
them, except for purging, a task performed by the purger process .
RDF Operations 39