Extending Transactions to the Mainframe with COMTI

   

With COMTI, your application can access transactions running on a mainframe. Because COMTI is a Microsoft Transaction Server (MTS) component, it takes advantage of specific MTS features, including multiple threading, and object management for improved performance. COMTI supports both CICS and IMS transactions.

Windows-based distributed applications that use Microsoft Transaction Server (MTS) can include CICS applications in MTS-coordinated transactions.

COMTI integrates seamlessly with MTS so that:

• If you are a Windows developer, you can describe, execute, and administer special MTS objects that access CICS or IMS Transaction Programs (TPs).
• If you are a mainframe developer, you can make mainframe TPs available to distributed applications.
• If you are an MTS component designer, you can include mainframe applications within the scope of MTS, two-phase commit transactions.

MTS developers can decide which parts of the application require a transaction and which parts do not. COMTI extends this choice to the mainframe, as well, by handling both calls that require transactions and calls that do not. For Windows-based applications that require full integration between two-phase commit and mainframe-based Sync Level 2 transactions, COMTI provides all the necessary functionality. COMTI does this without requiring you to change the client application, without placing executable code on the mainframe, and with little or no change to the mainframe TPs. The client application does not need to distinguish between the COMTI component and any other MTS component reference.

The following diagram shows an example of how a Windows-based client application uses the Distributed Transaction Coordinator (DTC) to handle a distributed transaction involving SQL Server and a CICS Transaction Program. The DTC is the part of MTS that coordinates two-phase commit transactions.

MTS components, and thus COMTI components, have four possible transaction properties that are set in the component builder at the time you build the component. These are listed in the following table.

Transaction properties	Expected use
Requires transaction	The mainframe TP must be transactional and support Sync Level 2.
Requires new transaction	The mainframe TP must be transactional and support Sync Level 2.
Supports transactions	The mainframe TP must support both Sync Level 0 and Sync Level 2 requests and handle the transaction semantics.
Does not support transactions	This choice is required for IMS TPs and for any CICS non-link TPs that support only Sync Level 0.

If a COMTI component is invoked within the scope of an MTS transaction, COMTI will establish a Sync Level 2 conversation with CICS (otherwise, Sync Level 0 is used). This is transparent to the client of the COMTI component. If the mainframe TP is a CICS Link program, the transactional nature of the conversation is transparent to the TP as well. This is because IBM's mirror transaction in CICS (CSMI) handles the Sync Level 2 protocol and the TP that it is linked to is unaware whether Sync Level 0 or Sync Level 2 is being used.

COMTI complies with the MTS programming model by calling SetComplete or SetAbort when it completes the operation of each method call from the client. If no errors were detected, COMTI calls SetComplete; otherwise, it calls SetAbort. COMTI also calls SetAbort if the mainframe TP indicates that the transaction should not commit by setting the DisableCommit flag in the error block meta-data returned. Note that an MTS application component that invokes methods on other MTS components — including COMTI-created components — can also call SetAbort if it has other information that causes it to cancel a transaction.

When the client's method call returns, the transaction program on the mainframe has performed some unit of work, but any changes to protected resources in CICS are not yet committed. COMTI uses new DTC interfaces to enlist the Sync Level 2 conversation on the DTC transaction. When DTC is ready to commit or abort the transaction, it communicates with COMTI to drive the appropriate two-phase commit flows on the LU 6.2 conversation. Again, all of the two-phase commit work is performed transparently by COMTI on the client's behalf.

Although the COMTI object may be deactivated when the method completes, the conversation must be maintained until the transaction commits or aborts. While a conversation is waiting to commit, it is divorced from the object with which it was associated. COMTI manages a pool of these "waiting" conversations and performs the required sync-level operations when the appropriate notifications are received from DTC. When possible, COMTI reuses these conversations to minimize overhead.

COMTI also provides a resynchronization service, implementing the "Exchange Log Names" and "Compare States" functions of an SNA Transaction Manager. COMTI allows both DTC and CICS to initiate the recovery process as required during system startup or following a system or communication failure.

Note   All of the COMTI resync and two-phase commit flows are implemented in conformance with the SNA Sync Point Services Architecture Reference (IBM manual number SC31-8134-00).

Using SNA Server and MTS, developers can easily make mainframe programs available to COM-supported clients and their Internet applications. In addition, MTS component designers can easily include mainframe applications within the scope of two-phase commit transactions.

For More Information   For more information about using Microsoft Transaction Server, search online for "MTS Overview and Concepts" in MSDN Library Visual Studio 6.0.