COMTI supports three classes of mainframe transaction processing (TP), as shown in the following list.
With CICS LINK, the COMMAREA is a communication area of up to 32K containing all of the data that is passed to and from the mainframe program. Only the simple flow model is supported with CICS LINK (Non-Transactional Single Send and Receive). Therefore, variable length recordsets are not supported for this class of TP. Fixed-sized recordsets are supported.
For CICS LINK using DPL (Distributed Program Link) emulation, when a method is invoked, COMTI sends the TP name "CSMI" in the LU 6.2 data stream. "CSMI" (the CICS Mirror Transaction) gets control and does an EXEC CICS LINK to the requested CICS program (the name of this program is associated with the method name in the COMTI Component Builder), passing it the COMMAREA containing the input fields. When the CICS program is finished processing, it issues an EXEC CICS RETURN, returning the COMMAREA to "CSMI" with all output fields updated.
The CICS Mirror Transaction also handles any Sync Level 2 interactions with COMTI, and thus transparently provides the two-phase commit capability for programs in this class.
Existing CICS programs may already be structured this way. Instead of COMTI issuing the LU 6.2 request, another CICS TP might already issue an EXEC CICS LINK to run the CICS program in the preceding picture. In that case, both the existing CICS TP and the COMTI component can coexist and run the same CICS program.
With CICS non-LINK, a method invocation causes the TP to run. The TP must issue APPC (Advanced Program-to-Program Communications) or CPIC (Common Programming Interface for Communications) verbs to receive and send the input and output fields, respectively. The TP must also issue the appropriate verbs to implement Sync Level 2 and two-phase commit.
Existing CICS programs may already be structured this way. This is a more difficult programming model than CICS LINK (especially regarding two-phase commit), but can provide advantages if the output data is variably sized.
With IMS implicit, a method invocation causes a message to be sent to the IMS message queue. The TP is running in a message processing region and issues a Get Unique (GU) command to get the input parameters that were sent by COMTI. If there is an input unbounded recordset, the TP also makes one or more Get Next (GN) calls to get each row of the recordset that was sent. After the TP processes the inputs and makes any database calls, it makes one or more Insert (ISRT) calls to place the output parameters and possibly an output or return-value unbounded recordset into the message queue to be packaged and returned to the COMTI component.
Existing IMS programs are most likely structured this way. Existing 3270 applications typically send an LU 6.2 data stream and the fields are put into the IMS message queue as shown in the preceding diagram. For a COMTI component, the data stream is processed by MVS APPC and put into the queue. The processing by the IMS TP is the same. As in the case of CICS LINK, existing terminal programs can coexist with a new application with COMTI components that run the same IMS TP.