The Lockstep Transaction; Rdf Lockstep File - HP NonStop RDF J-series RVUs Management Manual

When the RDF receiver has flushed all audit records up to and including the lockstep audit into
the image trail, it replies to the extractor that the lockstep data is safe. When the extractor receives
that information, it replies to the gateway which, in turn, passes status back to the DoLockstep
call, and the latter then returns status to the application.
DoLockstep is a waited operation that waits until the RDF subsystem has safely stored all audit
data up to and including all audit data associated with the lockstep transaction in the image trail.
Therefore, if the communications line between the primary and backup nodes should go down
after the application has called DoLockstep, the application will wait until the line comes back
up and the lockstep audit data is safely stored.
DoLockstep returns one of these three states:
LockStepDone (value is 31428)
All audit data associated with the lockstep operation has been safely stored in the image trail
on the backup system.
LockStepDisabled (value is 31429)
Only returned when you have disabled lockstep processing. When this condition code is
returned to your application, what your application does next is up to you. For example, you
might choose to execute a recovery transaction that backs out the work of the previous
business transaction, or you might want to continue as if the lockstep operation has completed
and rely on RDF to ship the audit data to the backup system as soon as possible.
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

Each lockstep transaction involves a single update to a gateway-managed lockstep file. This 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 to be located. This volume must be configured to the Master
Audit Trail (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.
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 Master Audit Trail (MAT). 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.
The Lockstep Transaction 311