Understanding ims otma commit mode and synclevel

©2012 IBM Corporation

Understanding IMS OTMA Commit Mode and

Synchronization Level

IMS User Group

Steve [email protected]

2

IMS Regional User Group

Understanding IMS OTMA Commit Mode and Synchronization Level

Disclaimer

© Copyright IBM Corporation [current year]. All rights reserved.U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

THE INFORMATION CONTAINED IN THIS PRESENTATION IS PROVIDED FOR INFORMATIONAL PURPOSES ONLY. WHILE EFFORTS WERE MADE TO VERIFY THE COMPLETENESS AND ACCURACY OF THE INFORMATION CONTAINED IN THIS PRESENTATION, IT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. IN ADDITION, THIS INFORMATION IS BASED ON IBM’S CURRENT PRODUCT PLANS AND STRATEGY, WHICH ARE SUBJECT TO CHANGE BY IBM WITHOUT NOTICE. IBM SHALL NOT BE RESPONSIBLE FOR ANY DAMAGES ARISING OUT OF THE USE OF, OR OTHERWISE RELATED TO, THIS PRESENTATION OR ANY OTHER DOCUMENTATION. NOTHING CONTAINED IN THIS PRESENTATION IS INTENDED TO, NOR SHALL HAVE THE EFFECT OF, CREATING ANY WARRANTIES OR REPRESENTATIONS FROM IBM (OR ITS SUPPLIERS OR LICENSORS), OR ALTERING THE TERMS AND CONDITIONS OF ANY AGREEMENT OR LICENSE GOVERNING THE USE OF IBM PRODUCTS AND/OR SOFTWARE.

IBM, the IBM logo, ibm.com, and IMS are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml

3



Introduction

IMS OTMA

– IMS/ESA 5.1 introduced the IMS OTMA (Open Transaction

Manager Access) feature

• There have been MANY enhancements since then

– The OTMA code runs in the IMS Control Region

– This feature uses the MVS cross-coupling facility (XCF) to send

and receive data (messages and commands) to/from IMS from

MVS applications (OTMA clients)

• No VTAM or TCP/IP is involved

• OTMA clients do not have to be in the same LPAR as IMS

– They just have to be in the same SYSPLEX.

4



Introduction

There is a wide variety of OTMA clients

– MQSeries includes an IMS OTMA client

• “MQSeries-IMS Bridge”

– IMS Connect is an IBM provided OTMA client for TCP/IP

– DB2 Stored Procedures include an OTMA Client

• DSNAIMS

– You can write your own OTMA client

• Using the XCF Interface (VERY hard to do)

• Using the OTMA Callable Interface from Java, C or C++ programs

– Many vendors provide OTMA clients

5



SERVERz/OS,WIN,

AIX, SUN, …

SNA

z/OS

TCP/IP

ICON

OTMA

IMS

VTAM

IMS BRIDGE

MQSeries

LU1LU2

LU 6.1LU 6.2

XCF

AnyTCP/IP

App

RYOClient

TN3270

Websphere

ICON

IMS BRIDGE

MQSeries

z/OS

XCF

XCF

ITRA

Websphere

PC

MQSeries

TCP/IP

Websphere

IMS TMResourceAdapter

End User

TCP/IPApplication

SCI

OM

IMS ControlCenter

BTAM <V10

VTAM

MFS WebServices

ITRA

IMS SOAPGateway


Understanding IMS OTMA Commit Mode and Synchronization Level 6

Introduction

IMSAOTMANM=IMSAOTMA

IMSBOTMANM=IMSBOTMA

XCF GROUPGRNAME=GR1

XCF GROUPGRNAME=GR2

DS1

DS2

DS3

ICON1

IMS BridgeQueue

StorageClass

MQSeries

TMEMBER1

TMEMBER2

TMEMBER3

TMEMBER4

Names are not definedin any IMS GEN

TPIPE's

TPIPE's

7



TPIPEs (Transaction Pipes)

OTMA equivalent of LTERMs Input (IOPCB) TPIPE names are specified by the OTMA

Client in the OTMA header– For IMS Connect for CM1 messages it is the TCP/IP Port which

received the input message

– For IMS Connect for CM0 messages it is the ICON Client Name

• This could lead to MANY TPIPEs!!!

– For MQSeries there are 2 TPIPEs per IMS Bridge Queue

• One for “asynchronous” messages (CM0)

• One for “synchronous” messages (CM1)

• The name is a 3-character user supplied prefix and a 5-digit number

– It is a 2-character prefix if using MQSeries shared queues

– If the TPIPE does not exist is it created

8



Client Interface

The OTMA client communicates information to IMS

and gets information from IMS in a prefix passed in

front of the message (or command)

– The prefix has 4 sections mapped by macro DFSYMSG (or

HWSOMPFX for ICON):

• Control: TPIPE name and type, message type, chaining, etc.

• State Data: Commit mode, Sync Level, IOPCB LTERM and

MODNAME override, etc.

• Security: Security scope, Userid, Group, Utoken, no password

• User: Client specific – maximum of 1,024 bytes

9



Client Interface OTMA Synclevel

– Specified by the OTMA client on each input message– Determines how output messages are acknowledged by the

OTMA client• IOPCB output and ALTPCB output

– Synclevel 0 (SL0) - None• The output message is not acknowledged – no ACK/NAK

– Synclevel 1 (SL1) - Confirm• The OTMA client must send an ACK/NAK for the output message

– Dequeue/Reenqueue the output message (CM0)– Complete syncpoint – (CM1)

• MQSeries always uses SL1

– Synclevel 2 (SL2) - Syncpoint• The OTMA client is participating in 2-phase commit

• Only supported by IMS Connect and IMS TM Resource Adapter

10



Client Interface

OTMA Synclevel

– Does not apply to OTMA acknowledging input messages

– To ask OTMA to acknowledge an input message set

TMAMCRSI to TMAMCRRQ (x’20’) in the Control section in the

OTMA header

• MQSeries always does this

• IMS Connect does not do this

– With one exception – Send-Only with ACK

11



Client Interface

OTMA Commit Mode

– Specified by the OTMA client on each input message

– Determines how IOPCB output messages are sent

– Similar to APPC-IMS Commit Mode

12



Client Interface

OTMA Commit Mode

– Commit Mode 1 (CM1) - Send-then-commit

• IMS sends the IOPCB output and may wait for an ACK before

syncpoint is complete

– Synch level 0 (None) – no ACK – continue syncpoint

– Synch level 1 (Confirm) – wait for ACK/NAK

– Synch level 2 (Synchpoint) – wait for ACK/NAK + RRS

• Increases region occupancy

• MQSeries calls these “synchronous” messages

– The output message is “synchronous” with syncpoint completion

13



Client Interface

OTMA Commit Mode

– Commit Mode 1 - Send-then-commit

• Output messages are not queued

– Anchored on a control block called a TIB (Transaction Instance Block)

– The destination name is x’FDFFFFFFaaaaaaaa’

• aaaaaaaa is the address of a CLB associated with the TIB

• Not the address of the TIB control block

• If the message can not be sent to the client or is NAKed by the client

