The ATM daemon runs as a special kind of database nucleus for which the following restrictions apply:
no files may be loaded to this database except as detailed in the installation process.
no application program or user session may issue Adabas calls to this database.
At version 7.5, the recovery file, suspect transaction journal and
ET data file must reside in the ATM daemon’s own
database.
If it becomes necessary to perform maintenance of the ATM daemon’s
database (for example, to reorder the checkpoint file), you must first shut
down the system. Then carry out the maintenance normally in either single-user
or multi-user mode. You must first, temporarily, set the ADARUN parameter
DTP=NO.
Note:
Any utility jobs run against the ATM daemon database must use an
Adabas link module that does not use a TM proxy or the ATM job parameter
ATM=OFF must be set.
Once you have defined an ATM daemon database, its Database ID should remain fixed. If you need to change it, you must first ensure that there are no incomplete transactions anywhere in your system. Follow the normal procedure for closing down the ATM daemon and, if appropriate, its recovery database. Then close down all application/client environments in which a TM proxy is active. Now you can change the Database ID. Next, follow the normal procedure for activating ATM, then restart the application/client environments.
When Adabas Transaction Manager is in use with the runtime parameter
setting ADARUN TMETDATA=ATM,
ET data is stored in and read from the ATM daemon's
database.
If your applications need their current ET
data to be established in the ATM daemon's database before they can execute,
refer to section Copy ET Data
for more information.
When running with the CICS Syncpoint Manager or Recoverable Resource
Management Services (RRMS), it is not possible to synchronize the storage of
ET data when an unsolicited syncpoint occurs,
because CICS and RRMS syncpoints have no knowledge of
ET data.
If an application stores ET data and runs in
a CICS/RMI or RRMS environment, you can ensure that the storing of its
ET data is synchronized with the two-phase commit
process by conforming to the following rules:
Any syncpoint for which ET data is to be
stored must be triggered by an ET or
CL command.
The ET or CL
command that triggers the syncpoint must also supply the
ET data; that is, if the application issues a series
of ET commands to different databases, the first
ET must supply the ET
data.
In an IMS/TM system whose transactions are coordinated by RRMS, it is
not possible to store ET data synchronously with an
RRMS syncpoint. IMS allows an RRMS commit syncpoint to take place only at the
successful completion of message processing, and this syncpoint cannot be
triggered by an ET or CL
command.
Most pools and queues used by ATM will expand dynamically as required. In other cases, to help avoid filling a pool or queue, ATM issues a warning message to the operator and to DDPRINT when the internal pool or queue area becomes 85% full (rounded down). The high-water marks can be displayed using the Online Services application.
You can optionally write Adabas Transaction Manager diagnostic log information to sequential log datasets. For MVS systems (z/OS and OS/390), the characteristics of the log datasets are:
sequential organization
fixed-block records
record length of 256 bytes
block size 5120 bytes
For BS2000 systems the ATMLOG datasets are SAM files with variable-length record format.
Use of the log datasets is determined by the ADARUN parameter
TMLOG and the operator command TM
LOG.
The log datasets ATMLOG1 and ATMLOG2 must be defined in the ATM daemon
startup job control. It is recommended that you specify
DCB=BUFNO=1 for these datasets on MVS systems (OS/390
and z/OS), to avoid the possibility of Sx37 abends during termination of the
ATM daemon or switching of log datasets.
A sample Natural job ATMLPRNT is provided in the supplied JOBS library for use in producing a readable report from a log dataset. Use the comments in the job when modifying it to conform to site requirements. The content of the report is undocumented, and subject to change. A log report might be requested by Software AGs support for problem diagnosis.
In MVS systems (OS/390 or z/OS), any batch jobs that use a TM proxy cause the following message to appear in its JES message log:
IEC130I TMPLOG DD STATEMENT MISSING
This message can be ignored. Alternatively, you can suppress it by including the following JCL statement in the job step:
//TMPLOG DD DUMMY
The TMPLOG DD name can be used to provide a dataset for a diagnostic log that details activity within the TM proxy.
Caution:
Use this diagnostic log only after consulting with Software AG
support.
Rigorous management of global transactions inevitably creates overhead, which can be minimized by careful exclusion of certain databases. For example:
A development database generally does not require the same guarantees of transaction integrity as a production database and can therefore be excluded from two-phase commit processing.
System files generally do not require the same guarantees of transaction integrity as application data files. If you maintain application data files and system files in different databases, those containing system files can often be excluded from two-phase commit processing.
The ADARUN DTP parameter is used to include an
Adabas database (DTP=RM) or exclude it from
(DTP=NO) participation in two-phase commit processing.
Remember, however, that ATM generates ET or
BT commands to changed databases that run with
DTP=NO, when a user’s global transaction terminates. For
more information about the way ATM handles commands directed at databases
running with DTP=NO, see the section
Adabas Transactional
Commands.
If a database running with the ADARUN parameter setting
DTP=RM is terminated, a message is issued by the ATM
daemon indicating
that an RM has signed off;
whether or not the RM had unresolved transactions; and
if so, whether the unresolved transactions were prepared or unprepared.
If you restart the database with DTP=NO, you must
also specify IGNDTP=YES for its first execution.
However, you may lose the integrity of incomplete prepared transactions if you
restart the database with DTP=NO and
IGNDTP=YES. To avoid this, you must resolve any
incomplete transactions before switching to DTP=NO.
If you restart a database with a different DTP
parameter value, the change will not be recognized by any TM proxy components,
for users who are already in session with that database. This could cause
errors if such a user tries to change the database. However, new user sessions
will recognize the new parameter value, and users who close the database and
issue a new OP command will be able to carry on
processing normally.
If you need to change a database’s DTP parameter,
the safest procedure is as follows:
ensure that the database is closed cleanly, with no incomplete global transactions in flight;
restart all application/client environments which use the database;
restart the database.
