Version 7.5.1
 —  Adabas Transaction Manager Operations Guide  —

ATM Database Management


ATM Database Usage and Restrictions

The ATM daemon runs as a special kind of database nucleus for which the following restrictions apply:

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.

Top of page

ET Data Storage

ET Data Storage in the ATM Daemon's Database

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.

ET Data Storage with External Transaction Coordinators

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:

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.

Top of page

Pool/Queue Usage Control

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.

Top of page

Diagnostic Logging

Using ATMLOG Datasets

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:

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.

Using TMPLOG Dataset

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.

Top of page

Excluding DBMSs from Global Transaction Processing

Rigorous management of global transactions inevitably creates overhead, which can be minimized by careful exclusion of certain databases. For example:

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.

Top of page

Disengaging a Database from Two-Phase Commit Processing

If a database running with the ADARUN parameter setting DTP=RM is terminated, a message is issued by the ATM daemon indicating

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:

Top of page