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

When the extractor pins an audit trail file, it does this by sending a message to TMF, asking TMF
to keep the file pinned until the extractor no longer needs it, so in reality it is TMF who actually
pins the file on behalf of RDF. When the extractor rolls over from one audit trail file to the next, it
unpins the earlier file and pins the next file.
NOTE: TMF keeps the extractor's audit trail file pinned even if you stop RDF. This ensures that
the file is in the audit trail for the extractor when you next start RDF.
If TMF has an audit trail file pinned and it wants to roll over that file, then it generates a TMF event
to indicate that it cannot unpin the file because it is keeping the file pinned on behalf of RDF. In
this event, TMF includes in that event the name of the RDF control subvolume for the RDF subsystem
that wants the file pinned. Thus you can always determine which RDF subsystem is holding up TMF.
If the extractor has an audit trail file pinned, the extractor is either stopped or stalled for some
reason, and this is affecting TMF, there are two ways to unpin the audit trail file.
1. Issue the RDFCOM UNPINAUDIT command. If you have only one RDF subsystem configured
on your primary system and the control subvolume is the name of the primary system, then
this is a simple operation. If, however, you have multiple RDF subsystems configured on the
primary system, each with its own set of extractors, then you may need to issue the UNPIN
audit command for each RDF subsystem. You do this by starting RDFCOM, and then for each
RDF subsystem you issue the OPEN command with the name of RDF subsystem's control
subvolume, and then issue the UNPINAUDIT command. When you have issued the
UNPINAUDIT command for each control subvolume, then the file is unpinned by TMF.
2. Issue the STOP TMF command. While stopping RDF does not unpin an audit trail file, stopping
TMF does.
There is a special circumstance that has caused trouble for some customers. Assume you are running
RDF to protect your primary database. Now assume that someone configures a small RDF test
subsystem, starts that test subsystem, stops it, and then deletes the RDF control subvolume on the
primary and backup systems to eliminate all vestiges of that test subsystem. In doing this, the person
performing the test has omitted one critical task - issuing the UNPINAUDIT command for that
subsystem before deleting the control subvolume. Why is this a problem? Remember that when
this RDF test subsystem was started, its extractor pinned the current audit trail file, and this file
remains pinned even after that RDF subsystem was stopped. To complicate this problem further,
the control subvolume was deleted. To recover from this problem, recall that TMF generates an
event when it cannot unpin a file because of RDF and recall that the control subvolume for the RDF
subsystem that has the file pinned is named in the event. In this example, however, the control
subvolume does not even exist because it was deleted at the end of the test. If you find yourself in
this situation, then you must configure an RDF subsystem with the name of the control subvolume
listed in the TMF event. Once you have configured it, you can then issue the RDFCOM OPEN
command, specifying this control subvolume and then issue the UNPINAUDIT command.
CAUTION: To avoid problems like that described immediately, always be sure that you issue the
UNPINAUDIT command before you delete an RDF control subvolume.
Stopping RDF
If the communications lines between the primary and backup systems are up, there are two ways
to stop RDF:
1. Issue a STOP RDF command on the primary system.
2. Issue a TMFCOM STOP TMF command on the primary system. After the RDF updaters have
reached the TMF shutdown record, RDF stops and then TMF stops.
If the communications lines between the two systems are down and you want to stop RDF, you
must issue the STOP RDF command on both the primary and backup systems.
Stopping RDF 121