(SL1) the transaction abends with U0119 and backs out

• CM1 is required for Conversational and Fast Path EMH messages

14



Client Interface OTMA Commit Mode


• For Synclevel 0 (SL0) even though the OTMA client gets the

message before the syncpoint is complete it should not process the

message until it receives a “deallocation” message from OTMA

indicating the status of the syncpoint

– “Commit Confirm” or “Commit Abort”

– “De-allocate Confirm” or “De-allocate Abort”

– Only returned at the end of a conversation for IMS Conversations

– If the syncpoint did not complete successfully the OTMA client should

discard the message

• IMS Connect does this and sends an error message to the ICON Client

instead

• MQSeries always uses SL1

• OTMA C/I does this



OTMA Client Interface – IMS ConnectCM1 SL0 – Syncpoint OK

ICON CLIENT ICON OTMA MPRTCP/IP WRITE

CM1 SL0XCF SENDCM1 SL0

ALLOC TIBCALL RACFISRT MSGENQ MSG GU IOPCB

ISRT IOPCB

ANCHORMSG on TIB

START SYNC

XCF SENDREPLY

TIB

ANCHORREPLYON SVT

12 3 4

5

9

7

IMSMessageQueue

SVT

CONNECTWRITEREAD

6

GET MSG

8

10

(ALLOCSVT)

XCF SEND

XCF SEND



OTMA Client Interface – IMS ConnectCM1 SL0 – Syncpoint OK

ICON CLIENT ICON OTMA MPR

SYNC OK

XCF SENDDEALLOCATE

CONFIRM

TCP/IP WRITEREPLY

TIB

FREE TIB

PROCESSREPLY

SVT

16

11

14SYNC

COMPLETE

15

18

SENDREPLY

PROCESSSYNC

12

XCF SEND

13

KEEP/FREESVT

17

17



Client Interface IMS Connect – CM1 SL0 – Syncpoint OK

1. An IMS Connect Client sends a CM1 SL0 input message to ICON

2. IMS Connect allocates a control block for the Client (SVT) if it does not already exist and sends the input message to IMS OTMA via XCF

• The TPIPE name is the Port number that received the input message

3. OTMA processes the input message

• Allocates the TIB

• Calls RACF if needed

• Inserts the input message to the IMS Message Queue

– X’01’ log record – input message

• Enqueues the input message on the transaction queue

– X’35’ log record - enqueue

18




4. The IMS transaction does a GU to the IOPCB to retrieve the input message

• X’31’ log record – “DL/I Get Unique”

5. The IMS transaction ISRTs the reply message to the IOPCB

• X’03’ log record – output message

6. The reply message is anchored on the TIB

• No X’35’ log record – message is not enqueued

7. The IMS application reaches a syncpoint (GU IOPCB, termination)

19



Client Interface

IMS Connect – CM1 SL0 – Syncpoint OK

8. IMS OTMA retrieves the reply message from the message queue

• X’31’ log record – “Communications Get Unique”

9. IMS OTMA sends the reply message to IMS Connect via XCF and

deletes it from the IMS Message Queue

• X’33’ log record – Free DRRN

10. IMS Connect anchors the reply message on the SVT waiting for the De-

Allocate

20



Client Interface


11. Syncpoint proceeds

• X’5610’ record – begin Phase 1 syncpoint

• X’37’ – end Phase 1 syncpoint – begin Phase 2 syncpoint

12. Syncpoint completes successfully

13. OTMA sends the De-Allocate Confirm to IMS Connect (not if Conversation)

14. OTMA deletes the TIB control block (not if Conversation) and frees the input

message

• X’33’ log record – free DRRN

21



Client Interface


15. Syncpoint completes

• X’5612’ log record – end Phase 2 syncpoint

16. IMS Connect sends the reply message to the IMS Connect Client

17. If this is a persistent socket IMS Connect keeps the connection open

and does not free the SVT control block

18. The ICON Client processes the reply message

22




– This is what you would have seen in IMSPI if you had done a TX on

the x’01’ log record

01 Input Message TranCode=TRANA Source=CONNECT 35 Input Message Enqueue TranCode=TRANA 08 Application Start TranCode=TRANA Region=00015607 Start of UOR Program=PROGRAMA Region=0001 31 DLI GU TranCode=TRANA Region=0001 03 Output Message Response LTerm=6001 Source=CONNECT 31 Message GU for APPC LTerm=6001 33 Free Message 5610 Syncpoint Start of Phase 1 Region=0001 3730 Syncpoint End of Phase 1 Region=0001 33 Free Message 5612 Syncpoint End of Phase 2 Program=PROGRAMA Region=000107 Application Terminate TranCode=TRANA Region=0001



OTMA Client Interface – IMS ConnectCM1 SL0 – Syncpoint Fail




ISRT IOPCB

ANCHORMSG on TIB

START SYNC

XCF SENDREPLY

TIB

ANCHORREPLYON SVT

12 3 4

5

9

7

IMSMessageQueue

SVT

CONNECTWRITEREAD

6

GET MSG

8

10

(ALLOCSVT)

XCF SEND

XCF SEND



OTMA Client Interface – IMS ConnectCM1 SL0 – Syncpoint Fail


SYNC FAIL

XCF SENDDEALLOCATE

ABORT

TCP/IP WRITEDFSxxx

TIB

FREE TIB

PROCESSDFSxxx

SVT

16

11

14APPL

ABEND

15

18

SENDDFSxxx

PROCESSSYNC

12

XCF SEND

13

KEEP/FREESVT

17

XCF SENDDFSxxx

DISCARDREPLY

XCF SEND

25



Client Interface IMS Connect – CM1 SL0 – Syncpoint Fail









26



Client Interface IMS Connect – CM1 SL0 – Syncpoint Fail






9. IMS OTMA sends the reply message to IMS Connect via XCF and

deletes it from the IMS Message Queue

10. IMS Connect anchors the reply message on the SVT waiting for the De-

Allocate

27



Client Interface

IMS Connect – CM1 SL0 – Syncpoint Fail


12. Syncpoint fails

13. OTMA process the syncpoint failure

• OTMA sends the DFSxxx message to IMS Connect via XCF

• OTMA sends the De-Allocate Abort to IMS Connect via XCF

• Because this is XCF these messages can arrive in any order in IMS

Connect

14. OTMA deletes the TIB control block

28



Client Interface

IMS Connect – CM1 SL0 – Syncpoint Fail

15. Syncpoint fails

• The application abends

16. IMS Connect processes the syncpoint failure

• IMS Connect discards the reply message

• IMS Connect sends the DSFxxx message to the IMS Connect Client



18. The ICON Client processes the DSFxxx message

29





• For Synclevel 1 (SL1) the OTMA client gets the message and has

to send an ACK for syncpoint to continue but it should still not

process the message until it receives the de-allocate response

– ICON will send the message to the ICON Client and wait for the ACK

from the ICON Client which is then sent to OTMA

• There is a timeout in OTMA waiting for the ACK

– The ICON client will get another output after IMS Connect receives the

de-allocate message from OTMA (unless in conversation)

• RC4, Reason Code x’97’ – de-allocate confirmed

