The ATM transaction manager 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 transaction manager’s database;
change any of the following ATM ADARUN parameter values:
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 Transaction 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 the local ATM
transaction manager and provides the details of any incomplete global
transactions.
The TM 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 managers 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 manager obtains, from its recovery file and from any partner ATM managers 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 manager 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.
In an Adabas environment without Transaction Manager, it can happen that a client session changes a database, and that the database is then recycled without the client session being made aware. This can be prevented (see below). However, if it is allowed to happen, the client might then make more changes and then commit, receiving a positive response from Adabas - not knowing that the changes made in the previous Adabas session were backed out as a result of the recycle. The same situation applies when Transaction Manager is present. To avoid this problem, one or both of the following approaches must be used:
Set the ADARUN parameter OPENRQ=YES for all
databases, so that a restarted database will give response code 9, subcode 66,
indicating that a new OP is required.
Use ETIDs for all client sessions, so that “backout during system open” sets a pending response 9 for the affected session.
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 transaction manager. If the ATM manager is inactive, the recovery process is deferred until the manager 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 manager 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 manager writes a message to the console indicating that the re-synchronization 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 transaction manager 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 manager starts, the ATM manager 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.
