This section describes the operational changes and enhancements provided by Version 8.1.
Terminology Change: Job Parameters Replaced By Client Runtime Controls
Change of Parameter Length: TMCIDPREF (Dynamic Client ID Prefix) Parameter
Adabas Transaction Manager has been enhanced internally to become more efficient, in addition to the changes to support the new Adabas Version 8.1 evolution. For example, the Transaction Manager now focuses only on your currently active transactions whereas previous releases took on more internal overheads. This will show some gains in efficiency over previous releases for sites that have a high number of concurrent Adabas sessions. Over the whole system, in a single-system laboratory test, cpu reductions were experienced across the sum of clients, Transaction Manager, and Adabas RMs. These reductions are likely to be seen in higher-end production systems rather than small-scale test systems.
ATM job parameters are now referred to as Client Runtime Controls.
For more information, see section ATM Parameters.
Note:
This section is relevant only to z/OS systems. The setting of the
client control UseHostSystemTransactionManager is
ignored in other systems.
In earlier versions of Adabas Transaction Manager, the screen for
defining client runtime controls (job parameters) for ATM offered the value YES
for the parameter UseHostSystemTransactionManager. ATM
Version 8.1 validates this runtime control more rigorously than earlier
versions, to ensure that the host-system transaction manager is used when, and
only when it is required. It is therefore possible, if you use a configuration
file that has been converted from a previous version, that inappropriate
settings for this control will exist, and will cause runtime errors.
At Version 8.1, if you try to use a client session for which the runtime
control UseHostSystemTransactionManager
is set to YES and ATM’s client proxy has not been configured to use
the host system’s transaction manager, response code 240, subcode 444 will be
given, and you will be unable to continue processing normally. You should
therefore check that the runtime control
UseHostSystemTransactionManager
is set correctly in all client runtime controls; set to YES only for client
jobs or environments for which ATM supports the host system’s transaction
manager, and which have been correctly configured to use the host transaction
manager.
ATM’s client runtime controls are stored in a system file (configuration file). Many sites consider the configuration file to be a critical point in operations. Consequently, availability is critical. ATM now works with the Adabas System Coordinator to provide an alternate file facility, so that if one becomes unavailable the other is used automatically and dynamically. The switching to and from alternate is done on a session-by-session basis, dynamically. This means that at any point in time some sessions may be using one file, and some the other. This is as intended. If you wish to force all sessions to use the same file you can make the other unavailable for a long period and all sessions will move to it over time.
For more details please refer to the Adabas System Coordinator documentation.
Note:
It is your responsibility to make sure the contents of both
configuration files are identical. See the Adabas System
Coordinator documentation for more details.
Previous versions of Adabas Transaction Manager worked on the assumption that a client would make consistent use of single ETID across all database session, or else no ETID would be used. However, there are requirements for a client to use an ETID for certain database sessions, but no ETID for others.
From Version 8.1, ATM supports more flexible use of ETIDs. A client session can use ETIDs for some database sessions, while using other databases concurrently without ETID. Software AG strongly recommends that a client use no more than one non-blank ETID at a time.
For further details, see Introduction: Interfacing to Adabas Applications.
If a CL command is issued to a database that
is at ET status, when a global transaction is in
progress against other databases, the CL command is
processed, but the global transaction is not affected.
Adabas Transaction Manager acts to end a distributed transaction across
all affected databases, with full transaction integrity, as soon as the
application session issues an ET or
BT command. Nevertheless, Adabas Transaction Manager
expects an application to be well-formed in the way it pursues transaction
outcome. Specifically, where multiple databases are modified, the application
is expected to pursue transaction outcome on all the changed databases, in
series. For example, if two databases are modified, Adabas Transaction Manager
expects to see two ET commands (one to each
database) to cause a positive transaction outcome; or two
BT commands (one to each database) for a negative
transaction outcome. If an application tries to issue a transactional command
without having issued the expected ET/BT commands to
all databases changed by the previous transaction, response code 240, sub-code
496 will be returned. This well-formed behaviour is significant to ensure the
application is able to run successfully in the case where Adabas Transaction
Manager is unable to operate temporarily or permanently due to some sort of
planned or unplanned outage.
Triggers can execute global transactions under the control of Adabas Transaction Manager. Refer to the documentation for the Adabas System Coordinator to find out how to configure the System Coordinator for a trigger environment.
If your application causes participating triggers to be fired, and you require a global transaction to include changes made by both the application program and the participating trigger, you must ensure that the very first change command (store, delete or update) of the global transaction is issued by the application program, not by the trigger.
Operation of an ATM transaction manager has been streamlined by eliminating the Global User Queue. The Transaction Manager focuses on active transactions, without the need to maintain a list of active clients.
Sometimes a transaction is terminated in such a way that the owner should receive a non-zero response code, but in circumstances in which it is not possible to return a response code; for example, the transaction manager backs the transaction out because its global transaction time limit has been exceeded. When this happens, the manager stores details of the pending response code in a new list, and returns it to the client at the first possible opportunity. Pending response codes can be listed and displayed using ATM’s Online Services application.
As in previous releases, there is a requirement to use an unmodified ADALNK in certain areas. With Version 8.1 this restriction has been reduced to unmodified ADALNK being needed only when running standalone Adabas utility jobs.
The default value for the ATM ON/OFF (Activate
ATM Processing) parameter has been changed from ON to OFF.
For more information, see ATM Parameters.
The maximum length of this parameter has been reduced from 3 to 2 characters, to allow for a greater number of client IDs. A three-character value will be accepted, but only the first two characters will be used.
For more information, see ATM Parameters.
Previous versions of Adabas Transaction Manager provided a global
non-activity timeout feature, to prevent dormant or lost client sessions from
retaining resources. The Adabas System Coordinator now provides such a facility
in an integrated manner, which is effective not only for Adabas Transaction
Manager, but also for other products which use the System Coordinator.
Therefore, from Version 8.1, ATM’s non-activity timeout facility has been
removed, and the ADARUN parameter TMGTNA is no longer
effective.
Previous versions of Adabas Transaction Manager used the runtime
parameter TMDYNTCIDS to limit the number of temporary,
dynamic Client Identifiers that a transaction manager could assign, and there
was a theoretical maximum of 64k. From Version 8.1, a transaction manager will
be able to assign up to 16,777,215 Client Identifiers. The ADARUN parameter
TMDYNTCIDS is therefore no longer effective.
With previous versions of Adabas Transaction Manager, a client control (job parameter) was used to identify the Adabas SVC for which ATM was required to provide transaction coordination. ATM would not interfere in any way with commands that were issued under a different Adabas SVC.
From Version 8.1, the client session’s Adabas SVC will be taken to be the SVC used by the Adabas link module.
The following error messages have been recently added or modified:
ATM messages: ATM034, ATM065, ATM092, ATM104, ATM122, ATM129
ATM Error Codes: 512,-517, 520, 524, 528
Subcodes for RC 9: 73, 97
Please refer to the ATM Messages for more information.
The ADARUN DTP parameter indicates whether or
not a database is capable of full participation in Distributed Transaction
Processing. Normally, when a database is started with
DTP=RM, it is immediately “signed on” to the Transaction
Manager for Distribute Transaction Processing. This means that the Transaction
Manager uses two-phase commit protocol to guarantee the integrity of
distributed transactions that modify this database.
There might be occasions, however, when the process of “signing on” for
DTP cannot be completed immediately, perhaps because of a planned or unplanned
outage of another component that is itself going through startup processing at
the time. During this transient period, Adabas Transaction Manager ensures
uninterrupted operation by treating databases that have not signed on for DTP
as if they were running wth DTP=NO. In these
circumstances, a commit operation is applied to all “unsigned on” databases in
turn immediately after DTP commit has been completed for all databases in the
transaction that are signed on, by means of serial
ET commands. At some later point this transient “not
signed on” period ends because the sign-on eventually succeeds, Adabas
Transaction Manager recognizes the change, and from that point the database is
treated as a DTP=RM database.
In a multi-system environment, it is possible to run completely
separate System Coordinator groups in the separate systems. For example, a
“production” group might run on system A, while a “test” group might run on
system B. The databases used by the “production” environment would be executing
outside the scope of the “test” System Coordinator group; that is, they would
be “external” to the group. If an application in the “test” environment
modifies a database in the “production” environment, Adabas Transaction Manager
recognizes that the database is executing outside the scope of the current
System Coordinator group. The client control
Application
controls ET data, can be used to determine the extent to
which ATM should provide transaction coordination for changes on such
“external” databases. By default, full coordination is provided for external
databases running with DTP=RM, and serial
ET/BT commands are used to provide co-ordination of
DTP=NO databases.
This feature can be exploited to make it easier to upgrade multi-system environments. See the section Easier Upgrade Process for Multi-System Environments.
Historically it has been difficult to perform software upgrades in
sites that deploy Adabas Transaction Manager across several inter-connected
systems. A new client runtime control,
Coordinate
Adabas DBs outside the group, is provided, that makes it
possible to upgrade one system at a time. The upgrade can be achieved by
creating a new System Coordinator group in one system, replacing the previous
software levels. The new client control can then be used to instruct ATM to
provide DTP coordination across the System Coordinator groups.
If an application issues an ET command with
ET data, on a session for which no valid ETID has
been provided, ATM, like Adabas, will now not store the
ET data persistently. This is true, regardless of
the setting of the TMETDATA parameter. Instead, it will
proceed as follows:
If the target database of the ET command
is being managed using the two-phase protocol, the
ET data will be ignored, but ATM will not draw
attention to this fact by means of a non-zero response code;
Otherwise, the ET data will be passed to
the database which the application specified on the
ET command, and to no other database.
In other respects the Transaction Manager will process the
ET command as normal.
A new client runtime control,
Application
controls ET data is provided. It can be used to override
the effect of the transaction manager’s TMETDATA
parameter, for the client session. If this control is set to YES, the
ET data provided on an ET
or CL command will be stored only in the database to
which the command was issued.
A new client runtime control,
Coordinate
Adabas DBs outside the group is provided, to allow the
administrator to determine, by client session, the extent to which ATM should
provide transaction coordination with databases executing outside the scope of
the client’s COR group.
By default, full coordination is provided for external databases
running with DTP=RM, and serial
ET/BT commands are used to provide co-ordination of
DTP=NO databases. The administrator can specify that ATM
should prevent transactional usage of external non-RMs, or of all external
databases, by giving response code 240, subcode 544.