• RC4, Reason Code x’96’ – de-allocate abort



OTMA Client Interface – IMS ConnectCM1 SL1 – ACK – Syncpoint OK




ISRT IOPCB

ANCHORMSG on TIB

START SYNC

XCF SENDREPLY

TIB

ANCHORREPLYON SVT

12 3 4

5

9

7

IMSMessageQueue

SVT

CONNECTWRITEREAD

6

GET MSG

8

10

(ALLOCSVT)

XCF SEND

XCF SEND





TIBSVT

TCP/IP WRITEREPLY

TCP/IP WRITEACK

HOLDREPLY

11

14

SEND ACKREAD

REPLYON SVT

SENDREPLYREAD

XCF SEND

XCF SENDACK

12

13





SYNC OK

XCF SENDDEALLOCATE

CONFIRM

TCP/IP WRITEDEALLOCATE

CONFIRM

TIB

FREE TIB

PROCESSREPLY

SVT

20

15

18SYNC

COMPLETE

19

22

SENDDEALLOC

PROCESSSYNC

16

XCF SEND

17

KEEP/FREESVT

21

XCF SENDACK

33



Client Interface IMS Connect – CM1 SL1 – ACK – Syncpoint OK









34




4. The IMS transaction does a GU to the IOPCB to retrieve the input

message




35



Client Interface

IMS Connect – CM1 SL1 – ACK – Syncpoint OK


9. IMS OTMA sends the reply message to IMS Connect via XCF

• IMS OTMA waits for an ACK/NAK

• Syncpoint processing is held

• The MPR is occupied

• Database locks are held

• External subsystem (DB2, MQ, etc.) locks are held

10. IMS Connect anchors the reply message on the SVT

36



Client Interface

IMS Connect – CM1 SL1 – ACK – Syncpoint OK


• IMS Connect waits for the ACK/NAK

12. The IMS Connect Client gets the reply message and sends an ACK

13. The IMS Connect Client holds the message waiting for the

De-Allocate message to see if syncpoint completed successfully

14. IMS Connect sends the ACK to OTMA

37






17. OTMA sends the De-Allocate Confirm to IMS Connect



20. IMS Connect sends the De-Allocate Confirm to the IMS Connect

Client



22. The ICON Client processes the reply message



OTMA Client Interface – IMS ConnectCM1 SL1 – ACK – Syncpoint Fail




ISRT IOPCB

ANCHORMSG on TIB

START SYNC

XCF SENDREPLY

TIB

ANCHORREPLYON SVT

12 3 4

5

9

7

IMSMessageQueue

SVT

CONNECTWRITEREAD

6

GET MSG

8

10

(ALLOCSVT)

XCF SEND

XCF SEND





TIBSVT

TCP/IP WRITEREPLY

TCP/IP WRITEACK

HOLDREPLY

11

14

SEND ACKREAD

REPLYON SVT

SENDREPLYREAD

XCF SEND

XCF SENDACK

12

13





SYNC FAIL

XCF SENDDEALLOCATE

ABORT

TCP/IP WRITEDFSxxx

TIB

FREE TIB

PROCESSDFSxxx

SVT

20

15

18APPL

ABEND

19

22

SENDDFSxxx

PROCESSSYNC

16

XCF SEND

17

KEEP/FREESVT

21

XCF SENDDFSxxx

XCF SEND

DISCARDREPLY

XCF SENDACK

41



Client Interface IMS Connect – CM1 SL1 – ACK – Syncpoint Fail









42





message




43



Client Interface

IMS Connect – CM1 SL1 – ACK – Syncpoint Fail









44



Client Interface





13. The IMS Connect Client holds the message waiting for the

De-Allocate message to see if syncpoint completed successfully


45



Client Interface



16. Syncpoint fails

17. OTMA processes the failed syncpoint




Connect


46




19. Syncpoint fails


20. IMS Connect processes the failed syncpoint




22. The ICON Client processes the failed syncpoint

• The ICON Client discards the reply message

• The ICON Client processes the DSFxxx message



OTMA Client Interface – IMS ConnectCM1 SL1 – Client NAK




ISRT IOPCB

ANCHORMSG on TIB

START SYNC

XCF SENDREPLY

TIB

ANCHORREPLYON SVT

12 3 4

5

9

7

IMSMessageQueue

SVT

CONNECTWRITEREAD

6

GET MSG

8

10

(ALLOCSVT)

XCF SEND

XCF SEND





TIBSVT

TCP/IP WRITEREPLY

TCP/IP WRITENAK

DISCARDREPLY

11

14

SEND NAKREAD

REPLYON SVT

SENDREPLYREAD

XCF SEND

XCF SENDNAK

12

13





SYNC FAIL

XCF SENDDEALLOCATE

ABORT

TCP/IP WRITEDFSxxx

TIB

FREE TIB

PROCESSDFSxxx

SVT

20

15

18APPL

ABEND

19

22

SENDDFSxxx

PROCESSSYNC

16

XCF SEND

17

KEEP/FREESVT

21

XCF SENDNAK

XCF SEND

XCF SENDDFSxxx

50



Client Interface IMS Connect – CM1 SL1 – Client NAK









51





message




52



Client Interface

IMS Connect – CM1 SL1 – Client NAK









53



Client Interface




12. The IMS Connect Client gets the reply message and sends a NAK

13. The IMS Connect Client discards the reply message and waits for the

De-Allocate message

14. IMS Connect sends the NAK to OTMA

54



Client Interface



16. Syncpoint fails





Connect


55



Client Interface


19. Syncpoint fails


20. IMS Connect processes the failed syncpoint




22. The ICON Client processes the DSFxxx message



OTMA Client Interface – WebSphere MQ CM1 SL1 – ACK – Syncpoint OK

OTMA MPR

XCF SENDCM1 SL1

ALLOC TIBCALL RACFISRT MSGENQ MSGSEND ACK

GU IOPCB

ISRT IOPCBANCHORMSG on TIB

START SYNC

XCFSEND REPLY

MQ APPL

MQPUTIMS

BRIDGEQUEUE

MQ IMS BRIDGE

MQGETXCF SEND

1

2

3

46

7

9

XCF SENDACK

5

8

IMSMessageQueue

MQCMITDEQUEUE

INPUT

TIB

MQQueue

GET MSG

XCF SEND

10



OTMA Client Interface – WebSphere MQ CM1 SL1 – ACK – Syncpoint OK

OTMA MPR

PROCESSSYNC

SYNCCOMPLETE

XCFSEND REPLY

XCF SENDXCF SENDDEALLOCATE

CONFIRM

XCF SEND ACK

FREE TIB

MQ APPL

MQGETREPLYTOQUEUE

MQ IMS BRIDGE

MQPUTRTQ(OR DLQ)OK

MQCMIT

11

1213

16

17

TIBMQ

Queue

XCF SEND

SYNC OK

14

18

19

15

58



Client Interface WebSphere MQ – CM1 SL1 – Syncpoint OK

1. A WebSphere MQ application does an MQPUT to an IMS Bridge Queue

2. The IMS Bridge code in the WebSphere MQ Queue Manager has an

