You are currently on IBM Systems Media’s archival website. Click here to view our new website.

MAINFRAME > Administrator > IMS

IMS 13 Delivers Synchronous Program-to-Program Communication

Announced in October, IMS version 13 includes a wide variety of enhancements designed to:

  • Reduce the total cost of ownership
  • Improve open access and integration with other products
  • Make IMS more adaptable and flexible to business growth and modernization requirements, and
  • Improve its general performance, efficiency, availability and resilience

One key feature of IMS 13 can facilitate the modernization of your application infrastructure and reduce unnecessary network traffic. It does this by supporting synchronous communication between IMS application programs that run in separate IMS-dependent regions. In this article, we’ll examine this program-to-program communication feature and cover some tips for using it.

Program-to-Program Communication

When an IMS application processing a transaction in one IMS-dependent region sends a transaction message to a separate application running in another region in IMS, this type of program-to-program communication is referred to as a program switch.

Prior to IMS 13, for an application program to perform a program switch, it had to issue two calls through the IMS Data Language/I (DL/I) interface:

  1. A CHNG call to an alternate program communication block (PCB) that identified the destination, and
  2. An ISRT call to send the message

If the target program generated a response message, that message was sent back asynchronously to a different application program.

To meet the needs of customers whose application architecture requires a faster, more efficient method of program-to-program communication, IMS 13 enables programs to perform a program switch with a single DL/I call and receive the response synchronously, all in a single unit-of-work (UOW). This new enhancement is called a “synchronous program switch.”

Synchronous Program Switch

The synchronous program switch support is provided by the ICAL DL/I call. Prior to IMS 13, the ICAL call was used only to send synchronous callout requests across a TCP/IP network for data or services from other mainframe or distributed applications running externally to IMS. The IMS programs issue the ICAL call and process the external response synchronously, all in the same UOW.

IMS 13 applies the ICAL DL/I synchronous callout model to program-to-program communication between IMS-dependent regions. Now, if an IMS application needs to make a program-to-program switch to a second IMS program—instead of issuing the CHNG and ISRT calls—it issues a single ICAL call. The destination application can be in the same IMS, as shown in Figure 1, in a shared-queue, back-end IMS running in the same z/OS sysplex, or in a remote IMS connected by a Multiple Systems Coupling (MSC) link. The application that issues the call then waits to receive the synchronous response for processing in the same UOW.

Figure 1: Synchronous Program-to-Program Communication

The ICAL format for a synchronous callout request and a synchronous program switch request are the same:


The application interface block (AIB) is where the options, or sub-functions, of the ICAL call are specified, along with the name of an Open Transaction Manager Access (OTMA) destination descriptor, any timeout value, the length of the data, and more. When sending a synchronous program switch message, the sub-function for the request is SENDRECV.

The request area is for the message data. For a synchronous program switch message, the data must start with a four-byte field that defines the length of the data in the standard IMS LLZZ format, followed by an eight-byte transaction code. For multi-segment transactions, which are defined to IMS with the MULTSEG keyword, the entire length of all segments of the transaction must fit into the request area of the ICAL call. The LLZZ format is required for each segment. The transaction code is only required in the first segment.

The response data is returned to the calling application in the response area of the ICAL call. This area also must begin with an LLZZ field that defines the length of the response data segment.

If a segment is too long to fit in the response area, the data is truncated in the synchronous response, but also saved by IMS in its entirety for later asynchronous retrieval. The later retrieval is also performed by issuing the ICAL call, but by specifying the new RECEIVE sub-function instead of the SENDRECV sub-function. The format of the ICAL with the RECEIVE sub-function is as follows:


Ben Johnson is an IBM information developer. He has been writing about IMS since 2003, focusing on both IMS database administration and IMS communications and connections, with a particular interest in OTMA and IMS Connect. He can be contacted at

Dave Cameron is a senior software engineer for IMS development. He can be contacted at

Jack Yuan is a senior software engineer for IMS development. He can be contacted at



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Bringing IMS and SOA Together With IMS Connect

New requirements for IMS Connect functionality could make implementing an SOA environment with IMS easier and more flexible.

Celebrating 40 Successful Years

IMS version 10 supports synchronous and asynchronous callout

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters