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

3. Run the changed SCF script.
When SCF restarts the gateway, lockstep processing is disabled. Thus, if your application calls
DOLOCKSTEP, the gateway will return control immediately to the application without doing lockstep
processing.
Disabling lockstep processing is a very useful feature. Suppose that the communications lines from
your RDF primary to your RDF backup systems are down. In such a case, the extractor cannot send
audit data to the backup system, and lockstep processing will hang until the communications lines
are back up and the extractor resumes sending audit data. This is desired behavior if you really
want lockstep processing. But suppose that the communications lines have been down for so long
that your applications are getting no work done at all. In such a case, you might want to disable
lockstep processing to allow your applications to resume their work without lockstep operations.
When lockstep is disabled, remember that your original transaction has already committed on the
primary system. If you should subsequently lose the primary system and do a takeover on the
backup system, the transaction might or might not have been committed in the backup database
depending on whether or not the extractor got all of the original audit data over to the backup
system before the primary system failed.
Reenabling Lockstep
To reenable lockstep processing:
1. Change DISABLE to ENABLE in the STARTUPMSG attribute script.
2. Manually delete the RDF lockstep gateway process from SCF.
3. Run the changed SCF script.
When SCF restarts the gateway, lockstep processing is enabled.
Lockstep Performance Ramifications
By definition, a lockstep operation will increase the response time of your application because,
after having invoked DoLockstep, the application must wait for the data to become safely stored
in the backup system’s image trail. The extractor and receiver processes have been streamlined
to facilitate lockstep processing, but a short delay is unavoidable. Depending on the number of
auxiliary audit trails configured, if auxiliary audit trails are configured for lockstep support, then
the processing time of lockstep varies.
Expand problems or CPU failures that trigger extractor and receiver restart operations could also
increase response times.
As described in “Multiple Concurrent Lockstep Operations” (page 302), the RDF gateway only ever
has a single lockstep transaction in progress at any one time. If called while a lockstep transaction
is in progress, the RDF gateway merely queues the request. Consequently, if an application process
issues a DoLockstep request immediately after the gateway has started a lockstep transaction, that
request must wait to be performed until the current lockstep transaction is committed on the backup
system. That could also increase response times.
Lockstep and Network Transactions
You cannot use lockstep to protect data associated with network transactions because the lockstep
protocol only pertains to operations on a single system. If lockstep is used with network transactions,
consistency between lockstep operations and the distributed application database files cannot be
guaranteed after an RDF takeover.
For a description of lockstep operation event messages, see “Lockstep Gateway Event Messages”
(page 305)
304 Process-Lockstep Operation