The ATM daemon records details of incomplete, prepared transactions in the recovery record file. Whenever a transaction is completed, its recovery record is deleted. If the contents of this file are lost at a time when incomplete, prepared transactions exist in the system, ATM is not able to guarantee the integrity of those transactions.
You can use the Online Services application to check for incomplete transactions in the system.
Caution:
When incomplete transactions exist, you must
not
change the Database ID of an ATM daemon;
change any of the following ATM ADARUN parameter values:
TMDYNTCIDS,TMETDATA,TMSYNCMGR, or
TMTCIDPREF.
ATM uses the suspect transaction journal (STJ) file to record all known details of incomplete transactions that have been purged from the system as a result of intervention by the operator or database administrator.
Incomplete transactions can be purged as follows:
using the Stop User function provided by Online Services, or
as a result of a forced restart using the runtime parameter
TMRESTART.
Online Services can be used to browse through the contents of the STJ file.
Alternatively, you may use the sample program ATMSPRNT in the supplied JOBS library to produce a readable printout of the contents of the STJ file. See Print STJ File for more information. Use the comments in the job when modifying it to conform to site requirements.
There is no automatic housekeeping of the STJ file. It is intended for emergency use only. The database administrator should purge its contents from time to time, after making sure that the information contained in it is no longer required.
During the life of a transaction, an application gains ownership of certain database resources associated with the transaction. For example, records that are changed, or new and old unique descriptor values. Adabas locks these resources against use by other users or applications until the transaction is completed; that is, committed or backed out.
In the case of a global transaction, Adabas secures this information, together with the necessary recovery information, in its Work dataset. The information is not discarded until the end of the two-phase commit process for the owning transaction. It also survives database restart if the transaction has successfully completed the prepare phase.
When a database nucleus with the runtime parameter
DTP=RM is started, it signs on to ATM and provides the
details of any incomplete global transactions.
ATM then attempts to complete each of the transactions by instructing each relevant database to commit its transaction or roll back its changes, as appropriate. If any of the incomplete transactions have branches in other systems, the partner ATM daemons in those systems are also instructed to commit or roll back, as appropriate.
Meanwhile, the resources that were changed by the incomplete transaction remain unavailable to other users.
When started, an ATM daemon obtains, from its recovery file and from any partner ATM daemons in other systems, details of any global transactions that were incomplete when it last terminated. It then attempts to complete each of these transactions by instructing each relevant database to commit its transaction or roll back its changes, and each partner ATM to commit or roll back its transaction branches, as appropriate.
The integrity of global transaction is thus secured across restarts of critical components.
ATM does not decide whether to commit or back out a prepared transaction that is controlled by an external transaction coordinator. Any such transaction remains in doubt until the external coordinator resolves it.
For a CICS system in which an Adabas TRUE interface is used, the TRUE is enabled during CICS startup. If the system has been configured to use the RMI, the program that enables the TRUE interface to attempt to coordinate recovery with the local ATM daemon. If the ATM daemon is inactive, the recovery process is deferred until ATM starts up.
The recovery process is the same, whether it occurs during CICS startup or ATM startup:
The ATM CICS Resync Driver program obtains from the local ATM daemon a list of all incomplete (but already prepared) transactions that were controlled by this CICS system.
CICS is then instructed to re-synchronize each of these transactions.
During this process, CICS tells ATM whether each transaction should be backed out or unconditionally committed.
When the last incomplete transaction has been processed, the ATM daemon writes a message to the console indicating that the re-synchronize process is complete.
In order to re-synchronize incomplete transactions between CICS and ATM, CICS logging must be active and CICS must be warm started. If CICS logging is not in use or if CICS is cold started when there are incomplete transactions in the system, transaction integrity cannot be guaranteed.
If RRMS is already active when the ATM daemon starts up, which is normally the case, ATM re-synchronizes in cooperation with RRMS to resolve any incomplete transactions that were under RRMS control.
If RRMS is unavailable when the ATM daemon starts, the ATM daemon issues a warning message to the console and waits until RRMS becomes available. Then it re-synchronizes.
If a critical component of RRMS becomes unavailable while ATM is operating, a warning message is issued to the console. In some cases, ATM is able to continue processing and initiates re-synchronization processing as soon as the missing component is reactivated.
