Recoverable IMS transactions

This topic contains scenarios for running recoverable transactions in the IMS Connect environment.

For each of the following scenarios:
  • OTMA will have deleted the input message.
  • Requeuing of the input message will not occur.
  • For CM1 (send-then-commit), none of the output is placed (ENQUEUED) in the IMS queue.

Only commit mode 0 (CM0, also referred to as commit-then-send) is treated as recoverable; CM1 is not recoverable. With the use of CM0, IMS Connect creates a separate TPIPE for each client that uses CM0. This TPIPE remains in IMS, so a fixed client name is highly recommended for each client that intends to use CM0.

The combination of commit mode and Sync level is critical. The following scenarios describe the different uses and the results.
  • With CM1 and SYNC LEVEL = NONE:

    The input message is processed by IMS and an output message is sent back to IMS Connect, IMS Connect sends the message to the client, and any ACK/NAK from the client in response to the output message would become an error because the ACK/NAK are not expected and IMS Connect would have received a message from the client with no application data.

  • With CM1 and SYNC LEVEL = CONFIRM:

    The input message is processed by IMS and an output message is sent back to IMS Connect, IMS Connect sends it to the client, and an ACK from the client will result in the successful completion of the application. This scenario works as expected.

    The input message is processed by IMS and an output message is sent back to IMS Connect, IMS Connect sends it back to the client, and a NAK from the client will result in an IMS MPP 119 abend and an IMS message, DFS555. The 119 abend will back out the database changes, and both the input and output messages are discarded. The result would be as if the system had never seen the transaction, and a reentry of the transaction would be necessary.

  • With CM0 and SYNC LEVEL = CONFIRM:

    The input message is processed by IMS, the application program commits the changes, and an output message is sent back to IMS Connect. IMS Connect sends it to the client, and an ACK response from the client results in IMS dequeuing the output, and represents the successful completion of transaction processing. CM0 forces the Synch level to Confirm. This scenario works as expected.

    The input message is processed by IMS and an output message is sent back to IMS Connect, IMS Connect sends it back to the client, and a NAK from the client will result in the database changes not being backed out. The input message is discarded and the output message is requeued to the IMS queue for representation. These output messages will be moved to the hold asynchronous queue by OTMA, and will be retrievable only with the RESUME TPIPE, RECEIVE and ACK process.

Recommendation: To run recoverable transactions in the IMS Connect environment, use CM0 and SYNC LEVEL = CONFIRM, and use a single unique CLIENT_ID for each client that uses CM0 and SYNC LEVEL = CONFIRM