What’s New in IMS OTMA for Mobile Transactions

In today’s digital world, enterprise platforms must evolve to process large, complex mobile transactions at lightning speed. When mobile applications take a few extra seconds to process payment transactions, it induces anxiety and panic for users until they see the payment is processed successfully. Customers want to grow without degrading the transaction processing performance. Today, many mobile applications interact with IMS transactions using Open Transaction Manager Access (OTMA). Scalability and OTMA are intertwined; recent OTMA enhancements have focused on improving its performance and agility as transaction workloads surge.

Faster OTMA Output Message Processing

If the highway you're driving on has a traffic jam, your experience driving in the carpool lane will likely be superior. In OTMA, we’ve created a similar fast lane to process the acknowledgement messages (ACK or NAK) from clients, such as IMS Connect or IBM MQSeries.

After OTMA delivers a response message and waits for an ACK or NAK message from the client, an IMS dependent region or transaction pipe (tpipe) will be in the wait state. If there is any delay in handling these ACK or NAK messages, the resources allocated by the IMS dependent region or tpipe cannot be released. When IMS executes high volumes of OTMA transactions, processing the ACK or NAK messages as soon as possible becomes increasingly important.  
One OTMA enhancement, provided in IMS 14 APAR PI96088 or IMS 15 APAR PI96089, introduces a new IMS task (ITASK) under the OTMA member TCB for processing the ACK or NAK messages from the clients. This new ITASK allows ACK or NAK messages to be processed faster, especially when the member ITASK is busy working on other tasks. The enhancement also sets IMS Page (IPAGE) length to 32K in online environments for two storage pools—LSAV (IMS Dynamic SAP save sets) and LQMW (Local queue manager work area)—to minimize the number of IPAGEs to search when allocating storage for new OTMA ITASKs.  

Enhanced LUMP Storage Pool Defaults for OTMA Output Messages

For every OTMA CM0 IOPCB output message, OTMA requests two storage buffers from the extended private area (LUMP): a 38144-byte buffer for output work area and a 5120-byte buffer for the prefix work area. Because the IMS storage pool manager allocates the LUMP storage buffer from the smallest size pool that fits the request, storage is wasted when 38144 bytes are obtained from the oversize buffer (64K) and 5120 bytes are obtained from the 33024-byte buffer.  
Another OTMA enhancement, provided in IMS 14 APAR PH00202 or IMS 15 APAR PH01051, introduces the two new default LUMP storage pool buffer definitions, which efficiently optimizes storage for OTMA CM0 and CM1 output messages.
The default LUMP storage pool definitions generated by IMS with and without the APAR are listed in Figure 1 for comparison. Buffers 1 to 7 remained the same.

LUMP Buffer 8 Buffer 9 Buffer 10 Buffer 11
Size without APAR 33024 65536 N/A N/A
Size with APAR 5120 33024 38144 65536
Primary Allocation 8 4 8 4
Secondary Allocation 8 2 8 2
Obtain primary allocation? No No No No

Figure 1: Default LUMP storage pool definitions generated by IMS with and without the APAR

In addition, the APAR also enhances OTMA flood control by rejecting any new input messages and quickly releasing the storage allocated for the rejected input messages as soon as a flood condition is detected.  

Reduced LUMP Storage for OTMA CM0 IOPCB Output Messages

One of the IMS LUMP storage buffers allocated for every OTMA CM0 IOPCB output is a 38144-byte buffer (hence a new buffer size 38144 is introduced by APAR PH00202 or APAR PH01051), which is allocated without consideration of the actual size of output message.

An OTMA enhancement provided in IMS 14 APAR PI99729 or IMS 15 APAR PH00002 makes it possible to allocate a reduced LUMP storage buffer for CM0 IOPCB output. It does so by examining the actual size of output messages for the OTMA client and considering the possibility of message segmentation by queue manager and output data expansion by user exit DFSYIOE0 to come up with a reduced LUMP storage. Customers can further set the pool definitions by explicit specification of LUMP in DFSSPMxx PROCLIB member with the maximum size of output messages.

IMS Callout Enhancements

If an IMS application program running in a dependent region issues an IMS Synchronous Callout (ICAL), and there’s no TCP/IP client available to handle the callout (no outstanding Resume TPIPE request for callout), then the IMS application program must wait for the full timeout value. This affects IMS application performance. An OTMA enhancement provided in IMS 14 APAR PI81868 or IMS 15 APAR PI81869 will reject the ICAL call if there’s no outstanding Resume TPIPE call so that IMS application program doesn’t need to wait for timeout. If needed, customers can specify ICALRTP=NO, provided in IMS V14 APAR PH02884 or IMS 15 APAR PH03829, for the DFSOTMA descriptor so that the IMS application program issuing the ICAL call can wait for a Resume TPIPE call until the ICAL call gets timeout.

Enhanced Tpipe Cleanup

OTMA performs tpipe cleanup during system checkpoint time. An OTMA enhancement provided in IMS 14 APAR PI88304 or IMS 15 APAR PI88409 ensures that tpipe cleanup can be effectively performed when there are a high number of ACK timeout cases or after the /STOP TMEMBER TPIPE command is issued. Two new status terms—MCP and SYW—were added to the /DISPLAY TMEMBER TPIPE command to indicate that cleanup for some or all tpipes can’t be performed. When MCP is displayed, it means this tpipe is running in a shared queues environment and might have output messages on the global queue. Because of this, the tpipe can’t be freed. When SYW is displayed, it means there’s an ongoing tpipe scan operation which prevents all tpipes from being cleaned up.   

Faster Message Processing

Faster message processing is key in improving the overall performance of IMS Transaction Manager. With these new OTMA enhancements on faster message processing, storage buffer management, and tpipe flood reduction, IMS Transaction Manager supports rapidly scaling business-critical online and mobile transactions without compromising its hallmark performance.  

Rita Shih is an IMS quality analyst with IBM.

Swetha Sridharan is an offering manager for IMS. She can be reached at

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

comments powered by Disqus



2019 Solutions Edition

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


Your Input Needed: IBM Systems Media Reader Survey

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