IMS Connectivity in an On Demand Environment: A Practical Guide to IMS Connectivity

Chapter 2. Open Transaction Manager Access 13

In order to guarantee that client transactions are processed and that they are processed only

once, OTMA provides a protocol for synchronizing transactions. This is done by defining the

Tpipe as synchronized in the MCI section of the message and by using commit mode 0. IMS

then waits for the response from the client (acknowledgment) before the output is dequeued

from the message queue. This provides the message recoverability similar to that provided for

Set and Test Sequence Number (STSN) terminals, such as SLUP, 3600, and ISC terminals. if

ACK is not received or a NAK is sent by the client, the output message is not dequeued.

Message recoverability is applicable only for commit-then-send mode transactions. Any input

messages on the message queue that are marked nonrecoverable are discarded during an

IMS restart. Any input messages on the message queue that are marked recoverable are left

on the message queue and are eligible for scheduling after the IMS restart completes.

Transactions from OTMA clients are recoverable if the recoverable sequence number in the

MCI section of the message prefix is not 0. IMS then forces the transaction to be recoverable

even if the TRANSACT macro does not contain the INQUIRY=RECOVER parameter.

2.3.2 Send-then-commit message (commit mode 1) flows

With send-then-commit mode, there are three different levels of synchronization that can be

used:

none, confirm, or sync point. The message flow is different in all these different cases.

With commit-then-send mode, the synchronization level parameter is ignored, and the

synchronization level of confirm is always used.

With the send-then-commit flow, the output is not enqueued; instead, it is sent directly to the

client before the transaction is committed. Therefore, the output is nonrecoverable in case of

a transaction abort. Even though the message is received, the OTMA client should not

process the message. After sync point is complete, OTMA will send another output indicating

whether the sync point was successful or failed. This is called a deallocation message. If the

sync point was successful, a deallocate confirm message is sent, and the OTMA client knows

that the transaction has not backed out. If the sync point was not successful (for example,

DB2 voted “no” during two-phase commit), OTMA will send a deallocate abort message, and

the OTMA client knows that the transaction has backed out. It then has to make the decision

of what to do with the output message.

Send-then-commit (sync level=none)

With send-then-commit flow, IMS sends the output message, but does not request or wait for

an acknowledgement from the client. After the message is sent, sync point processing

continues. Even though the OTMA client gets the message, it should not process the

message until the deallocate message is received from OTMA. Figure 2-5 on page 14 shows

the message flow for send-then-commit with sync level=none and deallocate confirm

message. If the sync point does not complete successfully, OTMA sends the deallocate abort

instead of the deallocate confirm message, and then the client discards the output message.

14 IMS Connectivity in an On Demand Environment: A Practical Guide to IMS Connectivity

Figure 2-5 Send-then-commit message flow with sync level=none, deallocate confirm

Send-then-commit (sync level=confirm)

If the synchronization level is set to confirm in the state-data section, IMS sends the output

message, request, and acknowledgement (ACK) or negative acknowledgement (NAK) before

continuing sync point processing. This increases region occupancy.

If an ACK is returned, sync point processing continues. Even though the OTMA client has

received the message and returned an ACK, it still does not process the message until the

deallocate message is received. Figure 2-6 on page 15 shows the deallocate confirmed flow.

Again, if the sync point does not complete successfully, OTMA sends the deallocate abort

instead of the deallocate confirm message, and then the client discards the output message.

If a NAK is returned, the transaction will abend U0119. The database updates are backed out,

and message DFS555I is sent to the client. The client then sends an ACK for the DFS555I

message, and IMS responds with the commit aborted message.

While OTMA is waiting for an ACK/NAK, a /DIS TMEMBER xxx TPIPE yyy command shows

a status of WAIT_A (waiting for ACK). If a you enter the /STOP TMEMBER xxx TPIPE yyy

command, a NAK is generated and the transaction will abend U0119.

IMSOTMA Client Application

GU Call

...

ISRT to IOPCB

Sync Start

Sync End

Transaction

completes

Transaction

inserted to SMB

OTMA Prefix

DATA

DATA

TRAN

OTMA Prefix

TRAN DATA

MSGQ

DATA

Output sent

Send

Receive

Receive

OTMA Prefix

Deallocate Confirm