EXEC CICS or CPI Communications?

Some CICS® products give you a choice of two application programming interfaces (APIs) for coding your DTP conversations on APPC sessions. The first, the CICS API, is the end-user interface of the CICS implementation of the APPC architecture. It consists of EXEC CICS commands and can be used with all CICS-supported languages. The second, Common Programming Interface for Communications (CPI Communications) is the communications interface defined by Systems Application Architecture® (SAA). It consists of a set of defined verbs, in the form of program calls, which are adapted for the language being used.

Table 10 compares the two methods to help you to decide which API to use for a particular application.

Table 10. CICS API compared with CPI Communications
CICS API CPI Communications
Portability between different members of the CICS family. Portability between systems that support SAA.
Synchronization levels 0, 1, and 2 supported. Synchronization levels 0, 1, and 2 supported, except for transaction routing, for which only synchronization levels 0 and 1 are supported.
Program initialization parameter (PIP) data supported (CICS on System/390® and CICS on Open Systems only). PIP data not supported.
Only a few conversation characteristics are programmable. The rest are defined by resource definition. Most conversation characteristics can be changed dynamically by the transaction program.
Can be used on the principal facility to a transaction started by ATI. Cannot be used on the principal facility to a transaction started by ATI.
Mapped conversations (see note 3) can be programmed in any of the languages supported by CICS. Mapped conversations can be programmed in any of the languages supported by CICS.
Basic conversations (see note 3) can be programmed only in assembler language or C, and only on a CICS on System/390 system. Basic conversations can be programmed in any of the languages supported by CICS, but only on a CICS on System/390 system.

Additional notes on the two APIs

  1. You can mix CPI Communications calls and EXEC CICS commands in the same transaction, but not on the same side of the same conversation. In other words, each half-session can use only one application interface.
  2. One partner in a conversation can use CPI Communications calls while the other uses the CICS API. In other words, the half-sessions at either end of the same conversation can use different application interfaces.

    To correctly coordinate a conversation that is using a different API in each half-session, the programmers must know the details of how both APIs map to the APPC architecture.

  3. Both interfaces, CICS API and CPI Communications, support APPC mapped conversations, in which the systems provide and interpret protocol headers, and the application programs deal only with user data. In an APPC basic conversation, the sending application must prefix the data with the header required by the communications protocol. The receiving application must interpret this header.
  4. CICS/VSE 2.3 does not support the CPI Communications API.

Related concepts
Why use distributed transaction programming?
Conversations
Related reference
CICS product communication support
[[ Contents Previous Page | Next Page Index ]]