Modified IMS application programs

Modified IMS application programs use a DL/I GU call to get the incoming transaction. These modified IMS application programs also use DL/I ISRT calls to generate output messages to the same or different terminals, regardless of whether LU 6.2 is used.

A non-message-driven BMP is considered a modified standard IMS application program when it uses the explicit API. Unlike standard IMS application programs, modified IMS application programs use CPI Communications calls to allocate new conversations, and to send and receive data. IMS has no direct control of these CPI Communications conversations.

Modified IMS transactions are indistinguishable from standard IMS transactions until program execution. In fact, the same application program can be a standard IMS application on one execution, and a modified IMS application on a different execution. The distinction is simply whether the application program uses CPI Communications resources.

Modified IMS programs are scheduled by IMS TM, and the DL/I calls are processed by the DL/I language interface. The conversation, however, is maintained by APPC/MVS, and any failures that involve APPC/MVS are not backed out by IMS TM. The general format of a modified IMS application program is shown in the following code example.

Figure 1. General format of a modified DL/I application program
  • GU IOPCB
    • ALLOCATE
    • SEND
    • RECEIVE
    • DEALLOCATE
  • ISRT IOPCB
Restriction: The APPC conversation cannot span sync points. If the conversation is not deallocated before a sync point is reached, IMS causes the conversation to be terminated by issuing a clean TP call (ATBCMTP). A new APPC conversation can be allocated after each sync point.

When an APPC program enters an IMS transaction that executes on a remote IMS system, an LU 6.2 conversation is established between the APPC program and the local IMS system. The local IMS system is considered the partner LU of the LU 6.2 conversation. The transaction is then queued on the local IMS system's remote transaction queue. From this point on, the transaction goes through normal MSC processing. After the remote IMS system executes the transaction, the output is returned to the local IMS and is then delivered to the originating LU 6.2 program.

Related Reading:  For more information on failure recovery and modified DL/I application program design, see IMS Version 15.5 Application Programming APIs.