Impact of OTMA message TIBs on storage

For each message received from an OTMA client, IMS creates a transaction instance block (TIB).

Each TIB requires approximately 8 KB of extended private area storage.

You can view information about the TIBs and the OTMA messages that are currently being processed by IMS by issuing the type-2 IMS Command QUERY OTMATI. The information you can view includes message counts, message ages, and much more.

Normally TIBs are freed and the storage released by IMS either after IMS enqueues the commit-then-send (CM0) input message of TIBs created for commit-then-send messages or after IMS returns a send-then-commit (CM1) output message of TIBs created for send-then-commit messages.

An excessive number of TIBs is usually caused by either a message flood condition or orphan TIBs.

Message flood conditions usually occur as a result of:
  • A stopped program
  • The unavailability of message processing regions
  • The rate of incoming messages exceeding the rate at which IMS can process the messages

To help avoid a message flood condition, you can enable message flood detection by specifying a maximum number of OTMA messages that IMS can process at any one time. IMS determines the number of messages that are currently being processed by counting TIBs. When message detection is enabled, IMS issues messages when the number of TIBs nears the maximum.

Orphan TIBs

There are circumstances in which IMS cannot free a TIB. When this happens, the TIB persists in storage as an orphan TIB.

Orphan TIBs are created when IMS processes an OTMA transaction, but does not generate either a send-then-commit output message or a DFS2082 message in place of the send-then-commit output message. For example, if a send-then-commit message triggers a program-to-program switch to an asynchronous transaction that is defined as a non-response mode transaction, and if OTMAASY=Y, IMS cannot delete the TIB even thought the switched-to transaction generates a response to the IOPCB.

IMS includes orphan TIBs in its count of total TIBs when message flood is enabled. If OTMA input has been stopped due to a message flood condition, you can issue the /DISPLAY OTMA or /DISPLAY TMEMBER command to see the number of TIBs. If there is still a high number of TIBs after the OTMA input has been stopped, it is possible that there are orphan TIBs.

You can remove orphan TIBs related to IMS conversational transactions. You can identify orphan TIBs that are related to conversational transactions by issuing the command /DISPLAY CONVERSATION. If an orphaned TIB exists for the conversation, you can then issue the command /EXIT CONVERSATION to remove the orphaned TIB.

You can also remove orphan TIBs related to conversational transactions in OTMA by specifying the ENDCONV= parameter of the DFSOTMA descriptor in the DFSYDTx member of the IMS PROCLIB data set. If the conversational transaction remains idle for the specified period of time after the prior iteration of the conversational transaction completes, OTMA ends the transaction and releases IMS resources that were allocated for the transaction.