MAINFRAME > Administrator > IMS

Making a Better Connection

Latest Release Simplifies IMS-to-IMS Communications via a TCP/IP Network

Editor’s note: This is the first of two articles on IMS-to-IMS communication via TCP/IP. Part two focuses on performance testing and tips to optimize performance.

IBM Information Management System (IMS) version 12 introduces support for TCP/IP communications between two geographically remote IMSs. Through the IMS integrated TCP/IP server, IMS Connect, one IMS can send messages to another geographically remote IMS over a TCP/IP network.

Two connection methods support IMS-to-IMS TCP/IP communication: open transaction manager access (OTMA) and multiple systems coupling (MSC). However, this article focuses on OTMA, which provides one-way, asynchronous TCP/IP support between two IMSs.

Figure 1 illustrates a configuration in which an IMS in Los Angeles sends OTMA transaction messages to another in New York. Prior to V12, connecting two systems in this manner would typically require a third, non-IMS gateway application to relay the OTMA messages from one IMS Connect instance to the other.

How it Works

An application program running in an IMS-dependent region initiates the sending of an OTMA message to a remote IMS by issuing IMS DL/I API calls. The application program issues a CHNG call to indicate where to retrieve the destination routing information and then an ISRT call to an alternate program communication block (ALTPCB) to send the message.

The destination routing information can be defined in one of two ways:

  • By an OTMA destination descriptor, which is specified by name in the destination name field of the CHNG call, or
  • By coding it in an OTMA user data formatting exit routine (DFSYDRU0), which is called only if an OTMA destination descriptor isn’t used

In either case, the destination routing information is stored in the message’s OTMA header. The destination routing information includes the name of the local IMS Connect that’s providing the TCP/IP connection services for the sending IMS as well as the name of the remote IMS.

After the ISRT ALTPCB call is issued and the destination routing information retrieved, IMS passes the message to the local IMS Connect, which sends the message to the remote IMS Connect instance by using a send-only-with-acknowledgement protocol. This protocol indicates that the sending application waits for a positive or negative acknowledgement—an ACK or NAK—before sending the next transaction message, but doesn’t expect a reply to the transaction. Any transaction reply or unsolicited output message is queued to an asynchronous hold queue in the receiving IMS for later retrieval.

When the remote IMS Connect instance receives the message, it passes that message to the remote IMS, which returns a positive acknowledgement (ACK) message to IMS Connect only after the transaction message is successfully queued for processing in the remote IMS. The message is routed back to the local IMS, which is waiting for the ACK.

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

Yu Ying Wang is an advisory software engineer for IMS performance test. She can be contacted at

comments powered by Disqus



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