Specifying an expiration time for transactions to OTMA

You can specify an expiration time for a transaction to reduce processing costs by preventing IMS from processing transactions that the client can no longer use.

When a transaction specifies an expiration time, OTMA monitors the transaction and, if the transaction is not processed or enqueued before the time expires, OTMA discards the transaction.

OTMA stops monitoring a transaction for expiration when an IMS application program in an IMS dependent region retrieves the transaction for either MSC, Fast Path, or conversational processing. After either of these events, the expiration time no longer applies and IMS processes the transaction and returns the output to OTMA and the OTMA client.

You can enable transaction expiration either when you define the transaction to IMS or in the OTMA message header when the transaction is submitted to OTMA. An expiration time specified in the definition of a transaction becomes the default expiration period for that transaction type and applies to all instances of the transaction. An expiration time specified in an OTMA message header applies only to the transaction instance submitted with the OTMA header and overrides any expiration time specified in the transaction definition.

An expiration time specified in an OTMA message header can be specified as a point in time or as a length of time. If specified as a point in time, the expiration time is specified in store clock (STCK) format and represents the time of day at which a transaction expires. If specified as a length of time, the expiration time is specified in seconds and OTMA calculates the expiration time from the time at which OTMA receives the transaction from the z/OS® cross-system coupling facility (XCF).

OTMA checks if a transaction is expired at three points:

  1. When OTMA first receives a transaction from XCF. If the expiration time has already passed, OTMA discards the transaction and returns a NAK message to the client.
  2. When OTMA enqueues a transaction in IMS. If a transaction expires before OTMA enqueues the transaction, OTMA discards the transaction and returns a NAK message to the client.
  3. For transactions that are not MSC, Fast Path, or conversational, when an IMS application program issues a GU call to retrieve a transaction from the input queue.

    If a transaction expires on the input queue before an IMS application program can retrieve it with a GU call, OTMA discards the transaction and, by default, issues message DFS3688I to the OTMA client. However, if the TMAMINPT flag is set in the OTMA input message that expires, instead of the returning a DFS3688I message, OTMA sends back the original input transaction data to the OTMA client.

    For each OTMA client, you can optionally configure OTMA to create a symptom dump and issue a DFS554A message for transactions that expire on the input queue by specifying TODUMP=YES in the OTMA client descriptor in the DFSYDTx member of the IMS.PROCLIB data set.

    You can also request a symptom dump and DFS554A message for individual messages by setting the TMAMDUMP flag in the OTMA state data prefix of input messages. Setting the TMAMDUMP flag on an individual message overrides a specification of TODUMP=NO for that message only.

For the following transaction types, OTMA monitors the expiration time only until the transaction is enqueued in IMS:

OTMA does not monitor the expiration time for the following transaction types:

When you define an expiration time period in the definition of a transaction, you use the EXPRTIME parameter of either the TRANSACT stage-1 system definition macro or the type-2 dynamic resource definition commands CREATE TRAN or UPDATE TRAN. You can also specify an expiration time period for transactions created by the Destination Creation exit routine (DFSINSX0). Transaction expiration times enabled by any of these methods are not specific to OTMA.