MAINFRAME > Administrator > IMS

IMS 13 Enhancements Achieve Performance Benchmark


In August of 2013, IBM's IMS achieved an unprecedented performance benchmark: an IMS 13 system processed more than 100,000 Fast Path transactions per second at a sustained rate. Many different performance enhancements in IMS 13 contributed to this achievement, not the least of which were the performance enhancements to the IMS Open Transaction Manager Access (OTMA) component.

OTMA enables other subsystems that are running in the mainframe environment to submit transactions to IMS through a z/OS cross system coupling facility (XCF) interface. Some of the z/OS subsystems that rely on OTMA for high-performance communication across z/OS address spaces include IMS Connect, the TCP/IP gateway to IMS, DB2 for z/OS using the DSNAIMS stored procedure, WebSphere MQ and a variety of z/OS subsystems that are provided by IBM business partners (see Figure 1).

IMS Version 13 enhanced OTMA in many different ways, not just for performance, including:

  • Earlier client notification of IMS terminations
  • Enhancements to OTMA's global flood control
  • The ability to display the number of messages on IMS Connect hold queues
  • An enhanced callable interface for asynchronous messages
  • Improved routing of write to operator messages for easier operations and automation
  • The identification of OTMA client types
  • Enhancements to the OTMA destination descriptor for WebSphere MQSeries
  • The ability to override OTMA descriptors with OTMA exit routines
  • Support for synchronous program-to-program switches by using the DL/I ICAL call

While all of these enhancements are worthy of discussion, this article focuses on the OTMA performance enhancements that contributed IMS 13's ability to process more than 100,000 transactions per second.

z/OS Storage Call Elimination for OTMA

OTMA receives messages from OTMA clients via a z/OS cross-system coupling facility (XCF) and an IMS XCF message exit routine. The processing of this exit routine directly impacts OTMA's message throughput.

Before IMS 13, the exit routine used STORAGE OBTAIN calls to get working storage. Issuing a STORAGE OBTAIN call is expensive to do for every input message and requires a LOCAL MVS system lock, which causes contention when XCF invokes the exit routine in parallel for higher message rates.

IMS 13 improves the processing of the IMS XCF exit routine by replacing the expensive STORAGE OBTAIN calls with MVS's more efficient cell pool services (CPOOL macro).

After input messages are received from the IMS XCF exit routine, they are passed to IMS for processing using asynchronous work element (AWE) blocks. Before IMS 13, the AWEs were obtained by using the STORAGE OBTAIN call. In IMS 13, IMS conditionally uses IMS pool services (DFSBCB) calls to obtain AWEs and only uses STORAGE OBTAIN calls when no blocks are immediately available. The replacement of these STORAGE calls in each of these cases dramatically reduces the processing costs for OTMA input messages.

Enhanced Control Block Chaining for Transactions

Prior to IMS 13, high volumes of OTMA transactions incurred significant overhead to process the internal control blocks (transaction instance blocks or TIBs) that are associated with each transaction. During processing, active TIBs were moved to a free chain and then an available chain when they became inactive. This multiple chain manipulation required excessive latching and processing. In IMS 13, the free chain is eliminated and the TIBs are placed directly to the bottom of the available chain. When a new TIB is required, it is taken from the top of the available chain and a check is made to ensure the TIB is inactive. If a TIB is not inactive, a new TIB is created.

Efficient Clearing of Output Buffers for Output Messages

IMS 13 further improves processing efficiency by changing how OTMA uses buffers. In the processing of input messages, OTMA obtains a buffer. Prior to IMS 13, OTMA always cleared the buffer unconditionally by using a move character long (MVCL) assembler instruction. Using the MVCL instruction to zero these large buffers was expensive when, in most cases, the buffers were initialized when used. This extra overhead was removed for all input messages except SyncLevel=SyncPoint messages.

More Control Block Hashing for Quick Access

Prior to IMS 13, the TIB control blocks related to a given OTMA client connection (transaction pipe, or tpipe) were chained on a single linked list anchored off of the tpipe control block. In IMS 13, the chaining of the OTMA TIB control blocks was changed from a single linked list to a hash table.

Fast Path Transaction Syncpoint Enhancement

Prior to IMS 13, when an OTMA Fast Path transaction was processed in an IMS Fast Path (IFP) dependent region, the IMS logger function performed a check write after a write of a syncpoint record for the transaction. During the check write, the IFP region had to wait for the logger function to write the targeted log record, which greatly reduced the rate at which the IFP region could process transactions.

In IMS 13, IMS no longer performs the check write for OTMA transactions in an IFP region. Instead, a new ITASK running under a new Fast Path TCB—TCB type FP2—makes sure that the OTMA client is informed properly when the syncpoint is ended. This enhancement allows IFP regions to process the next transaction immediately without waiting for the log write to complete.

Conclusion

The performance enhancements to OTMA in IMS 13 are a key contributor to the achievement of the 100,000 transactions per second benchmark. The 100,000 benchmark and the investment required to reach are clear evidence that even after over 45 years, IBM is committed to the IMS customers and the continued to improvement of IMS.

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 bpj@us.ibm.com.

Dave Cameron is a senior software engineer for IMS development. He can be contacted at daveac@ca.ibm.com.

Jack Yuan is a senior software engineer for IMS development. He can be contacted at jackyuan@us.ibm.com



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.


comments powered by Disqus

Advertisement

Advertisement

2018 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