Understanding IMS OTMA Commit Mode - IMS UG October 2012 Hartford
Upcoming SlideShare
Loading in...5
×
 

Understanding IMS OTMA Commit Mode - IMS UG October 2012 Hartford

on

  • 800 views

 

Statistics

Views

Total Views
800
Views on SlideShare
800
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Understanding IMS OTMA Commit Mode - IMS UG October 2012 Hartford Understanding IMS OTMA Commit Mode - IMS UG October 2012 Hartford Presentation Transcript

  • Understanding IMS OTMA Commit Mode and Synchronization Level IMS User GroupSteve Nathansnathan@us.ibm.com ©2012 IBM Corporation
  • IMS Regional User GroupDisclaimer © 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 BusinessMachines Corporation in the United States, other countries, or both. If these and other IBM trademarked termsare marked on their first occurrence in this information with a trademark symbol (® or ™), these symbolsindicate 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 IBMtrademarks is available on the Web at “Copyright and trademark information” atwww.ibm.com/legal/copytrade.shtml Understanding IMS OTMA Commit Mode and Synchronization Level 2
  • IMS Regional User GroupIntroduction 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. Understanding IMS OTMA Commit Mode and Synchronization Level 3
  • IMS Regional User GroupIntroduction 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 Understanding IMS OTMA Commit Mode and Synchronization Level 4
  • IMS Regional User Group SERVER z/OS,WIN, AIX, SUN, … z/OS z/OSIMS Control Center Any Websphere TCP/IP ITRA SCI Websphere App Websphere IMS TM Resource OM Adapter ITRA MFS Web XCF IMS Services PC ICON XCF TCP/IP ICON IMS SOAP Gateway RYO TCP/IP Client OTMA XCF TCP/IP Application IMS BRIDGE IMS BRIDGE MQSeries SNAMQSeries TN3270 MQSeries BTAM <V10 VTAM LU1 VTAM LU2 LU 6.1 LU 6.2End User Understanding IMS OTMA Commit Mode and Synchronization Level 5
  • IMS Regional User GroupIntroduction XCF GROUP ICON1 GRNAME=GR1 IMSA TMEMBER1 TPIPEs OTMANM=IMSAOTMA DS1 TMEMBER2 DS2 DS3 TMEMBER3 Names are not defined XCF GROUP in any IMS GEN GRNAME=GR2 MQSeries IMSB OTMANM=IMSBOTMA IMS Bridge Queue TPIPEs Storage TMEMBER4 Class Understanding IMS OTMA Commit Mode and Synchronization Level 6
  • IMS Regional User GroupTPIPEs (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 Understanding IMS OTMA Commit Mode and Synchronization Level 7
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 8
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 9
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 10
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 11
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 12
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 13
  • IMS Regional User GroupClient Interface OTMA Commit Mode – Commit Mode 1 - Send-then-commit • 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” – 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 Understanding IMS OTMA Commit Mode and Synchronization Level 14
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL0 – Syncpoint OK ICON CLIENT ICON OTMA MPR TCP/IP WRITE IMS CONNECT CM1 SL0 Message WRITE XCF SEND ALLOC TIB Queue (ALLOC READ CM1 SL0 CALL RACF SVT) XCF SEND ISRT MSG 1 ENQ MSG GU IOPCB 2 3 4 SVT TIB ISRT IOPCB ANCHOR 5 MSG on TIB 6 START SYNC 7 GET MSG 8 XCF SEND REPLY XCF SEND ANCHOR REPLY 9 ON SVT 10 Understanding IMS OTMA Commit Mode and Synchronization Level 15
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL0 – Syncpoint OK ICON CLIENT ICON OTMA MPR SVT TIB PROCESS SYNC 11 SYNC OK 12 XCF SEND XCF SEND 13 DEALLOCATE CONFIRM FREE TIB SEND REPLY 14 TCP/IP WRITE SYNC REPLY 16 COMPLETE 15 KEEP/FREE PROCESS SVT REPLY 17 18 Understanding IMS OTMA Commit Mode and Synchronization Level 16
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 17
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL0 – Syncpoint OK 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) Understanding IMS OTMA Commit Mode and Synchronization Level 18
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 19
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL0 – Syncpoint OK 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 Understanding IMS OTMA Commit Mode and Synchronization Level 20
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL0 – Syncpoint OK 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 Understanding IMS OTMA Commit Mode and Synchronization Level 21
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL0 – Syncpoint OK – 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=0001 5607 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=0001 07 Application Terminate TranCode=TRANA Region=0001 Understanding IMS OTMA Commit Mode and Synchronization Level 22
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL0 – Syncpoint Fail ICON CLIENT ICON OTMA MPR TCP/IP WRITE IMS CONNECT CM1 SL0 Message WRITE XCF SEND ALLOC TIB Queue (ALLOC READ CM1 SL0 CALL RACF SVT) XCF SEND ISRT MSG 1 ENQ MSG GU IOPCB 2 3 4 SVT TIB ISRT IOPCB ANCHOR 5 MSG on TIB 6 START SYNC 7 GET MSG 8 XCF SEND REPLY XCF SEND ANCHOR REPLY 9 ON SVT 10 Understanding IMS OTMA Commit Mode and Synchronization Level 23
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL0 – Syncpoint Fail ICON CLIENT ICON OTMA MPR SVT TIB PROCESS SYNC 11 SYNC FAIL 12 XCF SEND XCF SEND DFSxxx XCF SEND XCF SEND DISCARD DEALLOCATE REPLY ABORT 13 SEND FREE TIB DFSxxx APPL 14 ABEND TCP/IP WRITE 16 DFSxxx 15 KEEP/FREE PROCESS SVT DFSxxx 17 18 Understanding IMS OTMA Commit Mode and Synchronization Level 24
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL0 – Syncpoint Fail 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 • Enqueues the input message on the transaction queue Understanding IMS OTMA Commit Mode and Synchronization Level 25
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL0 – Syncpoint Fail 4. The IMS transaction does a GU to the IOPCB to retrieve the input message 5. The IMS transaction ISRTs the reply message to the IOPCB 6. The reply message is anchored on the TIB 7. The IMS application reaches a syncpoint (GU IOPCB, termination) 8. IMS OTMA retrieves the reply message from the message queue 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 Understanding IMS OTMA Commit Mode and Synchronization Level 26
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL0 – Syncpoint Fail 11. Syncpoint proceeds 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 Understanding IMS OTMA Commit Mode and Synchronization Level 27
  • IMS Regional User GroupClient 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 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 DSFxxx message Understanding IMS OTMA Commit Mode and Synchronization Level 28
  • IMS Regional User GroupClient Interface OTMA Commit Mode – Commit Mode 1 - Send-then-commit • 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 Understanding IMS OTMA Commit Mode and Synchronization Level 29
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL1 – ACK – Syncpoint OKICON CLIENT ICON OTMA MPR TCP/IP WRITE IMS CONNECT CM1 SL1 Message WRITE XCF SEND ALLOC TIB Queue (ALLOC READ CM1 SL1 CALL RACF SVT) XCF SEND ISRT MSG 1 ENQ MSG GU IOPCB 2 3 4 SVT TIB ISRT IOPCB ANCHOR 5 MSG on TIB 6 START SYNC 7 GET MSG 8 XCF SEND REPLY XCF SEND ANCHOR REPLY 9 ON SVT 10 Understanding IMS OTMA Commit Mode and Synchronization Level 30
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL1 – ACK – Syncpoint OKICON CLIENT ICON OTMA MPR SVT TIB REPLY ON SVT SEND REPLY READ TCP/IP WRITE REPLY 11 SEND ACK READ 12 TCP/IP WRITE ACK HOLD REPLY XCF SEND 13 14 XCF SEND ACK Understanding IMS OTMA Commit Mode and Synchronization Level 31
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL1 – ACK – Syncpoint OKICON CLIENT ICON OTMA MPR SVT XCF SEND TIB ACK PROCESS SYNC 15 SYNC OK 16 XCF SEND XCF SEND 17 DEALLOCATE CONFIRM FREE TIB SEND TCP/IP WRITE DEALLOC 18 DEALLOCATE SYNC CONFIRM 20 COMPLETE 19 KEEP/FREE PROCESS SVT REPLY 21 22 Understanding IMS OTMA Commit Mode and Synchronization Level 32
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint OK 1. An IMS Connect Client sends a CM1 SL1 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 • Enqueues the input message on the transaction queue Understanding IMS OTMA Commit Mode and Synchronization Level 33
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint OK 4. The IMS transaction does a GU to the IOPCB to retrieve the input message 5. The IMS transaction ISRTs the reply message to the IOPCB 6. The reply message is anchored on the TIB 7. The IMS application reaches a syncpoint (GU IOPCB, termination) Understanding IMS OTMA Commit Mode and Synchronization Level 34
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint OK 8. IMS OTMA retrieves the reply message from the message queue 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 Understanding IMS OTMA Commit Mode and Synchronization Level 35
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint OK 11. IMS Connect sends the reply message to the IMS Connect Client • 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 Understanding IMS OTMA Commit Mode and Synchronization Level 36
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint OK 15. Syncpoint proceeds 16. Syncpoint completes successfully 17. OTMA sends the De-Allocate Confirm to IMS Connect 18. OTMA deletes the TIB control block 19. Syncpoint completes 20. IMS Connect sends the De-Allocate Confirm to the IMS Connect Client 21. If this is a persistent socket IMS Connect keeps the connection open and does not free the SVT control block 22. The ICON Client processes the reply message Understanding IMS OTMA Commit Mode and Synchronization Level 37
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL1 – ACK – Syncpoint FailICON CLIENT ICON OTMA MPR TCP/IP WRITE IMS CONNECT CM1 SL1 Message WRITE XCF SEND ALLOC TIB Queue (ALLOC READ CM1 SL1 CALL RACF SVT) XCF SEND ISRT MSG 1 ENQ MSG GU IOPCB 2 3 4 SVT TIB ISRT IOPCB ANCHOR 5 MSG on TIB 6 START SYNC 7 GET MSG 8 XCF SEND REPLY XCF SEND ANCHOR REPLY 9 ON SVT 10 Understanding IMS OTMA Commit Mode and Synchronization Level 38
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL1 – ACK – Syncpoint FailICON CLIENT ICON OTMA MPR SVT TIB REPLY ON SVT SEND REPLY READ TCP/IP WRITE REPLY 11 SEND ACK READ 12 TCP/IP WRITE ACK HOLD REPLY XCF SEND 13 14 XCF SEND ACK Understanding IMS OTMA Commit Mode and Synchronization Level 39
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL1 – ACK – Syncpoint FailICON CLIENT ICON OTMA MPR SVT XCF SEND TIB ACK PROCESS SYNC 15 SYNC FAIL 16 XCF SEND XCF SEND DFSxxx XCF SEND XCF SEND DISCARD DEALLOCATE REPLY ABORT 17 SEND FREE TIB DFSxxx APPL 18 ABEND TCP/IP WRITE 20 DISCARD DFSxxx 19 REPLY KEEP/FREE PROCESS SVT DFSxxx 21 22 Understanding IMS OTMA Commit Mode and Synchronization Level 40
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint Fail 1. An IMS Connect Client sends a CM1 SL1 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 • Enqueues the input message on the transaction queue Understanding IMS OTMA Commit Mode and Synchronization Level 41
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint Fail 4. The IMS transaction does a GU to the IOPCB to retrieve the input message 5. The IMS transaction ISRTs the reply message to the IOPCB 6. The reply message is anchored on the TIB 7. The IMS application reaches a syncpoint (GU IOPCB, termination) Understanding IMS OTMA Commit Mode and Synchronization Level 42
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint Fail 8. IMS OTMA retrieves the reply message from the message queue 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 Understanding IMS OTMA Commit Mode and Synchronization Level 43
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint Fail 11. IMS Connect sends the reply message to the IMS Connect Client • 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 Understanding IMS OTMA Commit Mode and Synchronization Level 44
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint Fail 15. Syncpoint proceeds 16. Syncpoint fails 17. OTMA processes the failed syncpoint • 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 18. OTMA deletes the TIB control block Understanding IMS OTMA Commit Mode and Synchronization Level 45
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – ACK – Syncpoint Fail 19. Syncpoint fails • The application abends 20. IMS Connect processes the failed syncpoint • IMS Connect discards the reply message • IMS Connect sends the DSFxxx message to the IMS Connect Client 21. If this is a persistent socket IMS Connect keeps the connection open and does not free the SVT control block 22. The ICON Client processes the failed syncpoint • The ICON Client discards the reply message • The ICON Client processes the DSFxxx message Understanding IMS OTMA Commit Mode and Synchronization Level 46
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL1 – Client NAK ICON CLIENT ICON OTMA MPR TCP/IP WRITE IMS CONNECT CM1 SL1 Message WRITE XCF SEND ALLOC TIB Queue (ALLOC READ CM1 SL1 CALL RACF SVT) XCF SEND ISRT MSG 1 ENQ MSG GU IOPCB 2 3 4 SVT TIB ISRT IOPCB ANCHOR 5 MSG on TIB 6 START SYNC 7 GET MSG 8 XCF SEND REPLY XCF SEND ANCHOR REPLY 9 ON SVT 10 Understanding IMS OTMA Commit Mode and Synchronization Level 47
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL1 – Client NAK ICON CLIENT ICON OTMA MPR SVT TIB REPLY ON SVT SEND REPLY READ TCP/IP WRITE REPLY 11 SEND NAK READ 12 TCP/IP WRITE NAK DISCARD REPLY XCF SEND 13 14 XCF SEND NAK Understanding IMS OTMA Commit Mode and Synchronization Level 48
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM1 SL1 – Client NAK ICON CLIENT ICON OTMA MPR SVT XCF SEND TIB NAK PROCESS SYNC 15 SYNC FAIL 16 XCF SEND XCF SEND DFSxxx XCF SEND XCF SEND DISCARD DEALLOCATE REPLY ABORT 17 SEND FREE TIB DFSxxx APPL 18 ABEND TCP/IP WRITE 20 DFSxxx 19 KEEP/FREE PROCESS SVT DFSxxx 21 22 Understanding IMS OTMA Commit Mode and Synchronization Level 49
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – Client NAK 1. An IMS Connect Client sends a CM1 SL1 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 • Enqueues the input message on the transaction queue Understanding IMS OTMA Commit Mode and Synchronization Level 50
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – Client NAK 4. The IMS transaction does a GU to the IOPCB to retrieve the input message 5. The IMS transaction ISRTs the reply message to the IOPCB 6. The reply message is anchored on the TIB 7. The IMS application reaches a syncpoint (GU IOPCB, termination) Understanding IMS OTMA Commit Mode and Synchronization Level 51
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – Client NAK 8. IMS OTMA retrieves the reply message from the message queue 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 Understanding IMS OTMA Commit Mode and Synchronization Level 52
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – Client NAK 11. IMS Connect sends the reply message to the IMS Connect Client • IMS Connect waits for the ACK/NAK 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 Understanding IMS OTMA Commit Mode and Synchronization Level 53
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – Client NAK 15. Syncpoint proceeds 16. Syncpoint fails 17. OTMA processes the failed syncpoint • 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 18. OTMA deletes the TIB control block Understanding IMS OTMA Commit Mode and Synchronization Level 54
  • IMS Regional User GroupClient Interface IMS Connect – CM1 SL1 – Client NAK 19. Syncpoint fails • The application abends 20. IMS Connect processes the failed syncpoint • IMS Connect discards the reply message • IMS Connect sends the DSFxxx message to the IMS Connect Client 21. If this is a persistent socket IMS Connect keeps the connection open and does not free the SVT control block 22. The ICON Client processes the DSFxxx message Understanding IMS OTMA Commit Mode and Synchronization Level 55
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQCM1 SL1 – ACK – Syncpoint OK MQ IMS MQ APPL MQ BRIDGE OTMA MPR Queue IMS MQPUT MQGET XCF SEND ALLOC TIB Message IMS XCF SEND CM1 SL1 CALL RACF Queue BRIDGE QUEUE 2 ISRT MSG ENQ MSG SEND ACK 1 XCF SEND ACK 3 GU IOPCB MQCMIT 5 DEQUEUE TIB INPUT ISRT IOPCB 4 ANCHOR MSG on TIB 6 7 START SYNC GET MSG 8 9 XCF SEND REPLY XCF SEND 10 Understanding IMS OTMA Commit Mode and Synchronization Level 56
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQCM1 SL1 – ACK – Syncpoint OK MQ IMS MQ APPL BRIDGE OTMA MPR XCF TIB MQ SEND REPLY Queue MQPUT RTQ (OR DLQ) OK XCF SEND 11 ACK XCF SEND PROCESS SYNC 12 13 SYNC OK 14 XCF SEND XCF SEND DEALLOCATE CONFIRM 15 MQCMIT FREE TIB MQGET SYNC REPLYTO 18 16 COMPLETE QUEUE 17 19 Understanding IMS OTMA Commit Mode and Synchronization Level 57
  • IMS Regional User GroupClient 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 3. OTMA processes the input message • Allocates the TIB • Calls RACF if needed • Inserts the input message to the IMS Message Queue • Enqueues the input message on the transaction queue • Sends an ACK for the input message to WebSphere MQ Understanding IMS OTMA Commit Mode and Synchronization Level 58
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Syncpoint OK 4. WebSphere MQ does an MQCMIT and the input message is dequeued 5. The IMS transaction does a GU to the IOPCB to retrieve the input message 6. The IMS transaction ISRTs the reply message to the IOPCB 7. The reply message is anchored on the TIB 8. The IMS application reaches a syncpoint (GU IOPCB, termination) 9. IMS OTMA Retrieves the reply message from the message queue Understanding IMS OTMA Commit Mode and Synchronization Level 59
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Syncpoint OK 10. IMS OTMA sends the reply message to WebSphere MQ 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 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 Understanding IMS OTMA Commit Mode and Synchronization Level 60
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Syncpoint OK 12. The WebSphere MQ IMS Bridge sends an ACK to OTMA for the reply message 13. Syncpoint proceeds 14. Syncpoint completes successfully 15. OTMA sends the De-Allocate Confirm to WebSphere MQ 16. OTMA deletes the TIB control block 17. Syncpoint completes 18. The WebSphere MQ IMS Bridge MQCMITs the reply message 19. The WebSphere MQ application MQGETs the reply message from the Reply-to Queue Understanding IMS OTMA Commit Mode and Synchronization Level 61
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQCM1 SL1 – ACK – Syncpoint Fail MQ IMS MQ APPL MQ BRIDGE OTMA MPR Queue IMS MQPUT MQGET XCF SEND ALLOC TIB Message IMS XCF SEND CM1 SL1 CALL RACF Queue BRIDGE QUEUE 2 ISRT MSG ENQ MSG SEND ACK 1 XCF SEND ACK 3 GU IOPCB MQCMIT 5 DEQUEUE TIB INPUT ISRT IOPCB 4 ANCHOR MSG on TIB 6 7 START SYNC GET MSG 8 9 XCF SEND REPLY XCF SEND 10 Understanding IMS OTMA Commit Mode and Synchronization Level 62
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQCM1 SL1 – ACK – Syncpoint Fail MQ IMS MQ APPL BRIDGE OTMA MPR XCF TIB MQ SEND REPLY Queue MQPUT RTQ (OR DLQ) OK XCF SEND 11 ACK XCF SEND PROCESS SYNC 12 13 SYNC FAIL XCF SEND DFSxxx 14 XCF SEND XCF SEND MQBACK DEALLOCATE REPLY ABORT XCF SEND MQPUT 15 MQGET DFSxxx REPLYTO APPL QUEUE MQCMIT FREE TIB ABEND (DFSxxx) DFSxxx 16 17 19 18 Understanding IMS OTMA Commit Mode and Synchronization Level 63
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Syncpoint Fail 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 3. OTMA processes the input message • Allocates the TIB • Calls RACF if needed • Inserts the input message to the IMS Message Queue • Enqueues the input message on the transaction queue • Sends an ACK for the input message to WebSphere MQ Understanding IMS OTMA Commit Mode and Synchronization Level 64
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Syncpoint Fail 4. WebSphere MQ does an MQCMIT and the input message is dequeued 5. The IMS transaction does a GU to the IOPCB to retrieve the input message 6. The IMS transaction ISRTs the reply message to the IOPCB 7. The reply message is anchored on the TIB 8. The IMS application reaches a syncpoint (GU IOPCB, termination) 9. IMS OTMA Retrieves the reply message from the message queue Understanding IMS OTMA Commit Mode and Synchronization Level 65
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Syncpoint Fail 10. IMS OTMA sends the reply message to WebSphere MQ 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 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 Understanding IMS OTMA Commit Mode and Synchronization Level 66
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Syncpoint Fail 12. The WebSphere MQ IMS Bridge sends an ACK to OTMA for the reply message 13. Syncpoint proceeds 14. Syncpoint fails 15. OTMA processes the failed syncpoint • 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 16. OTMA deletes the TIB control block 17. Syncpoint fails • The application abends Understanding IMS OTMA Commit Mode and Synchronization Level 67
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 68
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQ CM1SL1 – Client NAK MQ IMS MQ APPL MQ BRIDGE OTMA MPR Queue IMS MQPUT MQGET XCF SEND ALLOC TIB Message IMS XCF SEND CM1 SL1 CALL RACF Queue BRIDGE QUEUE 2 ISRT MSG ENQ MSG SEND ACK 1 XCF SEND ACK 3 GU IOPCB MQCMIT 5 DEQUEUE TIB INPUT ISRT IOPCB 4 ANCHOR MSG on TIB 6 7 START SYNC GET MSG 8 9 XCF SEND REPLY XCF SEND 10 Understanding IMS OTMA Commit Mode and Synchronization Level 69
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQ CM1SL1 – Client NAK MQ IMS MQ APPL BRIDGE OTMA MPR XCF TIB MQ SEND REPLY Queue MQPUT RTQ AND DLQ FAIL XCF SEND 11 NAK XCF SEND PROCESS SYNC 12 13 SYNC FAIL XCF SEND DFSxxx 14 XCF SEND XCF SEND DEALLOCATE ABORT XCF SEND MQPUT 15 MQGET DFSxxx REPLYTO APPL QUEUE MQCMIT FREE TIB ABEND (DFSxxx) DFSxxx 16 17 19 18 Understanding IMS OTMA Commit Mode and Synchronization Level 70
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Client NAK 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 3. OTMA processes the input message • Allocates the TIB • Calls RACF if needed • Inserts the input message to the IMS Message Queue • Enqueues the input message on the transaction queue • Sends an ACK for the input message to WebSphere MQ Understanding IMS OTMA Commit Mode and Synchronization Level 71
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Client NAK 4. WebSphere MQ does an MQCMIT and the input message is dequeued 5. The IMS transaction does a GU to the IOPCB to retrieve the input message 6. The IMS transaction ISRTs the reply message to the IOPCB 7. The reply message is anchored on the TIB 8. The IMS application reaches a syncpoint (GU IOPCB, termination) 9. IMS OTMA Retrieves the reply message from the message queue Understanding IMS OTMA Commit Mode and Synchronization Level 72
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Client NAK 10. IMS OTMA sends the reply message to WebSphere MQ 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 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 Understanding IMS OTMA Commit Mode and Synchronization Level 73
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Client NAK 12. The WebSphere MQ IMS Bridge sends a NAK to OTMA for the reply message 13. Syncpoint proceeds 14. Syncpoint fails 15. OTMA processes the failed syncpoint • 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 16. OTMA deletes the TIB control block 17. Syncpoint fails • The application abends Understanding IMS OTMA Commit Mode and Synchronization Level 74
  • IMS Regional User GroupClient Interface WebSphere MQ – CM1 SL1 – Client NAK 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 Understanding IMS OTMA Commit Mode and Synchronization Level 75
  • IMS Regional User GroupClient Interface OTMA Commit Mode – 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 Understanding IMS OTMA Commit Mode and Synchronization Level 76
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 77
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 78
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 79
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 80
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 81
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM0 SL1 – ACK ICON CLIENT ICON OTMA MPR TCP/IP WRITE IMS CONNECT CM0 SL1 ALLOC TIB Message WRITE XCF SEND CALL RACF Queue (ALLOC READ CM0 SL1 ISRT MSG SVT) XCF SEND ENQ MSG 1 FREE TIB GU IOPCB 2 3 4 SVT TIB ISRT IOPCB ENQ REPLY 5 ON TEMP Q 6 START SYNC PROCESS SYNC 7 8 ENQ REPLY ON QAB 9 SYNC OK END SYNC 10 11 Understanding IMS OTMA Commit Mode and Synchronization Level 82
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM0 SL1 – ACK ICON CLIENT ICON OTMA IMS Message MPR Queue SVT GET REPLY XCF SEND 12 REPLY XCF SEND ANCHOR REPLY 13 ON SVT TCP/IP WRITE 14 REPLY SEND REPLY READ 15 TCP/IP WRITE ACK SEND ACK READ XCF SEND ACK 16 XCF SEND PROCESS 18 DEQ REPLY REPLY 19 17 Understanding IMS OTMA Commit Mode and Synchronization Level 83
  • IMS Regional User GroupClient Interface IMS Connect – CM0 SL1 – ACK 1. An IMS Connect Client sends a CM0 SL1 input message to ICON 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 3. OTMA processes the input message • Allocates the TIB • Calls RACF if needed • Inserts the input message to the IMS Message Queue • Enqueues the input message on the transaction queue • Frees the TIB after the message is enqueued Understanding IMS OTMA Commit Mode and Synchronization Level 84
  • IMS Regional User GroupClient Interface IMS Connect – CM0 SL1 – ACK 4. The IMS transaction does a GU to the IOPCB to retrieve the input message 5. The IMS transaction ISRTs the reply message to the IOPCB 6. The message is enqueued on a temporary queue 7. The IMS application reaches a syncpoint (GU IOPCB, termination) 8. Syncpoint proceeds 9. OTMA enqueues the reply message on a QAB (Queue Anchor Block) 10. Syncpoint is successful 11. Syncpoint completes Understanding IMS OTMA Commit Mode and Synchronization Level 85
  • IMS Regional User GroupClient Interface IMS Connect – CM0 SL1 – ACK 12. IMS OTMA does an internal GU to retrieve the reply message 13. IMS OTMA sends the reply message to IMS Connect via XCF 14. IMS Connect anchors the reply message on the SVT 15. IMS Connect sends the reply message to the IMS Connect Client • IMS Connect waits for the ACK/NAK 16. The IMS Connect Client gets the reply message and sends an ACK 17. The IMS Connect Client can process the message 18. IMS Connect sends the ACK to OTMA 19. OTMA de-queues the reply message Understanding IMS OTMA Commit Mode and Synchronization Level 86
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM0 SL1 – Client NAK ICON CLIENT ICON OTMA MPR TCP/IP WRITE IMS CONNECT CM0 SL1 ALLOC TIB Message WRITE XCF SEND CALL RACF Queue (ALLOC READ CM0 SL1 ISRT MSG SVT) XCF SEND ENQ MSG 1 FREE TIB GU IOPCB 2 3 4 SVT TIB ISRT IOPCB ENQ REPLY 5 ON TEMP Q 6 START SYNC PROCESS SYNC 7 8 ENQ REPLY ON QAB 9 SYNC OK END SYNC 10 11 Understanding IMS OTMA Commit Mode and Synchronization Level 87
  • IMS Regional User GroupOTMA Client Interface – IMS Connect CM0 SL1 – Client NAK ICON CLIENT ICON OTMA IMS Message MPR Queue SVT GET REPLY XCF SEND 12 REPLY XCF SEND ANCHOR REPLY 13 ON SVT TCP/IP WRITE 14 REPLY SEND REPLY READ 15 TCP/IP WRITE NAK SEND NAK READ XCF SEND NAK 16 RE-QUE/ XCF SEND PURGE/ REROUTE NOTIFY 18 REPLY USER 19 17 Understanding IMS OTMA Commit Mode and Synchronization Level 88
  • IMS Regional User GroupClient Interface IMS Connect – CM0 SL1 – Client NAK 1. An IMS Connect Client sends a CM0 SL1 input message to ICON 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 3. OTMA processes the input message • Allocates the TIB • Calls RACF if needed • Inserts the input message to the IMS Message Queue • Enqueues the input message on the transaction queue • Frees the TIB after the message is enqueued Understanding IMS OTMA Commit Mode and Synchronization Level 89
  • IMS Regional User GroupClient Interface IMS Connect – CM0 SL1 – Client NAK 4. The IMS transaction does a GU to the IOPCB to retrieve the input message 5. The IMS transaction ISRTs the reply message to the IOPCB 6. The message is enqueued on a temporary queue 7. The IMS application reaches a syncpoint (GU IOPCB, termination) 8. Syncpoint proceeds 9. OTMA enqueues the reply message on a QAB (Queue Anchor Block) 10. Syncpoint is successful 11. Syncpoint completes Understanding IMS OTMA Commit Mode and Synchronization Level 90
  • IMS Regional User GroupClient Interface IMS Connect – CM0 SL1 – Client NAK 12. IMS OTMA does an internal GU to retrieve the reply message 13. IMS OTMA sends the reply message to IMS Connect via XCF 14. IMS Connect anchors the reply message on the SVT 15. IMS Connect sends the reply message to the IMS Connect Client • IMS Connect waits for the ACK/NAK 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 Understanding IMS OTMA Commit Mode and Synchronization Level 91
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQCM0 SL1 – ACK MQ IMS MQ APPL MQ BRIDGE OTMA MPR Queue IMS MQPUT MQGET XCF SEND ALLOC TIB Message IMS XCF SEND CM0 SL1 CALL RACF Queue BRIDGE ISRT MSG QUEUE 2 ENQ MSG SEND ACK 1 FREE TIB XCF SEND ACK GU IOPCB 3 MQCMIT 5 DEQUEUE TIB INPUT ENQ REPLY ISRT IOPCB 4 ON TEMP Q 6 7 START PROCESS SYNC SYNC 8 9 ENQ REPLY ON QAB 10 SYNC OK END SYNC 11 12 Understanding IMS OTMA Commit Mode and Synchronization Level 92
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQCM0 SL1 – ACK MQ IMS IMS MQ APPL BRIDGE OTMA Message MPR Queue GET REPLY 13 XCF SEND REPLY XCF SEND MQ 14 Queue MQPUT RTQ (OR DLQ) OK 15 MQCMIT 16 XCF SEND XCF SEND ACK 17 MQGET REPLYTO QUEUE DEQ REPLY 18 19 Understanding IMS OTMA Commit Mode and Synchronization Level 93
  • IMS Regional User GroupClient Interface WebSphere MQ – CM0 SL1 – ACK 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 3. OTMA processes the input message • Allocates the TIB • Calls RACF if needed • Inserts the input message to the IMS Message Queue • Enqueues the input message on the transaction queue • Sends an ACK for the input message to WebSphere MQ • Frees the TIB after the message is enqueued Understanding IMS OTMA Commit Mode and Synchronization Level 94
  • IMS Regional User GroupClient Interface WebSphere MQ – CM0 SL1 – ACK 4. WebSphere MQ does an MQCMIT and the input message is de-queued 5. The IMS transaction does a GU to the IOPCB to retrieve the input message 6. The IMS transaction ISRTs the reply message to the IOPCB 7. The reply message is enqueued on a temporary queue 8. The IMS application reaches a syncpoint (GU IOPCB, termination) 9. Syncpoint proceeds 10. OTMA enqueues the reply message on a QAB (Queue Anchor Block) 11. Syncpoint is successful 12. Syncpoint completes Understanding IMS OTMA Commit Mode and Synchronization Level 95
  • IMS Regional User GroupClient Interface WebSphere MQ – CM0 SL1 – ACK 13. IMS OTMA does an internal GU to retrieve the reply message 14. IMS OTMA sends the reply message to WebSphere MQ via XCF 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 Understanding IMS OTMA Commit Mode and Synchronization Level 96
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQCM0 SL1 – Client NAK MQ IMS MQ APPL MQ BRIDGE OTMA MPR Queue IMS MQPUT MQGET XCF SEND ALLOC TIB Message IMS XCF SEND CM0 SL1 CALL RACF Queue BRIDGE ISRT MSG QUEUE 2 ENQ MSG SEND ACK 1 FREE TIB XCF SEND ACK 3 GU IOPCB MQCMIT 5 DEQUEUE TIB INPUT ENQ REPLY ISRT IOPCB 4 ON TEMP Q 6 7 START PROCESS SYNC SYNC 8 9 ENQ REPLY ON QAB 10 SYNC OK END SYNC 11 12 Understanding IMS OTMA Commit Mode and Synchronization Level 97
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQCM0 SL1 – Client NAK MQ IMS IMS MQ APPL BRIDGE OTMA Message MPR Queue GET REPLY 13 XCF SEND REPLY XCF SEND 14 MQ Queue MQPUT RTQ AND DLQ FAIL 15 XCF SEND XCF SEND NAK 16 RE-ENQ REPLY 17 Understanding IMS OTMA Commit Mode and Synchronization Level 98
  • IMS Regional User GroupClient Interface WebSphere MQ – CM0 SL1 – Client NAK 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 3. OTMA processes the input message • Allocates the TIB • Calls RACF if needed • Inserts the input message to the IMS Message Queue • Enqueues the input message on the transaction queue • Sends an ACK for the input message to WebSphere MQ • Frees the TIB after the message is enqueued Understanding IMS OTMA Commit Mode and Synchronization Level 99
  • IMS Regional User GroupClient Interface WebSphere MQ – CM0 SL1 – Client NAK 4. WebSphere MQ does an MQCMIT and the input message is dequeued 5. The IMS transaction does a GU to the IOPCB to retrieve the input message 6. The IMS transaction ISRTs the reply message to the IOPCB 7. The reply message is enqueued on a temporary queue 8. The IMS application reaches a syncpoint (GU IOPCB, termination) 9. Syncpoint proceeds 10. OTMA enqueues the reply message on a QAB (Queue Anchor Block) 11. Syncpoint is successful 12. Syncpoint completes Understanding IMS OTMA Commit Mode and Synchronization Level 100
  • IMS Regional User GroupClient Interface WebSphere MQ – CM0 SL1 – Client NAK 13. IMS OTMA does an internal GU to retrieve the reply message 14. IMS OTMA sends the reply message to WebSphere MQ via XCF 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 Understanding IMS OTMA Commit Mode and Synchronization Level 101
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 102
  • IMS Regional User GroupOTMA Client Interface – IMS Connect OTMA NAK Input Message ICON CLIENT ICON OTMA TCP/IP WRITE CONNECT INPUT WRITE (ALLOC XCF SEND READ SVT) INPUT PROCESS XCF SEND INPUT 1 FAILS 2 3 SVT NAK INPUT MESSAGE 4 XCF SEND NAK XCF SEND 5 SEND ERROR DELETE TIB (REQSTS) 6 TCP/IP WRITE 7 ERROR KEEP/FREE PROCESS SVT ERROR 8 9 Understanding IMS OTMA Commit Mode and Synchronization Level 103
  • IMS Regional User GroupClient Interface IMS Connect – OTMA NAK Input Message 1. An IMS Connect Client sends an 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 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 Understanding IMS OTMA Commit Mode and Synchronization Level 104
  • IMS Regional User GroupClient 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 Understanding IMS OTMA Commit Mode and Synchronization Level 105
  • IMS Regional User GroupOTMA Client Interface – WebSphere MQOTMA NAK Input Message MQ IMS MQ APPL MQ BRIDGE OTMA Queue MQPUT MQGET XCF SEND IMS XCF SEND INPUT BRIDGE PROCESS QUEUE 2 INPUT FAILS 1 3 NAK INPUT MESSAGE XCF SEND 4 NAK MQ XCF SEND PROCESS NAK 5 Input Queue 7 DELETE TIB Reply-to Queue Dead Letter Queue 6 Understanding IMS OTMA Commit Mode and Synchronization Level 106
  • IMS Regional User GroupClient Interface WebSphere MQ – OTMA NAK Input Message 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 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 Understanding IMS OTMA Commit Mode and Synchronization Level 107
  • IMS Regional User GroupClient Interface WebSphere MQ – 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 WebSphere MQ via XCF 6. OTMA deletes the TIB control block if it was allocated 7. WebSphere MQ processes the NAK Understanding IMS OTMA Commit Mode and Synchronization Level 108
  • IMS Regional User GroupClient Interface WebSphere MQ – OTMA NAK Input Message 7. WebSphere MQ processes the NAK • 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 Understanding IMS OTMA Commit Mode and Synchronization Level 109
  • IMS Regional User GroupClient Interface WebSphere MQ – OTMA NAK Input Message 7. WebSphere MQ processes the NAK • 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 Understanding IMS OTMA Commit Mode and Synchronization Level 110
  • IMS Regional User GroupClient Interface OTMA Commit Mode – 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 Understanding IMS OTMA Commit Mode and Synchronization Level 111
  • IMS Regional User GroupClient Interface OTMA Commit Mode – Commit Mode 1 - Send-then-commit • 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 Understanding IMS OTMA Commit Mode and Synchronization Level 112
  • IMS Regional User GroupIMS 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 Understanding IMS OTMA Commit Mode and Synchronization Level 113
  • IMS Regional User Group Appendix Processing CM1 Input Messages Understanding IMS OTMA Commit Mode and Synchronization Level 114
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 115
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 116
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 117
  • IMS Regional User GroupProcessing 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 Understanding IMS OTMA Commit Mode and Synchronization Level 118
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 119
  • IMS Regional User GroupProcessing CM1 Input Messages – Passing the TIB GU IOPCB CM1 GU GU Input ASYNC IOPCB IOPCB ISRT Message SYNC ALTPCB TIB ISRT ASYNC ASYNC ALTPCB ISRT ISRT ALTPCB ALTPCB ISRT SYNC ALTPCB GU IOPCB TIB ASYNC SYNC ISRT GU ISRT ALTPCB IOPCB ALTPCB ASYNC ISRT ALTPCB ISRT ASYNC ALTPCB ASYNC ISRT GU ALTPCB IOPCB ASYNC ISRT ALTPCB Understanding IMS OTMA Commit Mode and Synchronization Level 120
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 121
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 122
  • IMS Regional User GroupProcessing CM1 Input Messages – Input Transaction Reply to IOPCB CM1 GU Input IOPCB Message ASYNC ISRT GU ALTPCB IOPCB ISRT CM0 IOPCB ASYNC ISRT GU ALTPCB IOPCB ISRT CM0 IOPCB ASYNC ISRT GU ALTPCB IOPCB CM1 CM0 ISRT ISRT IOPCB IOPCB Understanding IMS OTMA Commit Mode and Synchronization Level 123
  • IMS Regional User GroupProcessing CM1 Input Messages If the original CM1 input transaction (or synchronous message-switched-to transaction) 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 Understanding IMS OTMA Commit Mode and Synchronization Level 124
  • IMS Regional User GroupProcessing CM1 Input Messages – All EXPRESS ALTPCB CM1 GU Input IOPCB Message ISRT ASYNC EXPRESS GU ALTPCB IOPCB No CM1 output ISRT CM0 TIB is freed IOPCB ISRT ASYNC EXPRESS GU ALTPCB IOPCB ISRT CM0 IOPCB ISRT ASYNC EXPRESS GU ALTPCB IOPCB CM0 ISRT IOPCB Understanding IMS OTMA Commit Mode and Synchronization Level 125
  • IMS Regional User GroupProcessing CM1 Input Messages If the original CM1 input transaction (or synchronous message-switched-to transaction) 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 Understanding IMS OTMA Commit Mode and Synchronization Level 126
  • IMS Regional User GroupProcessing CM1 Input Messages – Non-EXPRESS or (EXPRESS + Non-EXPRESS) CM1 GU Input IOPCB Message ISRT ? NON-EXP GU ALTPCB IOPCB Maybe CM1 ISRT CM? output IOPCB OTMAASY is ISRT ? NON-EXP GU used ALTPCB IOPCB TIB is not freed ISRT CM? IOPCB ISRT ? EXPRESS GU ALTPCB IOPCB CM? ISRT IOPCB Understanding IMS OTMA Commit Mode and Synchronization Level 127
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 128
  • IMS Regional User GroupProcessing CM1 Input Messages – OTMAASY=N – Scheduled Before Tran Ends CM1 GU Input IOPCB Message ISRT ? NON-EXP GU ALTPCB IOPCB Scheduled After First If scheduled Tran Ends ISRT CM? before first IOPCB transaction ends ISRT ? it is EXPRESS ALTPCB GU IOPCB Scheduled asynchronous After First IOPCB output is Tran ISRT CM? Ends CM0 IOPCB ISRT ASYNC EXPRESS GU ALTPCB IOPCB Scheduled Before First Tran CM0 Ends ISRT IOPCB Understanding IMS OTMA Commit Mode and Synchronization Level 129
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 130
  • IMS Regional User GroupProcessing CM1 Input Messages – OTMAASY=N – First Scheduled Gets TIB CM1 GU Input IOPCB Message ISRT ASYNC NON-EXP GU ALTPCB IOPCB Scheduled Second After First transaction Tran Ends ISRT CM0 scheduled after IOPCB the switching ISRT SYNC transaction ends EXPRESS ALTPCB GU IOPCB Scheduled gets the TIB First TIB After Switch is Tran ISRT CM1 Ends synchronous IOPCB IOPCB output is ISRT EXPRESS ASYNC GU CM1 ALTPCB Scheduled IOPCB Before All others are First Tran CM0 ASYNC Ends ISRT IOPCB Understanding IMS OTMA Commit Mode and Synchronization Level 131
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 132
  • IMS Regional User GroupProcessing CM1 Input Messages – OTMAASY=Y – Scheduled Before Tran Ends CM1 GU Input IOPCB RESPONSE Message ISRT ? NON-EXP GU ALTPCB IOPCB Scheduled After First If scheduled Tran Ends ISRT CM? before first IOPCB transaction ends ISRT NONRESPONSE ? it is EXPRESS ALTPCB GU IOPCB Scheduled asynchronous After First IOPCB output is Tran ISRT CM? Ends CM0 IOPCB RESPONSE ISRT ASYNC EXPRESS GU ALTPCB IOPCB Scheduled Before First Tran CM0 Ends ISRT IOPCB Understanding IMS OTMA Commit Mode and Synchronization Level 133
  • IMS Regional User GroupProcessing 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 Understanding IMS OTMA Commit Mode and Synchronization Level 134
  • IMS Regional User GroupProcessing CM1 Input Messages – OTMAASY=Y – First RESPONSE Sched Gets TIB CM1 GU Input IOPCB RESPONSE Message ISRT SYNC NON-EXP GU ALTPCB IOPCB Scheduled First RESPONSE Second After TIB transaction Tran Ends ISRT CM1 scheduled after IOPCB NONRESPONSE the switching ISRT ASYNC EXPRESS GU transaction ends ALTPCB Scheduled IOPCB gets the TIB First After Tran Switch is Ends ISRT CM0 IOPCB synchronous RESPONSE ISRT ASYNC IOPCB output is EXPRESS ALTPCB GU IOPCB Scheduled CM1 Before First All others are Tran Ends ISRT CM0 ASYNC IOPCB Understanding IMS OTMA Commit Mode and Synchronization Level 135
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 136
  • IMS Regional User GroupProcessing CM1 Input Messages – OTMAASY=Y – All NONRESPONSE After End CM1 GU Input IOPCB NONRESPONSE Message ISRT ASYNC NON-EXP GU ALTPCB IOPCB Scheduled Second If all After Tran NONREPONSE Ends ISRT CM0 IOPCB after transaction NONRESPONSE ends no one gets ISRT EXPRESS ASYNC GU the TIB ALTPCB Scheduled IOPCB First All are ASYNC After Tran Ends ISRT CM0 All IOPCB output IOPCB is CM0 ISRT ASYNC RESPONSE EXPRESS GU No DFS2082 ALTPCB Scheduled IOPCB Before TIB is orphaned First Tran CM0 until IMS COLD Ends ISRT IOPCB start Understanding IMS OTMA Commit Mode and Synchronization Level 137
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 138
  • IMS Regional User GroupProcessing CM1 Input Messages – OTMAASY=S – First Non-EXPRESS ISRT CM1 GU Input IOPCB NONRESPONSE Message SYNC THIRD GU ISRT IOPCB NON-EXP Scheduled ALTPCB Second First Non- After TIB Tran EXPRESS Ends ISRT CM1 IOPCB ALTPCB ISRT SECOND RESPONSE gets the TIB ISRT EXPRESS ASYNC GU ALTPCB IOPCB Switch is Scheduled First synchronous After Tran Ends ISRT CM0 IOPCB output is IOPCB FIRST CM1 ISRT ASYNC RESPONSE EXPRESS GU All others are ALTPCB Scheduled IOPCB Before ASYNC First Tran CM0 Ends ISRT IOPCB Understanding IMS OTMA Commit Mode and Synchronization Level 139
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 140
  • IMS Regional User GroupProcessing CM1 Input Messages – OTMAASY=S – No Non-EXPRESS ISRT CM1 GU Input IOPCB NONRESPONSE Message ASYNC THIRD GU ISRT IOPCB EXPRESS Scheduled ALTPCB Second If no Non- After Tran EXPRESS no one Ends ISRT CM0 IOPCB gets the TIB SECOND RESPONSE ISRT All are ASYNC EXPRESS ASYNC GU ALTPCB IOPCB Scheduled All IOPCB output is First After CM0 Tran Ends ISRT CM0 No DFS2082 FIRST IOPCB RESPONSE ISRT TIB is orphaned EXPRESS ASYNC GU ALTPCB IOPCB until IMS COLD Scheduled Before start First Tran CM0 Ends ISRT IOPCB Understanding IMS OTMA Commit Mode and Synchronization Level 141
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 142
  • IMS Regional User GroupProcessing CM1 Input Messages 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 Understanding IMS OTMA Commit Mode and Synchronization Level 143
  • IMS Regional User GroupProcessing CM1 Input Messages /DIS OTMA or /DIS TMEMBER xxxx (or ALL) shows the number of TIBS for a TMEMBER/DIS OTMAGROUP/MEMBER XCF-STATUS USER-STATUS SECURITY TIB MAX SMEM DRUEXIT T/O TPCNT ACEEAGEOTMAZZS-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 Understanding IMS OTMA Commit Mode and Synchronization Level 144
  • IMS Regional User GroupProcessing CM1 Input Messages /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 Understanding IMS OTMA Commit Mode and Synchronization Level 145
  • IMS Regional User GroupProcessing CM1 Input Messages /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 Understanding IMS OTMA Commit Mode and Synchronization Level 146
  • IMS Regional User GroupConsequences What are the consequences of CM1 IOPCB input producing CM0 IOPCB output? – WebSphere MQ • Nothing – the output will go on the Reply-to Queue Understanding IMS OTMA Commit Mode and Synchronization Level 147
  • IMS Regional User GroupConsequences 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 Understanding IMS OTMA Commit Mode and Synchronization Level 148
  • IMS Regional User GroupConsequences 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!!!!! Understanding IMS OTMA Commit Mode and Synchronization Level 149
  • IMS Regional User GroupConclusion There are many considerations for OTMA messages Careful planning is required Understanding IMS OTMA Commit Mode and Synchronization Level 150