Skip to main content

5 IMS OTMA Enhancements You Don’t Want to Miss

This article covers several OTMA enhancements including performance optimizations, added flexibility for customizations and additional helpful features.

White number 5 separated with storage sections against a wall.

IMS Open Transaction Manager Access (OTMA) is a high-performance, transaction-based, connectionless client/server protocol that allows z/OS applications to access IMS applications. In this article, we cover several OTMA enhancements including performance optimizations, added flexibility for customizations and additional helpful features that allow IMS OTMA to stay true to its high-performance heritage.  

Avoiding Transaction Bottlenecks in a Shared-Queue Environment

Currently, in an IMS shared-queue environment, OTMA can quickly process transactions by routing a transaction from a front-end IMS to one of the back-end IMS systems for processing. When a response is ready, the back-end IMS will route that response back to the front-end IMS for the client. However, you can get a delay in the processing of the response messages during heavy workloads when the front-end IMS must process a lot of response messages. 

So, how can you avoid those bottlenecks?

The following OTMA enhancement introduces a new IMS task under a new task control block (TCB) to handle responses from back-end IMS systems to avoid this bottleneck and improve the transaction throughput.  
  • IMS 14 APAR PI99661
  • IMS 15 APAR PH02371

More Efficient ACEE Lookup for Mobile Users

Many IMS customers have a large mobile banking client base, which in turn means a large number of System Authorization Facility (SAF) user IDs. OTMA creates a new SAF user ID block in IMS and caches an associated SAF Accessor Environment Element (ACEE) for each new client. When there are many cached ACEEs in IMS, searching for an ACEE can increase CPU utilization.

The following OTMA enhancement changes the hashing logic by calculating the number of hash entries based on the user-specified SAF user ID value (ACEEUSR=) in the DFSYDTx PROCLIB member. This will reduce the number of entries being searched for a given hash entry and, consequently, decrease CPU utilization.
  • IMS 14 APAR PH00405
  • IMS 15 APAR PH07823

Flexible OTMA Tpipe Flood Control  

System outages can be detrimental, so it is vital to prevent system outages whenever possible. A known IMS system outage trigger is when transaction pipes (tpipes) flood. Currently, IMS warns users when 80% of the tpipe threshold is reached and rejects new transactions if 100% of the tpipe threshold is reached. However, the difference between 80% and 100% can be huge to customers who have thousands of tpipes in the system. 

The following OTMA enhancement removes the static 80% threshold so that you can easily specify a tpipe flood warning level (MAXTPWN=) in the DFSYDTx member from 50% to 95% with a default of 80%, and the tpipe flood relief level (MAXTPRL=) can be set from 50% to 95% with a default of 50%.
  • IMS 14 APAR PI99661
  • IMS 15 APAR PH02371

Tpipe Cleanup for Improved Throughput  

With the growth of mobile banking, thousands of OTMA tpipe for mobile transactions can be easily created in an IMS system. Each tpipe consumes at least 9 KB of IMS private storage, so over time, tpipe storage consumption can be sizable if proper cleanup procedures are not implemented. 

Tpipe storage can be freed if the tpipe has been idle for three consecutive system checkpoints. The checkpoint frequency is configurable, so you can increase the system checkpoint frequency for quicker cleanup. However, when this was tested, we noticed IMS spent lots of unwanted CPU cycles waiting for the completion of the tpipe cleanup and this affected transaction throughput.

The following OTMA enhancement enhances the serialization method of tpipe cleanup (reduces CPU cycles) and expands the hash table for locating tpipes. This results in major throughput improvements when IMS is running with high checkpoint frequencies and a massive number of tpipes.  
  • IMS 14 APAR PI99661
  • IMS 15 APAR PH02371   

Automatic Tracing for OTMA Transactions 

IMS OTMA has tpipe trace and table trace to track the transaction processing flow and status for troubleshooting, but by default, these features are turned off to avoid any performance impacts. When an OTMA issue is reported in the production line without these traces turned on, it is difficult to identify the root cause of a problem. 

The following OTMA enhancement introduces a new 32-byte nibble trace without impact. This new nibble trace, included in OTMA control blocks DFSYTIB, DFSYQAB and DFSYPIP, is always on to store the last 32 events of transaction processing status so that the recent OTMA transaction status can be easily identified and analyzed from an IMS dump.   
  • IMS 14 APAR PH10267
  • IMS 15 APAR PH10272
So install these APARs and take advantage of these new OTMA enhancements!
IBM Systems Webinar Icon

View upcoming and on-demand (IBM Z, IBM i, AIX, Power Systems) webinars.
Register now →