PM25206: TIMEOUT WAITING FOR ACK OR HANG WAITING FOR ACK FOR OTMA COMMIT MODE 1 SYNCLEVEL 1 CONVERSATIONAL TRANSACTION OUTPUT.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• An MQSeries OTMA client was processing an IMS conversational
  transaction using Commit Mode 1 Synclevel 1.  When OTMA returned
  the output message MQ queued the message to the reply-to-queue
  and ACK'ed the output message.  It has to queue the message
  first so that it can NACK the output message if the queue fails.
   The MQSeries application sent back the next iteration of the
  conversation which reached IMS before the ACK for the previous
  output message.  This out of order processing caused OTMA to
  mishandle the ACK for the next output message.  It would ignore
  the ACK which could result in a timeout waiting for the ACK
  followed by ABENDU0119 for the transaction or OTMA would wait
  for the ACK and the wait would not end.
  Additional symptoms:
  When running a conversational transaction coming through IMS
  Connect, the message region shows a status of wait-syncpoint.
  The MPP is waiting in DFSYSND0 + x'CAA' under label @GS01805
  Flow is DFSTMS00, TMS30000, DFS6LUS0, DFSYLUS0, DFSYSLM0,
  DFSYSND0, DFSIWAIT
  We are in SYNCPOINT processing. R0 at entry to TMS30000 is
  x'18'(=24) indicating we do a LUM SEND (FULL FUNCTION), R7
  containsTMSYFUNC=x'03' that means COMMIT (PHASE 1 & 2).
  DFSYSND0 sends data and IWAITs for a response from the OTMA
  client (ACK or NAK).
  

Local fix

• There is no local fix for this problem.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All IMS V10 OTMA Users with conversational   *
  *                 transaction.                                 *
  ****************************************************************
  * PROBLEM DESCRIPTION: ABENDU0119 due to an ACK timeout while  *
  *                      processing a conversational transaction *
  *                      from OTMA.                              *
  ****************************************************************
  * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
  ****************************************************************
  An OTMA client was sent an IMS conversational transaction using
  Commit Mode 1 Synclevel 1. When OTMA returned the output message
  the client sent an ACK followed by the next iteration for the
  conversation. OTMA received the next iteration before the ACK
  for the previous iteration. Due to a logic error, OTMA discarded
  the ACK, which caused the next iteration to timeout, resulting
  in ABENDU0119.
  
  This is the flow that causes the problem.
  
   1. The first iteration arrives and DFSYPSI0 sets YTIB_SYNC_TMO.
   2. The first reply message is sent.
   3. The ACK for the first reply message is received.
   4. DFSYPSI0 resets YTIB_SYNC_TMO and processes the first ACK.
  
   5. The second iteration arrives and DFSYPSI0 sets YTIB_SYNC_TMO
   6. The second reply message is sent.
   7. The ACK for the second reply message is received.
   8. DFSYPSI0 resets YTIB_SYNC_TMO and processes the second ACK.
  
   9. The third iteration arrives and DFSYPSI0 sets YTIB_SYNC_TMO.
  10. The third reply message is sent.
  11. The fourth iteration arrives and DFSYPSI0 sets YTIB_SYNC_TMO
  12. The ACK for the third reply message is received.
  13. DFSYPSI0 resets YTIB_SYNC_TMO and processes the third ACK.
  
  14. The fourth reply message is sent.
  15. The ACK for the fourth reply message is received
  16. DFSYPSI0 fails to reset YTIB_SYNC_TMO because it's already
      been reset in Step 13. The ACK is discarded resulting in
      ABENDU0119 due to the fourth iteration timing out.
  
  YTIB_SYNC_TMO should be set on output not on input since it's
  for ACK timeout, which is an output event.
  

Problem conclusion

• GEN:
  KEYWORDS:
  
  *** END IMS KEYWORDS ***
  DFSYPSI0 was modified to remove the code to set YTIB_SYNC_TMO on
  input.
  
  DFSYSLM0 was modified to add the code to set YTIB_SYNC_TMO on
  output.
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  PM27817 PM27818 UK63479

Modules/Macros

• DFSYPSI0 DFSYSLM0
  

Fix information

• Fixed component name

  IMS V10

• Fixed component ID

  5635A0100

Applicable component levels

• R010 PSY UK63479

     UP10/12/30 P F012 Ž

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.