Summary of OTMA commit processing

The following table summarizes the differences between commit-then-send and send-then-commit processing.

Several variables are listed in the first column; the differences between processing options are described in the next two columns. Following the table are some usage notes to be aware of.

Table 1. Commit-then-send versus send-then-commit processing
Variables Commit-then-send Send-then-commit
Conversational Client receives a NAK message. Supported.
Fast Path Client receives a NAK message. Supported.
Non-conversational and non-Fast Path transactions IMS commits after enqueuing the output to the client. The output is delivered later. IMS sends output to the client and then commits.
Enqueue the input? Yes. Yes.
Enqueue the output? Yes. No.
Synchronized transaction pipe specified? Supported. Client receives a NAK message.
Timeout interval enforced? No. Yes, if a timeout value is specified with either synclevel=confirm or synclevel=synchpt.
Notes:
  • IMS conversations cannot use the commit-then-send commit mode.
  • Send-then-commit input and output is irrecoverable.
  • For irrecoverable output (send-then-commit), IMS requests an acknowledgment if the synchronization level is set to Confirm.
  • For a recoverable transaction, IMS always requests an acknowledgment for an output message.
  • For commit-then-send transactions, IMS always requests an acknowledgment.
  • Synchronized transaction pipes can only be used for commit-then-send transactions.
  • When a send-then-commit (CM1) input message is sent to a transaction, OTMA treats that transaction as RESPONSE mode even if the transaction is defined as NONRESPONSE. If the application does reply to the IOPCB, the output is send-then-commit. If the application does not reply to the IOPCB and does not complete a program-to-program message switch, then OTMA responds with a DFS2082 RESPONSE MODE TRANSACTION TERMINATED WITHOUT REPLY message.
  • When a commit-then-send (CM0) input message is sent to a transaction, and the TMAMHRSP flag is set in the OTMA state data prefix, OTMA treats that transaction as RESPONSE mode even if the transaction is defined as NONRESPONSE. If the application does not reply to the IOPCB and does not complete a program-to-program message switch, OTMA responds with a DFS2082 message.
    Restriction: This DFS2082 message for a commit-then-send transaction occurs only for the original input transaction and would not support the program-to-program switch.