IBM Support

PI62604: IBM MQ 8.0 APPLICATION SENT ADDITIONAL MESSAGES BY QUEUE MANAGER AFTER ENDING AN ASYNCHRONOUS CONNECTION.

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • After an application closes a connection to the queue
    manager the queue manager continues to send messages
    to the application.
    If the messages are non-persistent the potential exists
    for the messages to be lost.
    

Local fix

  • Set SHARECNV(0) on the channel used by the application
    to connect to the queue manager.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 8 *
    *                 Release 0 Modification 0.                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: Client applications using MQCB/MQCTL to *
    *                      asynchronously consume messages from    *
    *                      queues can receive messages after       *
    *                      issuing MQCTL with MQOP_STOP, leading   *
    *                      to messages being delayed or lost.      *
    *                                                              *
    *                      When the affected application is IIB    *
    *                      v10, the problem occurs when msgflows   *
    *                      or nodes are configured with additional *
    *                      instances.                              *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    A client with multiple connections to the queue manager
    consuming messages asynchronously issues MQCTL_STOP for one of
    the connections. This causes a notification to be sent to the
    server notifying it of a change in the consumer's state.
    When rstReceiveNotification processes the notification it
    suspends the consumer on the server and updates the consumer's
    state. However, it then always resumes the consumer, even when
    the notification was that async consume should be stopped for
    that connection.
    This can result in that consumer continuing to consume messages
    and sending them to the client, even though the client is no
    longer expected to receive messages.
    

Problem conclusion

  • rstReceiveNotification is changed to no longer resume the
    consumer when notified that async consume is being stopped for a
    connection.
    000Y
    CMQXRSTF
    

Temporary fix

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

Comments

APAR Information

  • APAR number

    PI62604

  • Reported component name

    WMQ Z/OS 8

  • Reported component ID

    5655W9700

  • Reported release

    000

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-05-17

  • Closed date

    2016-05-27

  • Last modified date

    2016-08-02

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

    IT12243

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

    UI38235

Modules/Macros

  • CMQXRSTF
    

Fix information

  • Fixed component name

    WMQ Z/OS 8

  • Fixed component ID

    5655W9700

Applicable component levels

  • R000 PSY UI38235

       UP16/07/06 P F607 ¢

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":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
02 August 2016