outstanding MQGET In Syncpoint for the IMS Bridge Queue and

receives input the message

• WebSphere MQ sends the input message to IMS OTMA via XCF






• Sends an ACK for the input message to WebSphere MQ

59



Client Interface

WebSphere MQ – CM1 SL1 – Syncpoint OK

4. WebSphere MQ does an MQCMIT and the input message is

dequeued


message




9. IMS OTMA Retrieves the reply message from the message queue

60




10. IMS OTMA sends the reply message to WebSphere MQ via XCF






11. The WebSphere MQ IMS Bridge MQPUTs the reply message to the

Reply-To Queue In Syncpoint but does not commit

• If the MQPUT to the Reply-To Queue fails the message is MQPUT

to the Dead Letter Queue

61




12. The WebSphere MQ IMS Bridge sends an ACK to OTMA for the reply

message



15. OTMA sends the De-Allocate Confirm to WebSphere MQ



18. The WebSphere MQ IMS Bridge MQCMITs the reply message

19. The WebSphere MQ application MQGETs the reply message from the

Reply-to Queue



OTMA Client Interface – WebSphere MQ CM1 SL1 – ACK – Syncpoint Fail

OTMA MPR

XCF SENDCM1 SL1


GU IOPCB


START SYNC

XCFSEND REPLY

MQ APPL

MQPUTIMS

BRIDGEQUEUE

MQ IMS BRIDGE

MQGETXCF SEND

1

2

3

46

7

9

XCF SENDACK

5

8

IMSMessageQueue

MQCMITDEQUEUE

INPUT

TIB

MQQueue

GET MSG

XCF SEND

10



OTMA Client Interface – WebSphere MQ CM1 SL1 – ACK – Syncpoint Fail

OTMA MPR

PROCESSSYNC

APPLABEND

XCFSEND REPLY


ABORT

XCF SEND ACK

FREE TIB

MQ APPL

MQGETREPLYTOQUEUE

(DFSxxx)

MQ IMS BRIDGE

MQPUTRTQ(OR DLQ)OK

MQBACKREPLY

11

1213

16 17

TIBMQ

Queue

XCF SEND

SYNC FAIL

14

1819

15

XCF SENDDFSxxx

XCF SEND

MQPUTDFSxxx

MQCMITDFSxxx

64



Client Interface WebSphere MQ – CM1 SL1 – Syncpoint Fail












65



Client Interface

WebSphere MQ – CM1 SL1 – Syncpoint Fail


dequeued


message





66










11. The WebSphere MQ IMS Bridge MQPUTs the reply message to the

Reply-To Queue In Syncpoint but does not commit

• If the MQPUT to the Reply-To Queue fails the message is MQPUT

to the Dead Letter Queue

67




12. The WebSphere MQ IMS Bridge sends an ACK to OTMA for the reply message


14. Syncpoint fails


• OTMA sends the DFSxxx message to WebSphere MQ

• OTMA sends the De-Allocate Confirm to WebSphere MQ

• Because this us XCF these messages can arrive in any order in WebSphere MQ


17. Syncpoint fails


68



Client Interface

WebSphere MQ – CM1 SL1 – Syncpoint Fail

18. WebSphere MQ processes the failed syncpoint

• The WebSphere MQ IMS Bridge MQBACKs the reply message

• The WebSphere MQ IMS Bridge MQPUTs the DFSxxx message to the

Reply-to Queue

• The WebSphere MQ IMS Bridge MQCMITs the DFSxxx message on the

Reply-to Queue

19. The WebSphere MQ application MQGETs the DFSxxx message from

the Reply-to Queue



OTMA Client Interface – WebSphere MQ CM1 SL1 – Client NAK

OTMA MPR

XCF SENDCM1 SL1


GU IOPCB


START SYNC

XCFSEND REPLY

MQ APPL

MQPUTIMS

BRIDGEQUEUE

MQ IMS BRIDGE

MQGETXCF SEND

1

2

3

46

7

9

XCF SENDACK

5

8

IMSMessageQueue

MQCMITDEQUEUE

INPUT

TIB

MQQueue

GET MSG

XCF SEND

10




OTMA MPR

PROCESSSYNC

APPLABEND

XCFSEND REPLY


ABORT

XCF SEND NAK

FREE TIB

MQ APPL

MQGETREPLYTOQUEUE

(DFSxxx)

MQ IMS BRIDGE

MQPUTRTQAND DLQFAIL

11

1213

16 17

TIBMQ

Queue

XCF SEND

SYNC FAIL

14

1819

15

XCF SENDDFSxxx

XCF SEND

MQPUTDFSxxx

MQCMITDFSxxx

71



Client Interface WebSphere MQ – CM1 SL1 – Client NAK





WebSphere MQ sends the input message to IMS OTMA via XCF







72



Client Interface

WebSphere MQ – CM1 SL1 – Client NAK


dequeued


message





73










11. The WebSphere MQ IMS Bridge tries to MQPUT the reply message to

the Reply-To Queue but it fails

• WebSphere MQ tries to MQPUT the reply message to the Dead Letter

Queue but it fails

74




12. The WebSphere MQ IMS Bridge sends a NAK to OTMA for the reply message


14. Syncpoint fails


• OTMA sends the DFSxxx message to WebSphere MQ

• OTMA sends the De-Allocate Abort to WebSphere MQ

• Because this us XCF these messages can arrive in any order in WebSphere MQ


17. Syncpoint fails


75



Client Interface


18. The WebSphere MQ IMS Bridge tries to MQPUT and MQCMIT the

DFSxxx message to the Reply-to Queue

• If that fails the WebSphere MQ IMS Bridge tries to MQPUT and MQCMIT

the DFSxxx message to the Dead Letter Queue

• If that fails the DFSxxx message is discarded

19. The WebSphere MQ application MQGETs the DFSxxx message from

the Reply-to Queue

76




– Commit Mode 0 (CM0) - Commit-then-send

• Output is queued

• IMS sends the output after syncpoint is complete

• Queued on a control block called a QAB (Queue Anchor Block)

– The destination name is x’FEFFFFFFaaaaaaaa’

• aaaaaaaa is the address of a CLB associated with the QAB

• Not the address of the QAB control block

• OTMA always requires an ACK to dequeue the output message

– Synclevel 1

• ALTPCB output messages are always Commit Mode 0

• MQSeries calls these “asynchronous” messages

– The output is “asynchronous” from syncpoint completion

77



Client Interface

OTMA Commit Mode

– IMS V11 introduces Timeout waiting for an ACK for a CM0 SL1

output message

• The output queue is being held

– When the timeout is reached the output message causing the

hang is moved to a special timeout queue TPIPE for that

TMEMBER

• The original output queue is now free to continue

78



Client Interface

OTMA Commit Mode– The same timeout value is used for both CM0 ACK timeout and

CM1 ACK timeout

– Can be specified in seconds (0-255) in 4 ways

• In the Client Bid

• T/O= parameter in DFSYDTx

• /STA TMEMBER xxxx TIMEOUT nnn

• By message in the OTMA header

– If less than the T/O or /STA value

– The default is 120 seconds

79



Client Interface

