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

LockStepNotDone (value is 31426)
The RDF gateway process cannot be started. This status has the same ramifications as
LockstepDisabled, and what your application does next is your decision.
The Lockstep Transaction
Remember, you must commit your business transaction before you call DoLockstep. Thus, when the
gateway process issues the lockstep transaction, all audit records associated with your business
transaction are guaranteed to be flushed in the audit trail on the primary system before any lockstep
audit is generated. Therefore, when the lockstep audit is safely in the image trail on the backup
system, you are also guaranteed to have all audit records of your business transaction safely in
the image trail as well, because your business audit preceded the lockstep audit.
RDF Lockstep File
The lockstep gateway creates a lockstep file for every RDF protected audit trail. Each lockstep
transaction involves a single update to all the gateway managed lockstep files in the current
configuration. The lockstep file is created by the lockstep gateway and it must only be updated by
the gateway. If you open the file and update data in it, you can potentially corrupt all future lockstep
operations.
When configuring the RDF configuration record, you must specify the name of the volume on which
you want the lockstep file for the Master Audit Trail (MAT) to be located. This volume must be
configured to the MAT, and either the entire volume or at least the lockstep file must be protected
by the RDF subsystem. You specify the volume by issuing a SET RDF LOCKSTEPVOL command.
SET RDF LOCKSTEPVOL volume
Where volume is a volume name and the volume is configured to the MAT. Additionally you
must ensure that you add an updater to protect either the volume or the lockstep file.
For other RDF protected auxiliary audit trails, the first volume configured for each auxiliary audit
trail is used to create the special lockstep file. The full file name is
volume.ZRDFLKSP.control-subvol. If you only need to protect this file on this volume, then
INCLUDE it when you configure the updater for the volume.
The RDF lockstep protocol supports virtual disks, so you can store your database on virtual disks
managed by the Storage Management Facility (SMF). The RDF LOCKSTEPVOL, however, must be
a physical disk, and it must be configured to the MAT. For auxiliary audit trails, the first configured
volume must be a physical disk to allow creation of the lockstep file for the concerned auxiliary
audit trail. Because the RDF lockstep file on the LOCKSTEPVOL is a direct (physical, not logical)
file, it can reside easily on a small portion of a physical disk to store the file, and you can then
subdivide the rest of the disk into virtual disks.
Multiple Concurrent Lockstep Operations
Because DoLockstep suspends the calling application until the associated lockstep transaction
commits on the backup system, a single application process cannot have more than one lockstep
operation in progress at any one time.
Multiple application processes, however, can invoke DoLockstep concurrently.
If called while idle, the RDF gateway immediately initiates a lockstep transaction to perform the
requested lockstep operation (one calling process, one lockstep transaction).
If called while it has a lockstep transaction active, the RDF gateway merely queues the request.
When the current lockstep transaction commits, the gateway initiates a new one that performs the
lockstep operation collectively for all of the queued requests (multiple calling processes, one lockstep
transaction).
Because the business transactions of each application process must have committed on the primary
system before the process called DoLockstep, the audit data for those is guaranteed to be in the
302 Process-Lockstep Operation