The COMTI programming model follows the COM programming model and the mainframe Transaction Program (TP) programming model by providing a bridge between the two. One result of this bridge is that COMTI does not have APIs that you have to program. Although COMTI uses existing mainframe programming models, some changes may be needed to an existing mainframe TP to fit the models supported by COMTI. For example, a TP does not necessarily expect a simple request-reply response sequence. With one exception, COMTI imposes that model on the mainframe program. As another example, a CICS program may have terminal processing logic embedded in the same program with the business logic. This type of program must be restructured as separate programs.
On the distributed platform, the programming model is object-oriented. Application objects are instantiated and methods on those objects are invoked. Using COMTI, mainframe applications appear as COM Automation objects with callable methods. The model is a synchronous exchange of inputs and outputs, as shown in the following illustration.
On the mainframe platform, COMTI supports a variety of programming models, flows, and relationships as summarized in the following illustration.
On the mainframe platform, COMTI supports the following flows:
For each method invocation, COMTI converts and sends the input parameters to the TP. The mainframe TP executes, processes the input data (for instance, accessing or updating the database), and sends its response back to COMTI. COMTI receives the output parameters from the TP, converts them, and finally returns them to the invoking program.
The simple model is extended to include one or more consecutive sends followed by one or more consecutive receives.
In this case, the last input parameter of the method invocation can be a "variably sized" recordset. The input parameters are converted and sent, and then each row of the recordset is converted and sent to the mainframe TP. The mainframe TP executes, receives the input data and each row of the recordset, processes the data (perhaps doing database accesses and/or updates), and sends its response back to COMTI. COMTI receives any output parameters from the TP and converts them to return to the invoker. Then, each row of a variably sized recordset is received, if appropriate. The mainframe TP has no notion of a recordset; it is just receiving or sending tabular data. COMTI handles converting to and from the recordset.
When a COMTI component participates in an MTS transaction (for example, a DTC-coordinated two-phase commit exchange), COMTI uses LU 6.2 Sync Level 2.
Note COMTI will also support the use of Sync Level 2 with IMS when COMTI supports IMS 6.0.
DTC works with the COMTI run-time proxy and with the COMTI Resync Service to provide the necessary two-phase commit flows, as well as transaction log synchronization and recovery. Note that COMTI clients can remain completely uninvolved in transaction commit/rollback decisions, or they may elect to participate. COMTI clients are never aware of, nor involved in, transaction recovery.
If a client chooses to remain uninvolved in transaction control, the COMTI run-time proxy will automatically commit transactions that have no run-time failures and will abort those that do fail. The COMTI run-time proxy, however, cannot detect or react to application-specific conditions that may require a transaction to abort. These special conditions must be handled by the application in an MTS component by simply executing the SetAbort method against the transaction's Context Object. For example, an out-of-cash situation in an automated teller machine requires a transaction rollback to reset the original account balance and a notification message to schedule machine maintenance.
The difference between this flow and the transactional single send-and-receive case is that multiple sends and/or multiple receives may occur between COMTI and the mainframe. This flow also supports variably-sized data where the number and size of the actual records returned or sent can vary at run time.
Note With Transactional Multiple Send and Receive, the CICS LINK programming model cannot be used because it supports only fixed-size data areas.