OTMA Commit Mode– The timeout value can not be specified via Client Bid for

MQSeries or OTMA C/I

– IMS Connect has the ACKTO parameter on the Datastore

control card which is the value used by IMS Connect for Client

Bid

– Can be turned off by T/O=0

or /STA TMEMBER xxxx

TIMEOUT 0

• Can not be turned off for a message using the OTMA header or by

Client Bid

80



Client Interface

OTMA Commit Mode

– The OTMA client can specify a CM0 ACK timeout TPIPE name

during Client Bid

• Currently only supported by IMS Connect

• The default TPIPE name is DFS$$TOQ

• IMS Connect has the CM0ATOQ parameter on the HWS control

card in the HWSCFGxx member and on the Datastore control card

– This specifies the TPIPE name

81



Client Interface

OTMA Commit Mode

– For IMS Connect the message is queued to a Hold queue

• If a Reroute TPIPE name was specified on the input message the

output message is queued to that TPIPE

• If a Reroute TPIPE name was not specified the message is

queued to the TPIPE name specified in the CM0ATOQ parameter

– If this parameter was not set the message is queued to TPIPE DFS$

$TOQ



OTMA Client Interface – IMS ConnectCM0 SL1 – ACK



ALLOC TIBCALL RACFISRT MSGENQ MSGFREE TIB GU IOPCB

ISRT IOPCB

ENQ REPLYON TEMP Q

START SYNC

12 3 4

5

7

IMSMessageQueue

SVT

CONNECTWRITEREAD

6

(ALLOCSVT)

XCF SEND

TIB

ENQ REPLYON QAB

PROCESSSYNC

8

9SYNC OK

10

ENDSYNC

11



OTMA Client Interface – IMS ConnectCM0 SL1 – ACK


SVT

TCP/IP WRITEREPLY

TCP/IP WRITEACK

PROCESSREPLY

15

18

SEND ACKREAD

SENDREPLYREAD

XCF SEND

XCF SENDACK

16

17

GET REPLY

12XCF SENDREPLY

XCF SEND

13

IMSMessageQueue

ANCHORREPLYON SVT

14

DEQ REPLY

19

84



Client Interface IMS Connect – CM0 SL1 – ACK


2. IMS Connect builds a control block for the Client (SVT) if it does not

already exist and sends the input message to IMS OTMA via XCF

• The TPIPE name is the Client ID






• Frees the TIB after the message is enqueued

85





message


6. The message is enqueued on a temporary queue



9. OTMA enqueues the reply message on a QAB (Queue Anchor Block)

10. Syncpoint is successful


86




12. IMS OTMA does an internal GU to retrieve the reply message






17. The IMS Connect Client can process the message


19. OTMA de-queues the reply message






ALLOC TIBCALL RACFISRT MSGENQ MSGFREE TIB GU IOPCB

ISRT IOPCB

ENQ REPLYON TEMP Q

START SYNC

12 3 4

5

7

IMSMessageQueue

SVT

CONNECTWRITEREAD

6

(ALLOCSVT)

XCF SEND

TIB

ENQ REPLYON QAB

PROCESSSYNC

8

9SYNC OK

10

ENDSYNC

11





SVT

TCP/IP WRITEREPLY

TCP/IP WRITENAK

NOTIFYUSER

15

18

SEND NAKREAD

SENDREPLYREAD

XCF SEND

XCF SENDNAK

16

17

GET REPLY

12XCF SENDREPLY

XCF SEND

13

IMSMessageQueue

ANCHORREPLYON SVT

14

RE-QUE/PURGE/

REROUTE REPLY

19

89





2. IMS Connect builds a control block for the Client (SVT) if it does not

already exist and sends the input message to IMS OTMA via XCF

• The TPIPE name is the Client ID







90





message


6. The message is enqueued on a temporary queue






91









16. The IMS Connect Client gets the reply message and sends a NAK

17. The IMS Connect Client notifies the User

18. IMS Connect sends the NAK to OTMA

19. OTMA re-queues, or purges, or reroutes the reply message



OTMA Client Interface – WebSphere MQ CM0 SL1 – ACK

OTMA MPR

XCF SENDCM0 SL1

ALLOC TIBCALL RACFISRT MSGENQ MSGSEND ACKFREE TIB

GU IOPCB

ISRT IOPCB

START SYNC

MQ APPL

MQPUTIMS

BRIDGEQUEUE

MQ IMS BRIDGE

MQGETXCF SEND

1

2

3

46

XCF SENDACK

5

8

IMSMessageQueue

MQCMITDEQUEUE

INPUT

MQQueue

TIB

ENQ REPLYON TEMP Q

PROCESSSYNC

ENQ REPLYON QAB

SYNC OK ENDSYNC

7

9

10

1112



OTMA Client Interface – WebSphere MQ CM0 SL1 – ACK

OTMA MPR

XCF SEND ACK

MQ APPL

MQGETREPLYTOQUEUE

MQ IMS BRIDGE

MQPUTRTQ(OR DLQ)OK

MQCMIT

15

17

MQQueue

XCF SEND

16

19

IMSMessageQueue

GET REPLY

13XCF

SEND REPLY XCF SEND

18

DEQ REPLY

14

94



Client Interface WebSphere MQ – CM0 SL1 – ACK


2. The IMS Bridge code in the WebSphere MQ Queue Manager has an outstanding MQGET In Syncpoint for the IMS Bridge Queue and receives input the message









95




4. WebSphere MQ does an MQCMIT and the input message is de-queued



7. The reply message is enqueued on a temporary queue






96






15. The WebSphere MQ IMS Bridge MQPUTs the reply message to the Reply-To Queue In Syncpoint

• If the MQPUT to the Reply-To Queue fails the message is MQPUT to the Dead Letter Queue

16. The WebSphere MQ IMS Bridge MQCMITs the reply message

17. The WebSphere MQ IMS Bridge sends an ACK to OTMA for the reply message

18. OTMA de-queues the reply message

19. The WebSphere MQ application MQGETs the reply message from the Reply-to Queue




OTMA MPR

XCF SENDCM0 SL1

ALLOC TIBCALL RACFISRT MSGENQ MSGSEND ACKFREE TIB

GU IOPCB

ISRT IOPCB

START SYNC

MQ APPL

MQPUTIMS

BRIDGEQUEUE

MQ IMS BRIDGE

MQGETXCF SEND

1

2

3

46

XCF SENDACK

5

8

IMSMessageQueue

MQCMITDEQUEUE

INPUT

MQQueue

TIB

ENQ REPLYON TEMP Q

PROCESSSYNC

ENQ REPLYON QAB

SYNC OK ENDSYNC

7

9

10

1112




OTMA MPR

XCF SEND NAK

MQ APPLMQ IMS BRIDGE

MQPUTRTQANDDLQFAIL

15

16

MQQueue

XCF SEND

IMSMessageQueue

GET REPLY

13XCF

SEND REPLY XCF SEND

17

RE-ENQ REPLY

14

99





2. The IMS Bridge code in the WebSphere MQ Queue Manager has an outstanding MQGET In Syncpoint for the IMS Bridge Queue and receives input the message









100




