IBM Support

IC80299: MQRC_NO_MSG_AVAILABLE INCORRECTLY RETURNED IN JAVA WHEN MQGET USING RESIZED BUFFER FAILS AND MESSAGE HAD A UNIQUE CORRELID

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • When 2 or more applications are getting messages from a
    WebSphere MQ queue, an application using the WebSphere MQ
    classes for Java recieves a 2033 (MQRC_NO_MSG_AVAILABLE) reason
    code when performing a get operation on an MQQueue object, even
    though there are deliverable messages on the queue that satisfy
    the criteria of the MQGET request.
    
    Similar behaviour is seen when using the WebSphere MQ classes
    for JMS in the same circumstances, although instead of the 2033
    reason code, a "null" JMS Message object is returned from the
    JMS MessageConsumer's receive method call.
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects users of:
    
    - The WebSphere MQ v7.0.1 and v7.1 classes for Java
    - The WebSphere MQ v7.0.1 and v7.1 classes for JMS
    - The WebSphere Application Server V6.1 WebSphere MQ messaging
    provider who have configured the WebSphere variable to use the
    WebSphere MQ v7.0.1 and v7.1 Messaging Provider.
    - The WebSphere MQ v7.0.1 and v7.1 Resource Adapter.
    
    Who are attempting to receive messages which are larger than
    the default buffer size of 4KB.
    
    Platforms affected:
    All Distributed (iSeries, all Unix and Windows) +Java +Java zOS
    ****************************************************************
    PROBLEM SUMMARY:
    When using the WebSphere MQ classes for Java to make a MQGET
    request by calling one of the methods:
    
    .     com.ibm.mq.MQQueue.get(MQMessage message)
    .
    .     com.ibm.mq.MQQueue.get(MQMessage message,
    .                            MQGetMessageOptions getMsgOpt)
    
    (the get() methods which do not take a maxMsgSize parameter),
    the WebSphere MQ classes for Java will, by default, attempt to
    get the  message from the queue manager using a 4KB buffer. If
    the message is bigger than this buffer size, and the
    application has not specified get option:
    
    .    MQGMO_ACCEPT_TRUNCATED_MSG
    
    in the GetMsgOptions, the WebSphere MQ classes for Java
    resizes this buffer to the actual size of the message, and
    retries the MQGET.
    
    In this two-stage operation, on the MQGET retry the WebSphere
    MQ classes for Java/JMS specify the message ID and correlation
    ID of the original message, in order to attempt to get the
    same message as seen in the first stage.
    
    Prior to WebSphere MQ v7.0.1.6, if the message is no longer
    available on the queue for the second stage get, for example
    if another application has removed it inbetween the two
    MQGETs, a MQRC 2033 'MQRC_NO_MSG_AVAILABLE' return code is
    returned to the WebSphere MQ classes for Java application, or
    a null message is returned when using the WebSphere MQ classes
    for JMS to indicate that there was no valid message to
    receive.
    
    This inappropriate behaviour was documented and changed under
    APAR IZ97006 (included in v7.0.1.6), such that upon receiving
    the 2033, another MQGET was issued for the remainder of the
    duration of the original MQGET call.  This ensured that the
    2033 (or null message in the case of the JMS API) was only
    returned to the application once the specified receive time
    had elapsed, in the case where there were no more suitable
    messages available on the queue.
    
    As of v7.0.1.6 (containing IZ97006), where the original
    first-stage message had a non-null value for its correlation
    ID and therefore used in the second-stage MQGET to assist with
    the identification of the message on the queue, in the case
    where the second-stage message was no longer available, the
    newly issued MQGET continued to use the cached correlation ID.
    
    The result of this was that this third-stage MQGET would not
    find a message (assuming that the correlation IDs of the
    messages on the queue were unique), wait the remainder of the
    time specified by the application on the original MQGET and
    return a MQRC 2033 (or null message in the case of the
    WebSphere MQ classes for JMS API).
    

Problem conclusion

  • The WebSphere MQ classes for Java/JMS have been updated to
    prevent caching the correlation ID in the event that an MQGET
    operation is retried as a result of the original message having
    been removed from the queue.
    
    | MDVPARTL 7.0.1-WS-MQ-AixPPC64-FP0006       |
    | MDVPARTL 7.0.1-WS-MQ-HpuxIA64-FP0006       |
    | MDVPARTL 7.0.1-WS-MQ-HpuxPaRISC64-FP0006   |
    | MDVPARTL 7.0.1-WS-MQ-LinuxIA32-FP0006      |
    | MDVPARTL 7.0.1-WS-MQ-LinuxPPC64-FP0006     |
    | MDVPARTL 7.0.1-WS-MQ-LinuxS390X-FP0006     |
    | MDVPARTL 7.0.1-WS-MQ-LinuxX64-FP0006       |
    | MDVPARTL 7.0.1-WS-MQ-SolarisSparc64-FP0006 |
    | MDVPARTL 7.0.1-WS-MQ-SolarisX64-FP0006     |
    | MDVPARTL 7.0.1-WS-MQ-Windows-FP0006        |
    
    | MDVPARTL 7.0.1-WS-MQ-AixPPC64-FP0007       |
    | MDVPARTL 7.0.1-WS-MQ-HpuxIA64-FP0007       |
    | MDVPARTL 7.0.1-WS-MQ-HpuxPaRISC64-FP0007   |
    | MDVPARTL 7.0.1-WS-MQ-LinuxIA32-FP0007      |
    | MDVPARTL 7.0.1-WS-MQ-LinuxPPC64-FP0007     |
    | MDVPARTL 7.0.1-WS-MQ-LinuxS390X-FP0007     |
    | MDVPARTL 7.0.1-WS-MQ-LinuxX64-FP0007       |
    | MDVPARTL 7.0.1-WS-MQ-SolarisSparc64-FP0007 |
    | MDVPARTL 7.0.1-WS-MQ-SolarisX64-FP0007     |
    | MDVPARTL 7.0.1-WS-MQ-Windows-FP0007        |
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v7.1       7.1.0.1
    v7.0       7.0.1.8
    
    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

    IC80299

  • 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

    2011-12-08

  • Closed date

    2012-01-20

  • Last modified date

    2013-12-05

  • 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

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Product":{"code":"SSFKSJ","label":"WebSphere MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.1"}]

Document Information

Modified date:
20 September 2021