IBM Support

IT26482: MQ classes for JMS incorrectly require "get" authority on the target cluster queue for an alias queue

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The topic:
    
    "Handling poison messages in IBM WebSphere MQ classes for JMS"
    
    in the IBM MQ sections of IBM Knowledge Center contains the
    following information:
    
    "IBM MQ classes for JMS queries the BackoutThreshold and
    BackoutRequeueQName of the queue. You must therefore grant
    inquire access on the queue to the user running the
    application. If the target queue is a cluster queue, grant
    inquire, browse and get access."
    
    However, the IBM MQ classes for JMS should not need "Get access"
    if the target queue for an alias queue is a cluster queue, as it
    is possible for them to query the backout threshold and backout
    requeue queue name with just "inquire" access.
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This issue affects users of:
    
    - The IBM MQ classes for JMS.
    - The IBM MQ resource adapter.
    - The WebSphere Application Server MQ messaging provider.
    
    who have applications, activation specifications or WebSphere
    Application Server Listener Ports that get messages from an
    alias queue on a queue manager, where the target queue for the
    alias queue is a cluster queue.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    When the IBM MQ classes for JMS detect a message on a
    destination, they will perform the following processing to
    determine whether to deliver that message to an application for
    processing, or move it to a backout requeue queue:
    
    - Check the backout count of the message.
    - If the backout count is greater than zero, then:
        - If this is the first message that has been detected which
    has a backout count greater than zero, then:
            - Query the backout threshold (BOTHRESH) and backout
    requeue queue name (BOQNAME) attributes of the queue.
            - Cache the values of the backout threshold and backout
    requeue queue attributes.
        - End if.
        - Compare the backout count of the message to the cached
    value of the backout threshold attribute for the queue.
            - If the backout count is greater than or equal to the
    backout threshold, then:
                - Move the message to the backout requeue queue, if
    one has been specified.
            - Else:
                - Deliver the message to the application.
            - End if.
    - Else:
        - Deliver the message to the application.
    - End if
    
    If an IBM MQ classes for JMS application was configured to get
    messages from an alias queue that had a cluster queue as its
    target, then the IBM MQ classes for JMS would open the cluster
    queue with the following options:
    
    - MQOO_INPUT_AS_Q_DEF
    - MQOO_INQUIRE
    - MQOO_FAIL_IF_QUIESCING.
    
    and then issue an MQINQ API call to get the values of the
    BOTHRESH and BOQNAME properties.
    
    However, the open option:
    
      MQOO_INPUT_AS_Q_DEF
    
    was not required.
    

Problem conclusion

  • The IBM MQ classes for JMS have been updated so that if a JMS
    application is configured to get messages from:
    
    - Either a cluster queue.
    - Or an alias queue, where the target for the alias queue is a
    cluster queue.
    
    then the IBM MQ classes for JMS will open the cluster queue with
    the options:
    
    - MQOO_INQUIRE
    - MQOO_FAIL_IF_QUIESCING.
    
    in order to get the value of the backout threshold (BOTHRESH)
    and backout requeue queue name (BOQNAME) properties.
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v8.0       8.0.0.12
    v9.0 LTS   9.0.0.6
    v9.1 CD    9.1.2
    v9.1 LTS   9.1.0.2
    
    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

    IT26482

  • Reported component name

    WMQ WINDOWS V7

  • Reported component ID

    5724H7220

  • Reported release

    710

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2018-10-02

  • Closed date

    2019-01-21

  • Last modified date

    2019-01-30

  • 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

  • R710 PSY

       UP

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

Document Information

Modified date:
09 March 2021