4. WebSphere MQ does an MQCMIT and the input message is dequeued



7. The reply message is enqueued on a temporary queue






101



Client Interface




15. The MQPUT to the Reply-To Queue and the Dead Letter Queue both

fail

16. The WebSphere MQ IMS Bridge sends a NAK to OTMA for the reply

message

17. OTMA re-queues the reply message on the QAB

• Purge and re-route options are not supported

102



Client Interface

Additional flows

– For completeness there are four additional flows

• OTMA NAK input message

– IMS Connect

– WebSphere MQ

• ABEND before syncpoint

– IMS Connect

• Send DFSxxx instead of reply message

– WebSphere MQ

• Send DFSxxx instead of reply message



OTMA Client Interface – IMS ConnectOTMA NAK Input Message

ICON CLIENT ICON OTMATCP/IP WRITE

INPUTXCF SEND

INPUT PROCESSINPUTFAILS

XCF SENDNAK

12

3

5

SVT

CONNECTWRITEREAD

4

NAKINPUT

MESSAGE

(ALLOCSVT)

XCF SEND

XCF SEND

DELETE TIB

6

SENDERROR

(REQSTS)

TCP/IP WRITEERROR

KEEP/FREESVT

8

PROCESSERROR

9

7

104



Client Interface IMS Connect – OTMA NAK Input Message

1. An IMS Connect Client sends an input message to ICON


3. OTMA processes the input message but there is an error

• TIB/TPIPE flood control

• No such transaction code

• Transaction stopped

• Security failed

• Message expired

• And many more

105



Client Interface IMS Connect – OTMA NAK Input Message

4. OTMA NAKs the input message with a Sense Code and Reason Code

• TMAMCSNC and TMAMCRSC in the OTMA header

• See macro DFSYMSG for a complete list of sense codes

5. OTMA sends the NAK to IMS Connect via XCF

6. OTMA deletes the TIB control block if it was allocated

7. IMS Connect sends an error message to the IMS Connect Client

• *REQSTS* if using IMS Connect sample User Message Exits

8. If this is a persistent socket IMS Connect keeps the connection open and does not free the SVT control block

9. The ICON Client processes the error



OTMA Client Interface – WebSphere MQ OTMA NAK Input Message

OTMA

XCF SENDINPUT

PROCESSINPUTFAILS

MQ APPL

MQPUTIMS

BRIDGEQUEUE

MQ IMS BRIDGE

MQGETXCF SEND

1

2

3

7

4XCF SENDNAK

MQPROCESS

NAK

MQQueue

NAKINPUT

MESSAGE

XCF SEND

6

DELETE TIB

5

Input QueueReply-to Queue

Dead Letter Queue

107



Client Interface WebSphere MQ – OTMA NAK Input Message






3. OTMA processes the input message but there is an error• TIB/TPIPE flood control

• No such transaction code

• Transaction stopped

• Security failed

• Message expired

• And many more

108



Client Interface

WebSphere MQ – OTMA NAK Input Message4. OTMA NAKs the input message with a Sense Code and Reason

Code

• TMAMCSNC and TMAMCRSC in the OTMA header

• See macro DFSYMSG for a complete list of sense codes

5. OTMA sends the NAK to WebSphere MQ via XCF

6. OTMA deletes the TIB control block if it was allocated

7. WebSphere MQ processes the NAK

109





• If it was an invalid message before sending to OTMA

– The input message goes on the DLQ

– A warning is sent to the system console

• If IMS rejected the message with sense 001A

– The DFS message from IMS goes to the Reply-to Queue

– If the DFS message can not be put on the Reply-to Queue it goes to the DLQ

– The input message goes to the DLQ

• IMS rejected the message due to a message error

– The input message goes on the DLQ

– A warning message is sent to the system console

110





• If IMS rejected the message for other reasons

– The input message goes back to the original queue

– A warning is sent to the system console

• If there is a queue problem

– The queue is Stopped

• If there is an IMS Bridge problem

– The IMS Bridge is stopped

111




– Commit Mode 1 - Send-then-commit• A CM1 input message which does ISRT - PURG - ISRT - PURG -

ISRT - PURG to the IOPCB will generate one multi-segment output message

– Not 3 single segment output messages

– A CM0 input would have generated 3 single-segment messages

– The maximum size of the output message is 32K

• If it is larger the transaction will ABEND – U0119

• In IMS V10 (PK60549) you have the option to make CM0 messages also ignore the PURG call and generate one multi-segment message

– Specified in the OTMA header for an input message

• Set bit x’02’ (TMAMIPRG) on in flag TMAMHCFL

– Supported by IMS Connect and ITRA

112



Client Interface

OTMA Commit Mode


• CM1 messages can not be sent on SYNChronized TPIPE’s

– They will be NAK’ed if they are sent this way

• CM1 input messages are ALWAYS treated as non-recoverable

– They will be discarded during IMS restart if they have not processed

yet

• A CM1 transaction that message switches can produce CM0 output

or DFS2082 messages

– This is very complicated

– The Appendix to this presentation explains this in detail

IMS Symposium 2012 – Session A07


IMS 12 – DFS2082 for CM0 Messages CM1 (Send-then-Commit) transactions rely on DFS2082

– To end the outstanding wait if the IMS transaction does not send IOPCB reply

Conversion from the use of CM1 to CM0 (Commit-then-send)– For remote programs waiting for a reply

• May result in a hang until timeout if there is no IOPCB reply

Enhancement– A new commit-then-send (CM0) optional flag to request DFS2082

• Specified on an input CM0 transaction message– Triggers OTMA to send the DFS2082 message if

• The IMS application does not reply to the IOPCB• Nor message switches to another transaction

114



Appendix

Processing CM1 Input Messages

115




OTMA Processing of CM1 input messages can be confusing– Especially if program-to-program message switches are

involved

– CM1 input messages may produce CM0 IOPCB output messages which may require special processing by the OTMA client

– CM1 input messages may produce message DFS2082 RESPONSE MODE TRANSACTION TERMINATED WITHOUT REPLY for NONRESPONSE transactions

– There are also special considerations for conversational transactions

116




Commit Mode 1 input messages are always treated

as being IMS Response Mode

– If the message is sent with Commit Mode 1 (send-then-commit)

then IMS will treat the input transaction as RESPONSE mode

even if it is defined as NONRESPONSE

– If the application does not reply to the IOPCB and does not do a

program-to-program message switch then IMS will respond with

a DFS2082 RESPONSE MODE TRANSACTION TERMINATED

WITHOUT REPLY message

117




When a Commit Mode 1 transaction does program-

to-program message switches to one or more

transactions those message-switched-to

transactions can be scheduled in one of two ways

– “Synchronously”

– “Asynchronously”

– At most only one of the message-switched-to transactions will

be scheduled synchronously

118



Processing CM1 Input Messages Synchronously scheduled message-switched-to

transaction – This transaction “owns the TIB” – It has the responsibility of replying to the IOPCB or doing a

program-to-program message switch to a transaction which is scheduled synchronously and replies to the IOPCB

– If it does reply to the IOPCB the output will be CM1– If this transaction does not reply to the IOPCB and does not do a

