You are currently on IBM Systems Media’s archival website. Click here to view our new website.

MAINFRAME > Administrator > IMS

Tips for Developing IMS Mobile Applications with Fewer IMS System Resources

In today's world, mobile apps have become very popular. Many of these apps deal with sending transactions to the IMS database to perform services, such as mobile payments, digital wallet services, trip booking, online purchases and Web banking. Each mobile transaction processed in IMS consumes system resources. Due to these mobile transactions, IMS could run out of system resources, resulting in a crash. This article provides tips to consume fewer IMS system resources for the mobile apps sending transactions to IMS via IMS Connect.

Mobile apps can submit a send-then-commit (CM1) transaction or commit-then-send (CM0) transaction to IMS via IMS Connect. IMS will allocate a transaction instance block (TIB) when a CM1 or CM0 transaction is received. An IMS TIB resource is primarily used for input and output processing for a CM1 transaction. Once an IMS output is delivered to IMS Connect for mobile apps, the TIB resource in IMS will be released. If the output is not sent due to a long wait in IMS processing, the TIB resource can stay allocated for a long period of time. For a CM0 mobile transaction, once the input is accepted by IMS, the TIB resources will be released. However, each CM0 mobile transaction with a new client ID will allocate an IMS transaction pipe (TPIPE) control block. IMS can be flooded with lots of TIB and TPIPE resources. Tips to avoid creating these IMS system resources for mobile apps are as follows.

Using Connection Pooling to Manage IMS Connect Connections

Connection pooling reduces the number of times new connections need to be established. Each new connection for a CM0 mobile transaction will consume IMS resources and create a new TPIPE control block in IMS. Implementing connection pooling properly will increase the performance of any mobile application by using active connections of the pool for consecutive requests rather than creating a new connection each time.

A minimum and maximum pool size for connection pooling might be needed. If there's no connection available and the number of existing connections hasn't reached the maximum pool size yet, a new connection can be created; if the maximum pool size has been reached and no usable connection is available, the request can be queued until there's an available connection or when the time-out is reached. Without connection pooling, many TPIPEs in IMS can be created to consume a large amount of system resources.

Avoid Closing Connection for Errors From IMS

The TCP/IP socket connection could close when an error occurs. However, if IMS reports an error, such as a stopped IMS transaction, IMS application abend or an IMS error message, the connection can remain open to save IMS resources.

Add Socket Reconnect Function

The socket reconnect function will re-establish a stale connection when one of the connections encounters a problem in the process of sending a request to or receiving a response from IMS Connect.

Choose “Purging Undeliverable” for CM0 Mobile Output

Purging undeliverable CM0 output is an option for mobile apps. When set, IMS will discard any undeliverable CM0 output to IMS Connect so that no output will be queued to IMS TPIPE. If an IMS TPIPE resource has queued output, the TPIPE resource cannot be released when TPIPE becomes inactive after three IMS checkpoints.

Specify an Alternate Client ID to Retrieve Mobile Output

A RESUME TPIPE call for IMS Connect is used to retrieve CM0 mobile outputs or IMS callout messages. Specifying an Alternate Client ID for a RESUME TPIPE call will reduce the number of TPIPE resource allocated in IMS.

Re-route Mobile Transactions When IMS Reports a Flood Condition

IMS Connect will report the IMS flood conditions in the return and reason codes fields of request status message. The specific IMS sense codes for IMS flood are X'0029' and X'0030', of which X'0029' reports the TPIPE flood and X'0030' reports the message flood. Mobile apps can re-route the subsequent mobile transactions to a different destination when an IMS flood occurs.

Monitor the Growth of IMS Resources

While testing the mobile apps, developers should periodically monitor the growth of IMS resources related to IMS Connect and OTMA by issuing IMS command/DISPLAY OTMA (see Figure 1). In the example, the number of all the TIB allocated in the IMS is 20, and the number of all the TPIPE resources allocated is 10, located under the TPCNT column.

You can also issue IMS command/DISPLAY TMEMBER member-name TPIPE ALL to view all of the TPIPEs created for the IMS Connect connections. Be sure to pay attention to the output message en-queue count (ENQCT) and output message de-queue count (DEQCT). Avoid having TPIPE resources allocated with both ENQCT=0 and DEQCT=0.

Mei Xiu Li is an IMS quality analyst with IBM. She can be contacted at

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

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.



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