It is possible for an application to use an ETID for some database sessions, and concurrently to use other database sessions with no ETID. It is also possible for a client to use different ETIDs concurrently in different database sessions; however, Software AG strongly recommends that the same ETID is used for all databases that are used.
ET data is a special type of application
data. Changes to ET data take effect if and only if
a transaction completes successfully (is applied) with an
ET command (or CL).
Adabas Transaction Manager supports the use of
ET data with distributed transactions. If no new
ET data is used when the transaction is applied the
existing ET data remains unchanged, similar to how
standard Adabas handles ET data.
When an application issues an ET command
with ET data when no valid ETID has been provided,
Adabas Transaction Manager, like Adabas will not store the
ET data persistently. 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 Adabas Transaction
Manager 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.
When ET data is stored by an
ET or CL command for a
session using a valid ETID, its location is determined by the setting of the
client runtime control
ET data
storage location.
Note:
It is important that the same mechanism and store location is
used from one execution to the next otherwise ET
data will be lost. For example, if the application is configured to store
ET data in a database one day, and then changed to
use the TM recovery file the next, then it is likely
that ET data will be lost during this changeover –
unless special action has taken place to make sure the
ET data has been moved from the old store to the new
store.
Software AG strongly recommends applications should use the same
ETID in all databases for one client. When this recommendation is followed,
there can be no confusion about which ETID should be used when
ET data is to be stored or read.
For information about:
controlling the storage of ET data,
see the ET data storage
location client runtime control and
ET data storage
location TM control.
establishing the current ET data of
your applications in the TM recovery file before
they execute, see ET Data
Management.
When a client session is temporarily running in continuous operation
mode, ET data requests are directed to the database
specified in the Adabas control block even though the client is configured to
use the TM recovery file. This could result in
incorrect ET data being read.
ET data being written to a database
from which Adabas Transaction Manager is not able to retrieve it.
incorrect results when Adabas Transaction Manager attempts to recover a transaction on behalf of the user
For these reasons, it is strongly recommended that the client
control Continuous
operation mode is set to NO when
ET data is configured to be maintained in the TM
recovery file.
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.
Do not use the TM option for defining the storage location of ET data for clients operating in a multi system dynamic transaction routing environment.
Refer to the TM control ET data storage location and Client Runtime Control ET data storage location for more information on defining the storage location of ET data.