program-to-program message switch then IMS will respond with a DFS2082 RESPONSE MODE TRANSACTION TERMINATED WITHOUT REPLY message

• This is unlike non-OTMA transactions where only the FIRST transaction scheduled can get the DFS2082

– If this transaction does not reply to the IOPCB and does do program-to-program message switches then one of its children MAY be scheduled synchronously

119




Asynchronously scheduled message-switched-to

transaction – If it does reply to the IOPCB the output will be CM0

– If this transaction does not reply to the IOPCB and does not do a

program-to-program message switch there will be no DFS2082

RESPONSE MODE TRANSACTION TERMINATED WITHOUT

REPLY message

– If this transaction does program-to-program message switches

then all of the message-switched-to transactions will be

scheduled asynchronously



Processing CM1 Input Messages – Passing the TIB

CM1Input

MessageSYNC

ASYNC

GUIOPCB

ISRTALTPCB

ISRTALTPCB

ISRTALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTALTPCB

ISRTALTPCB

ISRTALTPCB

ASYNC

ASYNC

ASYNC

ASYNC

ISRTALTPCB

SYNC

GUIOPCB

GUIOPCB

ISRTALTPCB

ISRTALTPCB

ISRTALTPCB

ISRTALTPCB

SYNC

ASYNC

ASYNC

ASYNC

TIB

TIB

121




Whether a message-switched-to transaction is

scheduled “synchronously” or “asynchronously”

depends on several factors

– IOPCB output from the CM1 input transaction

– EXPRESS or Non-EXPRESS ALTPCB’s

– The OTMAASY parameter

– RESPONSE or NONRESPONSE transaction

– When the message-switched-to transaction is scheduled

– The order of the message inserts to the ALTPCB

122




If the original CM1 input transaction (or

synchronous message-switched-to transaction)

replies to the IOPCB

– The IOPCB output will be CM1

– If the transaction also does program-to-program message

switches then all of the message-switched-to transactions will

be scheduled asynchronously

• IOPCB output from all of the message-switched-to transactions will

be CM0



Processing CM1 Input Messages – Input Transaction Reply to IOPCB

ASYNC

ASYNC

CM1Input

Message

GUIOPCB

ISRTALTPCB

ISRTIOPCB

CM1

ISRTALTPCB

ISRTALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

ASYNC

CM0

CM0

CM0

124






does not reply to the IOPCB and does program-to-

program message switches using only EXPRESS

ALTPCB’s

– All of the message-switched-to transactions will be scheduled

asynchronously

• IOPCB output from all of the message-switched-to transactions will

be CM0

– The TIB will be freed and will not be orphaned

125



Processing CM1 Input Messages – All EXPRESS ALTPCB

No CM1 output TIB is freed

ASYNC

ASYNC

CM1Input

Message

GUIOPCB

ISRTEXPRESSALTPCB

ISRTEXPRESSALTPCB

ISRTEXPRESSALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

ASYNC

CM0

CM0

CM0

126






does not reply to the IOPCB and does program-to-

program message switches using non-EXPRESS

ALTPCB’s or a mix of EXPRESS and non-EXPRESS

ALTPCB’s

– The OTMAASY parameter comes into effect

– The TIB will be not freed and may become orphaned

127



Processing CM1 Input Messages – Non-EXPRESS or (EXPRESS + Non-EXPRESS)

Maybe CM1 output

OTMAASY is used

TIB is not freed

?

?

CM1Input

Message

GUIOPCB

ISRTNON-EXPALTPCB

ISRTNON-EXPALTPCB

ISRTEXPRESSALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

?

CM?

CM?

CM?

128




If OTMAASY=N is specified (or defaulted) then ANY

message-switched-to transaction – RESPONSE or

NONRESPONSE – is eligible to be scheduled

synchronously

– If any message-switched-to transactions schedule before the

CM1 input transaction (or synchronous message-switched-to

transaction) has completed

• They will be scheduled asynchronously

– They can not get the TIB

• It is still owned by the running transaction

• These were inserted with EXPRESS ALTPCB’s

129



Processing CM1 Input Messages – OTMAASY=N – Scheduled Before Tran Ends

If scheduled before first transaction ends it is asynchronous

IOPCB output is CM0

?

?

CM1Input

Message

GUIOPCB

ISRTEXPRESSALTPCB

ISRTNON-EXPALTPCB

ISRTEXPRESSALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

ASYNC

CM?

CM0

CM?

ScheduledBefore

FirstTranEnds

ScheduledAfterFirstTranEnds


130




If OTMAASY=N is specified (or defaulted)

– The first message-switched-to transaction (RESPONSE or NONRESPONSE) to be scheduled after the CM1 input transaction (or synchronous message-switched-to transaction) has completed will be scheduled synchronously

• This transaction owns the TIB

• If this transaction replies to the IOPCB the output will be CM1

• If this transaction does not reply to the IOPCB and does not do program-to-program message switches then OTMA will return a DFS2082 message

– All other message-switched-to transactions will be scheduled asynchronously

• Their IOPCB output will be CM0

131



Processing CM1 Input Messages – OTMAASY=N – First Scheduled Gets TIB

First transaction scheduled after the switching transaction ends gets the TIB

Switch is synchronous

IOPCB output is CM1

All others are ASYNC

ASYNC

SYNC

CM1Input

Message

GUIOPCB

ISRTEXPRESSALTPCB

ISRTNON-EXPALTPCB

ISRTEXPRESSALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

ASYNC

CM0

CM0

CM1

ScheduledBefore

FirstTranEnds

ScheduledSecond

AfterTranEnds

ScheduledFirstAfterTranEnds

TIB

132




If OTMAASY=Y is specified then ONLY RESPONSE

message-switched-to transactions are eligible to be

scheduled synchronously

– If any message-switched-to transactions schedule before the

CM1 input transaction (or synchronous message-switched-to

transaction) has completed

• They will be scheduled asynchronously

– They can not get the TIB

• It is still owned by the running transaction

• These were inserted with EXPRESS ALTPCB’s

133



Processing CM1 Input Messages – OTMAASY=Y – Scheduled Before Tran Ends

If scheduled before first transaction ends it is asynchronous

IOPCB output is CM0

?

?

CM1Input

Message

GUIOPCB

ISRTEXPRESSALTPCB

ISRTNON-EXPALTPCB

ISRTEXPRESSALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

ASYNC

CM?

CM0

CM?

ScheduledBefore

FirstTranEnds



RESPONSE

RESPONSE

NONRESPONSE

134



Processing CM1 Input Messages If OTMAASY=Y is specified

– The first RESPONSE message-switched-to transaction to be scheduled after the CM1 input transaction (or synchronous message-switched-to transaction) has completed will be scheduled synchronously

• This transaction owns the TIB

• If this transaction replies to the IOPCB the output will be CM1

• If this transaction does not reply to the IOPCB and does not do program-to-program message switches then OTMA will return a DFS2082 message

– All other message-switched-to transactions will be scheduled asynchronously

• Their IOPCB output will be CM0

135



Processing CM1 Input Messages – OTMAASY=Y – First RESPONSE Sched Gets TIB

