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

After recompiling your program, you must then decide whether you want to bind the object explicitly
into your program or treat the object as a user library.
Typically you should explicitly bind the object into your program. The object file (LSLIBTO) is very
small, and there are no benefits to treating it as a user library.
To bind LSLIBTO into your program, issue this statement:
Select Search $vol.subvol.LSLIBTO
where $vol.subvol is the location where you have placed the lockstep library file.
If you do not want to bind the object into your program and if you do not already use a user
library, then you can skip the bind step and treat LSLIBTO as a user library.
The TAL procedure call syntax is:
status := DoLockstep;
where status is an int.
NOTE: The DoLockstep procedure can only be invoked from TAL and COBOL85 programs.
Non-native C and native mode languages (C, C++, native mode COBOL, and pTAL) are not
supported.
DoLockStep Execution
DoLockstep communicates with an RDF gateway process that acts as the coordinator of the lockstep
operation. This gateway initiates a new lockstep transaction against a special RDF lockstep file.
The gateway passes information about the lockstep transaction to the RDF extractor. 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.
NOTE: If the Master Audit Trail (MAT) and Auxiliary Audit Trail (AUX) disks are configured for
RDF protection:
• The special RDF lockstep file is created for each audit trail (MAT and AUX).
• A single lockstep transaction is performed across all the lockstep files.
The lockstep gateway communicates with all the extractors (MAT and AUX) and waits for the
response from them before it returns the status to the application. Depending on the number of
extractors, the total time taken for the completion of the lockstep operation varies.
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.
The DoLockstep Procedure 301