MAINFRAME > Storage > Data Management

A Reliable Transaction Management System

IBM Information Management System Transaction Manager


Supporting rapid growth in business-critical online and mobile transactions is a central challenge in today’s digital economy. A highly available, fast and reliable transaction management system with sufficient storage capacity for processing high-volume transactions is essential for meeting rising demands across industries for online and mobile services.

In this article, we provide tips and best practices for running different types of transactions in IBM Information Management System Transaction Manager (IMS TM). These best practices will help you protect your IMS against storage exhaustion, ensure IMS remains highly responsive and highly available for high-volume online transaction processing and facilitate your organizations’ participation in the mobile economy.

Commit-then-send Transactions

During commit-then-send transactions, also called commit mode 0 transactions, IMS commits output transaction data to an Open Transaction Manager Access (OTMA) transaction pipe (tpipe) queue before sending a response to client applications. OTMA uses tpipes to maintain connections between IMS and client applications. After a transaction is complete, the tpipe used to process commit-then-send output data for a client—such as IMS Connect—can persist in IMS storage so it can be reused for subsequent transactions. With increasingly high volumes of transactions, IMS storage can quickly become filled with tpipes.

Here are some tips for minimizing the amount of IMS storage needed for tpipes associated with transactions processed through IMS Connect:

  • Reuse the client IDs of IMS Connect client applications. Because each client ID has an associated tpipe, having a pool of reusable client IDs limits the number of tpipes created in IMS. If no client ID is specified for the IMS Connect client application, the IMS Connect user message exit generates a client ID, which can potentially flood IMS with tpipes if many client IDs are generated.
  • Specify the purge function in the IMS Connect client application to purge commit-then-send output that can’t be returned to the client. By default, undeliverable output is queued to a tpipe. However, once a tpipe has queued output, the tpipe can’t be removed during IMS checkpoints, even if the output is undeliverable. By specifying the purge function in the transaction input, undeliverable output will be deleted from the tpipe, thereby allowing the tpipe to be removed during the IMS checkpoint. You can enable the purge function by specifying the IRM_F3_PURGE flag (X'04') in the IRM_F3 field on certain types of input messages from a client application. You can also perdiodically run a tool—such as IMS Queue Control Facility for z/OS—to delete obsolete queued output from tpipes, making tpipes eligible for cleanup at system checkpoints.
  • Specify an appropriate IMS checkpoint frequency. An idle tpipe is identified at the end of three consecutive system checkpoints, and then IMS determines if the idle tpipe can be deleted. More frequent system checkpoints might allow idle tpipes to be deleted more frequently. If an idle tpipe can’t be deleted after being idle for three consecutive system checkpoints, IMS will try to delete it at subsequent checkpoints. When you specify a checkpoint frequency, however, bear in mind that an increase in checkpoint frequency can increase processing overhead and slow down normal IMS processing.
  • Avoid specifying a very small ACK timeout value. IMS uses the ACK timeout value to scan all tpipes in the system. During IMS scans, tpipes are used and can’t be deleted. Having a small ACK timeout value would therefore reduce the efficiency with which tpipes are deleted.
  • Issue the /DISPLAY TMEMBER TPIPE QCNT, /DISPLAY TMEMBER QCNT or /DISPLAY TMEMBER TPIPE ALL QCNT command when needed in a shared queues environment. These commands display the message queue count for tpipes. If the queue count is zero, the commands reset a shared queues flag (the MUST_CHECKPOINT flag) so that one or more tpipes are eligible for cleanup.
  • Specify a tpipe limit (MAXTP) in the OTMA client descriptor. This enables IMS to stop creating a tpipe and reject input transactions once the tpipe limit is reached.
  • Use send-then-commit transactions for inquiry messages from IMS Connect. IMS Connect informs IMS to create a port tpipe for all send-then-commit transactions. This method reduces the number of tpipes created in IMS.

Conversational Transactions

A conversational transaction might hang if the OTMA client that initiated the conversation terminates without IMS detecting the termination. In this case, the storage used for the hung transaction—such as the storage for the transaction instance block associated with each message from the OTMA client and the scratchpad area used for conversational processing—isn’t released. If hung transactions aren’t terminated, the amount of storage wasted on them can become significant.

Use the following tips to run conversational transactions with less storage:

  • Issue the IMS type-2 command (QUERY OTMATI) to display information about one or more OTMA target members, tpipes or both. In the command output, use the MsgAge column to identify message age values large enough to indicate that the message is orphaned. Then, use the ConvID column to make note of the conversational ID that the orphaned message belongs to. After identifying the transaction instance and noting its conversational ID, issue the /EXIT CONV conv_id command to terminate the transaction and free the associated storage.
  • Use the IMS type-1 command /DISPLAY CONV to display the target member and tpipe name for a conversational transaction issued from an OTMA client in addition to the IMS conversation ID and status. If an orphaned conversion exists, issue the /EXIT CONV conv_id command to terminate the transaction and free the associated storage.
  • Specify a timeout value using the ENDCONV= parameter in the DFSOTMA descriptor in the DFSYDTx proclib member. The ENDCONV= value, which has a default value of 3,600 seconds, enables OTMA to periodically examine the existence of orphaned conversational transactions, and terminate those transactions. Terminating orphaned conversational transactions releases storage associated with those transactions.

Transactions With OTMA Security

In a distributed environment, each client ID may have an associated system authorization facility (SAF) user ID. An accessor environment element (ACEE) block for the client’s SAF user ID is created and cached in the IMS control region. For an IMS that supports a large volume of online and mobile services, the increasing number of online and mobile transactions can become problematic as IMS storage can be filled with cached ACEE blocks for thousands of distributed client IDs.

Here are some tips for minimizing the number of ACEE blocks generated for your online and mobile transactions:

  • Map multiple distributed client IDs to a generic SAF user ID. This reduces the number of ACEE blocks created for SAF user IDs.
  • Specify a lower ACEE aging value to expedite the ACEE cleanup process. You can specify a non-zero value to OAAV= parameter in the DataStore statement of IMS Connect configuration file or issue the IMS type-1 command /SECURE OTMA with the ACEEAGE parameter specified to define an ACEE aging value for OTMA clients. To see the total number of ACEEs that are cached for the IMS system and the ACEE aging value for each OTMA member, issue the /DISPLAY OTMA command.
  • Enable ACEE flood control. You can do this by specifying TOACEE=YES on the DFSOTMA descriptor of the DFSYDTx member. You can also use the ACEEUSR= parameter on the descriptor to define the number of SAF user IDs that are stored in ACEEs when ACEE flood control is enabled.

Additional Resources

To learn more about configuring your IMS environment to avoid flood conditions while ensuring your system remains highly available for high-volume online transaction processing, visit the IBM Knowledge Center for IMS.

You can also find more information in the Knowledge Center for IMS about the following enhancements, which you can use to minimize the amount of IMS storage needed for your IMS online transactions:

Emily Siu joined IBM China Development Lab as an information developer in 2010. She has worked on the information development for IBM Z products, including TPF and IMS.

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.

Finding the Perfect Fit

IBM System Storage Easy Tier tailors SSDs for your workloads

Encrypt and Protect

IBM Tivoli Key Lifecycle Manager solves security problems and meets new standards

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