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

OWNER Attribute
The OWNER attribute specifies a user ID under which all RDF processes will always run. This
global configuration parameter provides functionality whereby any super ID group user ID can
start and stop RDF.
To illustrate this functionality, imagine ten users are responsible for managing a particular RDF
configuration and that SUPER.RDF is configured as the OWNER. Instead of providing all ten users
access to the SUPER.RDF user ID, each individual user can be assigned a separate super ID group
user ID. If one user is assigned SUPER.FIRST and another SUPER.SECOND, for example, they can
both log on with their user ID and be able to start or stop RDF. The RDF processes do not run under
SUPER.FIRST or SUPER.SECOND, however, but under SUPER.RDF (the RDF OWNER assigned
during configuration). The same principal applies to the other eight users.
The user ID associated with OWNER must be a valid Guardian user ID and must identify an existing
user account on the RDF primary and backup systems. The OWNER must also be a member of the
super ID group, since that is an existing requirement in RDF for stopping and starting RDF.
OWNER is an unalterable value. There is no need to change the value, unless you configured it
incorrectly (in which case you must reinitialize RDF with the correct value).
If the OWNER attribute is omitted, only the user ID that initializes RDF can start or stop RDF (as is
true for all versions of RDF prior to 1.7).
Setting Image Trail Attributes
Use SET IMAGETRAIL and ADD IMAGETRAIL commands to configure the following image trail
attribute:
• ATINDEX
The ATINDEX attribute associates an image trail with a specific audit trail on the primary system.
The RECEIVER RDFVOLUME attribute specifies the disk volume that contains the receiver’s master
image trail. The receiver process writes all commit/abort records to this volume. All updaters must
be configured to secondary image trails.
To create secondary image trails, use the ADD IMAGETRAIL command. Later, when you configure
your individual updater processes, you assign each of these processes to a specific image trail.
By spreading updaters across secondary image trails, you reduce the number of updaters contending
for a specific trail. ATINDEX specifies which receiver will write to that trail; 0 is the default.
Each secondary image trail contains the audit records needed by the associated updater processes.
Image trail files in secondary image trails have the same extent sizes as image trail files on the
volume specified by RDFVOLUME.
NOTE: To have secondary image trails, you must add them after initialization and before RDF
has been started for the first time. Also you cannot add secondary image trails until you have
configured the receiver, as described in the previous paragraphs. The secondary image trail files
have the same extents as the master image trail files. To delete a secondary image trail, you must
stop RDF, delete any updaters associated with the particular trail, and then delete the trail. Normally,
you should never delete a secondary image trail until RDF has completely caught up with TMF.
To add one secondary image trail to the volume named $IMAGA1 and another to the volume
named $IMAGA2, issue the following commands:
]SET IMAGETRAIL ATINDEX 0
]ADD IMAGETRAIL $IMAGA1
]SET IMAGETRAIL ATINDEX 1
]ADD IMAGETRAIL $IMAGA2
Dedicated Image Trails or Image Trails on UpdateVolumes
The master image trail (MIT) should always be placed on an image trail not used by any updaters.
For secondary image trails, however, you have two options. If your peak time audit generation
Initializing and Configuring RDF 81