IBM Support

IC66904: MESSAGES DESTINED TO A CLUSTER QUEUE ON A REMOTE QMGR THAT INCLUDE AN RFH2 HEADER ARE RECEIVED WITHOUT THE RFH2.

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Messages destined to a cluster queue on a remote queue manager
    that include an RFH2 header are received without the RFH2
    headers. This occurs when the destination cluster queue manager
    is stopped while messages are in the transmission queue and then
    restarted.  Messages transmitted before stopping the remote
    cluster queue manager were received with a proper RFH2 header.
    However, the messages transmitted after the remote cluster queue
    manager restart do not contain the RFH2 header. Instead the
    messages are sent as MQSTR format.
    
    The trace of the channel pooling process for the CLUSSDR channel
    shows that the RFH2 headers in the message had been stripped off
    prior to sending it to the remote cluster queue manager.
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    All users of WebSphere MQ v7 cluster queue managers.
    
    Platforms affected:
    All Distributed (iSeries, all Unix and Windows)
    ****************************************************************
    PROBLEM SUMMARY:
    When the destination cluster queue manager is stopped while the
    messages are still in the transmission queue, the cluster
    repository manager receives a message that the cluster channel
    failed. Due to this, it reallocates the messages associated with
    the failed channel. During this step, it destructively gets the
    message from the cluster transmit queue and does an MQPUT on the
    target queue. This causes the message to be reallocated to a
    working channel.
    
    Under the above step, while the message is being destructively
    read from the cluster transmit queue, the "MQGMO_NO_PROPERTIES"
    MQGMO option is used. This causes the message properties to be
    ignored upon MQGET. When this message is put on the target
    queue again, it does not contain any RFH2 properties.
    This is the reason why the messages transmitted after the
    destination cluster queue manager restart do not contain any
    RFH2 properties.
    
    The problem stems from the fact that the repository manager uses
    the MQGMO option "MQGMO_NO_PROPERTIES" while reallocating the
    messages.
    

Problem conclusion

  • The MQGMO options used while reallocating messages were altered
    such that the message properties are now read by the destructive
    MQGET call.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
                       v7.0
    Platform           Fix Pack 7.0.1.3
    --------           --------------------
    Windows            tbc_p700_0_1_3
    AIX                tbc_p700_0_1_3
    HP-UX (PA-RISC)    tbc_p700_0_1_3
    HP-UX (Itanium)    tbc_p700_0_1_3
    Solaris (SPARC)    tbc_p700_0_1_3
    Solaris (x86-64)   tbc_p700_0_1_3
    iSeries            tbc_p700_0_1_3
    Linux (x86)        tbc_p700_0_1_3
    Linux (x86-64)     tbc_p700_0_1_3
    Linux (zSeries)    tbc_p700_0_1_3
    Linux (Power)      tbc_p700_0_1_3
    
    The latest available maintenance can be obtained from
    'WebSphere MQ Recommended Fixes'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037
    
    If the maintenance level is not yet available, information on
    its planned availability can be found in 'WebSphere MQ
    Planned Maintenance Release Dates'
    http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309
    ---------------------------------------------------------------
    

Temporary fix

Comments

APAR Information

  • APAR number

    IC66904

  • Reported component name

    WMQ WINDOWS V7

  • Reported component ID

    5724H7220

  • Reported release

    701

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2010-03-04

  • Closed date

    2010-03-31

  • Last modified date

    2010-03-31

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

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

Fix information

  • Fixed component name

    WMQ WINDOWS V7

  • Fixed component ID

    5724H7220

Applicable component levels

  • R701 PSY

       UP

[{"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSCPQ63","label":"APAR \/ Maintenance"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
31 March 2010