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

CPUS primary-CPU : backup-CPU
identifies the CPUs in which the receiver process is to run as a process pair on the backup
system; primary-CPU is the primary CPU; backup-CPU is the backup CPU. Values range
from 0 through 15. The default is 0:1.
EXTENTS ( primary-extent , secondary-extent )
specifies the extent sizes to be used for the RDF image files on the backup system;
primary-extent-size is the primary extent size in pages; secondary-extent-size
is the size of each secondary extent in pages. The default is 100,100. The limit is 65500,
65500. This parameter only has an effect when specified for the MAT receiver.
RDFVOLUME $volume
specifies which disk volume on the backup system is to be used for the receiver’s master image
trail (the image trail to which the receiver writes all commit/abort records). The default is
$SYSTEM.
This attribute applies only to the master receiver (the receiver process configured with an
ATINDEX value of 0). It is ignored for auxiliary receivers.
For best performance, do not use $SYSTEM as the RDFVOLUME.
If the backup system will run with updating disabled, be sure to specify an RDFVOLUME disk
that has an adequate amount of available space.
If the RDFVOLUME disk becomes filled, the receiver process will receive error 43 messages
(Unable to obtain disk space for extent) from the file system until the situation is corrected.
PRIORITY priority
identifies the execution priority for the receiver process; priority is the execution priority,
from 10 through 199. The default is 165.
PROCESS process-name
specifies the process name for the receiver process; process-name is any unique, valid
process name of up to six characters; the first character must be a dollar sign ($). You cannot
specify any of the reserved process names listed in the Guardian Procedure Calls Reference
Manual. Names longer than six characters, including the $ sign, are invalid.
This parameter is not optional. You must explicitly name the receiver process.
FASTUPDATEMODE {ON | OFF}
FASTUPDATEMODE used to be known as SLOWMODE. During normal processing, the updaters’
RTD values are typically 0 to 20 seconds behind the extractor’s RTD value. This is expected
and normal behavior, although if 20 it does not necessarily mean that the updaters are in fact
running 20 seconds behind the extractor nor does it mean it will take 20 seconds for the
updaters to catch up. The updaters cannot read past what the receiver deems safe, and that
is determined by the frequency with which the receiver updates its context records. The receiver
normally updates its context records every 5 to 15 seconds, and the updaters’ RTD values
reflect that interval.
Some customers prefer the updaters to have the lowest possible RTD value at all times. This
can be accomplished by setting FASTUPDATEMODE ON.
With FASTUPDATEMODE ON, the receiver updates its context records after processing each
extractor message buffer. This enables the updaters to read and apply image records much
faster. It also, however, slows the extractor-to-receiver throughput rate. You should only specify
FASTUPDATEMODE ON if your throughput rate is typically low to moderate. In environments
with high extractor-to-receiver throughput, specifying FASTUPDATEMODE ON will cause the
extractor to fall behind TMF audit generation. See “Installing and Configuring RDF” (page 58)
for a more complete discussion of this option, and note that for FASTUPDATEMODE to achieve
what you want, you must also set the RDF UPDATERDELAY to 1 second.
The default is FASTUPDATEMODE OFF.
RDFCOM Commands 225