First RESPONSE transaction scheduled after the switching transaction ends gets the TIB


IOPCB output is CM1


SYNC

ASYNC

CM1Input

Message

GUIOPCB

ISRTEXPRESSALTPCB

ISRTNON-EXPALTPCB

ISRTEXPRESSALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

ASYNC

CM1

CM0

CM0

ScheduledBefore

FirstTranEnds

ScheduledSecond

AfterTranEnds


RESPONSE

RESPONSE

NONRESPONSE

TIB

136




If OTMAASY=Y is specified

– If all message-switched-to transactions are NONRESPONSE or

schedule before the CM1 input transaction (or synchronous

message-switched-to transaction) ends

• There will not be a synchronous transaction scheduled

– There will be no CM1 IOPCB output

– There will be no DFS2082 message

• THE TIB WILL BE ORPHANED AND NEVER DELETED

– Until an IMS Cold start

137



Processing CM1 Input Messages – OTMAASY=Y – All NONRESPONSE After End

If all NONREPONSE after transaction ends no one gets the TIB

All are ASYNC All IOPCB output

is CM0 No DFS2082 TIB is orphaned

until IMS COLD start

ASYNC

ASYNC

CM1Input

Message

GUIOPCB

ISRTEXPRESSALTPCB

ISRTNON-EXPALTPCB

ISRTEXPRESSALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

ASYNC

CM0

CM0

CM0

ScheduledBefore

FirstTranEnds

ScheduledSecond

AfterTranEnds


NONRESPONSE

RESPONSE

NONRESPONSE

138




If OTMAASY=S is specified then the decision as to

which transaction is scheduled synchronously gets

made at ISRT ALTPCB time – not GU IOPCB time

– The first transaction ISRT to a non-Express ALTPCB will be

scheduled synchronously

• It can be RESPONSE or NONRESPONSE

– All other transactions inserted to ALTPCBs will be scheduled

asynchronously

• Non-Express PCBs

• Express PCBs

139



Processing CM1 Input Messages – OTMAASY=S – First Non-EXPRESS ISRT

First Non-EXPRESS ALTPCB ISRT gets the TIB


IOPCB output is CM1


SYNC

ASYNC

CM1Input

Message

GUIOPCB

SECONDISRT

EXPRESSALTPCB

THIRDISRT

NON-EXPALTPCB

FIRSTISRT

EXPRESSALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

ASYNC

CM1

CM0

CM0

ScheduledBefore

FirstTranEnds

ScheduledSecond

AfterTranEnds


NONRESPONSE

RESPONSE

RESPONSE

TIB

140




If OTMAASY=S is specified

– If all message-switched-to transactions inserted to EXPRESS

ALTPCBs

• There will not be a synchronous transaction scheduled

– There will be no CM1 IOPCB output

– There will be no DFS2082 message

• THE TIB WILL BE ORPHANED AND NEVER DELETED

– Until an IMS Cold start

141



Processing CM1 Input Messages – OTMAASY=S – No Non-EXPRESS ISRT

If no Non-EXPRESS no one gets the TIB

All are ASYNC All IOPCB output is

CM0 No DFS2082 TIB is orphaned

until IMS COLD start

ASYNC

ASYNC

CM1Input

Message

GUIOPCB

SECONDISRT

EXPRESSALTPCB

THIRDISRT

EXPRESSALTPCB

FIRSTISRT

EXPRESSALTPCB

GUIOPCB

GUIOPCB

GUIOPCB

ISRTIOPCB

ISRTIOPCB

ISRTIOPCB

ASYNC

CM0

CM0

CM0

ScheduledBefore

FirstTranEnds

ScheduledSecond

AfterTranEnds


NONRESPONSE

RESPONSE

RESPONSE

142




Conversational Transactions

– Only the message-switched-to continuation of the conversation

will be scheduled synchronously

– All other message-switched-to transactions will be scheduled

asynchronously

143




If a CM1 message is sent via MSC to a back-end IMS

and the transaction there does not reply to the

IOPCB

– There is no DFS2082 message back to the client

– The OTMA client can hang

– The input TIB and ITASK will never be freed in the front-end

system

• Storage will fill up

144




/DIS OTMA or /DIS TMEMBER xxxx (or ALL) shows

the number of TIBS for a TMEMBER

/DIS OTMA

GROUP/MEMBER XCF-STATUS USER-STATUS SECURITY TIB MAX SMEM

DRUEXIT T/O TPCNT ACEEAGE

OTMAZZS

-IMSA ACTIVE SERVER FULL

-IMSA N/A 0

-CSQ1 ACTIVE ACCEPT TRAFFIC NONE 150 200

-CSQ1 CSQ1DRU0 5 55 999999

-ICON1 ACTIVE ACCEPT TRAFFIC CHECK 0 5000 SM01

-ICON1 HWSYDRU0 10 122 999999

145




/DIS TMEMBER xxxx TPIPE yyyy can show if CM0

IOPCB messages were sent for CM1 input

– For ICON CM1 TPIPE names are the Port number

– ENQCT and DEQCT are only for output messages

– CM1 output messages are not queued so ENQCT and DEQCT

should be 0 if only CM1 output

– If CM0 output is sent on a CM1 TPIPE ENQCT and DEQCT ≠ 0/DIS TMEMBER ICON1 TPIPE ALL

MEMBER/TPIPE ENQCT DEQCT QCT INPCT STATUS SMEM

ICON1

-6001 0 0 0 4956 TRA SM01

-6002 5 5 0 65534

146




/DIS TMEMBER xxxx TPIPE yyyy can show if CM0

IOPCB messages were sent for CM1 input

– For WebSphere MQ CM1 TPIPE names are xxx8nnnn

• xx8nnnnn for MQ Shared Queues

– If CM0 output is sent on a CM1 TPIPE ENQCT and DEQCT ≠ 0

/DIS TMEMBER ICON1 TPIPE ALL

MEMBER/TPIPE ENQCT DEQCT QCT INPCT STATUS SMEM

ICON1

-CSQ80034 0 0 0 4956

-CSQ80054 5 5 0 65534

147



Consequences

What are the consequences of CM1 IOPCB input

producing CM0 IOPCB output?

– WebSphere MQ

• Nothing – the output will go on the Reply-to Queue

148



Consequences

What are the consequences of CM1 IOPCB input

producing CM0 IOPCB output?

– IMS Connect

• The CM0 IOPCB output will be NAK’ed and put on the Hold Queue

with a TPIPE name of the Client ID

• If the Reroute option was specified on the input message the CM0

IOPCB output will be put on the reroute queue

– Reroute TPIPE from the input message or the default reroute TPIPE

name for the datastore or HWS$DEF (one $ is correct)

• If there was no CM1 IOPCB output the message will timeout in IMS

Connect

149



Consequences

The OTMAASY parameter is specified at the IMS

system level

– If things are working now – do not change it

– If you have a specific problem it may have to be changed to fix

some applications

• BUT – it may break other applications which are running fine now

– BE CAREFUL!!!!!

150



Conclusion

There are many considerations for OTMA messages

Careful planning is required

Documents

Understanding ims otma commit mode and synclevel