Only DBMSs that support the XA interface, for example ORACLE, can be controlled by OpenTP1 transaction processing. When a DBMS supports the XA interface, updates are possible using the commit and rollback operations of OpenTP1 transaction processing. In such transaction processing, you can use the functions that control OpenTP1 synchronization points (such as the functions dc_trn_begin(), dc_trn_unchained_commit(), tx_begin(), or tx_commit()). Facilities provided by a DBMS for controlling transactions cannot be used.

DBMSs that can be controlled through OpenTP1 transaction processing are limited to products supporting the XA interface.

In UAPs that access multiple databases, OpenTP1 allows updates while protecting the consistency of the multiple databases. The following OpenTP1 resource managers support the XA interface:

• TP1/FS/Direct Access (DAM file service)
• TP1/FS/Table Access (TAM file service)
• ISAM, ISAM/B (ISAM file service)
• TP1/Message Control (Message exchange facility (MCF))
• TP1/Message Queue (Message Queuing)

Thus, a UAP can process OpenTP1 transactions when accessing DBMSs that conform to the XA interface in the same way it does when it accesses the OpenTP1 resource manager. Even when some failure cause an abnormal termination of a UAP or when OpenTP1 is restarted, OpenTP1 performs a transaction determination (i.e., decides whether to perform a commit or rollback) for both the DBMS and the OpenTP1 resource manager.

A DBMS that does not support the XA interface can be accessed, but cannot be synchronized with OpenTP1 transactions.

When a DBMS does not work with OpenTP1 via the XA interface, OpenTP1 cannot order a transaction determination to the DBMS in certain situations: such as when a UAP abnormally terminates during access to a database, or when OpenTP1 requires a rerun during access to a database. In such situations, you must recover the transactions using the DBMS facilities.