IBM Support

PM67095: OTMA SYNCHRONIZED TPIPE SEQUENCE NUMBER ERRORS AFTER TIMEOUT WAITING FOR AN ACK.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • After a timeout waiting for an ACK for a Commit Mode 0 message
    from WebSphere MQ, recoverable sequence numbers errors can occur
    on an IMS OTMA synchronized TPIPE.
    
    The IMS message for the timeout is
    DFS3494E OTMA HAS TIMED OUT FOR TMEMBER/TPIPE xxxx/yyyy AND
    MOVED THE OUTPUT TO DFS$$TOQ
    
    The WebSphere MQ message when detecting the recoverable sequence
    number error is
    CSQ2005I CSQ2QCPI ERROR PROCESSING MESSAGE.  FEEDBACK=331,
    XCFGNAME=<gname> XCFMNAME=<mname> TPIPE=<tpipename>
    
    See also WebSphere MQ APAR PM67099
    

Local fix

  • To recover from the problem issue the MQ command
    /cpf RESET TPIPE<tpipe-name> XCFMNAME<member-name>
    where "cpf" is the command prefix for the queue manager
    or recycle OTMA using
    /STOP OTMA
    /START OTMA
    
    You can prevent the ACK timeout from occuring by turning off ACK
    timeout for an OTMA TMEMBER
    /START TMEMBER xxxxxxxx TIMEOUT 0
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All IMS V11 OTMA Users with WebSphere MQ     *
    *                 and synchronized TPIPES.                     *
    ****************************************************************
    * PROBLEM DESCRIPTION: OTMA synchronized TPIPE sequence number *
    *                      errors after CM0 ACK timeout.           *
    ****************************************************************
    * RECOMMENDATION: INSTALL CORRECTIVE SERVICE FOR APAR/PTF      *
    ****************************************************************
    After a CM0 ACK timeout, OTMA moves the output message to the
    timeout queue, DFS$$TOQ, increments the recoverable sequence
    number, and issues the following message:
    
    DFS3494E OTMA HAS TIMED OUT FOR TMEMBER/TPIPE mmmm/tttt
    AND MOVED THE OUTPUT TO DFS$$TOQ.
    
    This causes an out-of-sync error with WebSphere MQ, resulting
    in all subsequent output being rejected by MQ with NACK x'1F'
    and the following message:
    
    CSQ2005I MQM5 CSQ2QCP1 ERROR PROCESSING MESSAGE, FEEDBACK=331,
    XCFGNAME=gggg XCFMNAME=mmmm TPIPE=tttt
    
    OTMA mishandles the NACK x'1F', assuming it means MQ has already
    received the output, and therefore discards the message,
    resulting in lost messages.
    
    The local fix is to turn off CM0 ACK timeout for MQ by issuing
    the following IMS command:
    
    /STA TMEMBER mmmm TIMEOUT 0 - where mmmm is the MQ client name.
    
    Additional Keywords:
    
    MSGDFS1284E MSGDFS3493E MSGCSQ2005I
    

Problem conclusion

  • GEN:
    KEYWORDS:
    
    *** END IMS KEYWORDS ***
    The complete solution requires changes on both IMS, via this
    APAR, and MQ, via APAR PM67099. However, these APAR's may be
    applied independently since there is toleration code in IMS.
    
    MQ APAR PM67099 will now pass a reason code, TMAMCRSC, along
    with the x'1F' sense code, TMAMCSNC, and set TMAMPCM0 to tell
    IMS to discard the message, if it's already been received.
    
    DFSYPSO0 was modified to issue DFS3494E without the text
    indicating that the message was moved to the timeout queue.
    
    DFSYQAB0 was modified to wash the message back to the original
    queue rather than move it to the timeout queue.
    
    DFSYPSI0 was modified to process either the old NACK x'1F' or
    the new NACK x'1F' (MQ PM67099). For the new NACK x'1F', it
    will discard the message if TMAMPCM0 is set by MQ, otherwise
    it will stop the TPIPE to prevent message loss. In the later
    case, an MQ RESET TPIPE command will be required to reset the
    sequence numbers so message traffic can resume.
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    PM67095

  • Reported component name

    IMS V11

  • Reported component ID

    5635A0200

  • Reported release

    102

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2012-06-19

  • Closed date

    2012-10-26

  • Last modified date

    2012-11-02

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

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

    PM74638 UK83026

Modules/Macros

  • DFSYPSI0 DFSYPSO0 DFSYQAB0
    

Fix information

  • Fixed component name

    IMS V11

  • Fixed component ID

    5635A0200

Applicable component levels

  • R100 PSY UK83026

       UP12/10/30 P F210 Ž

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.

[{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"102","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCVRBJ","label":"System Services"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"102","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
02 November 2012