IBM Support

PM82427: MQCONNX CALL RETURNS WITH MQRC_ALREADY_CONNECTED WHEN MQ JMS ISSUES THE MQCONNX CALL FOR A NEW JMSCONNECTION

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • You ran traces and found the following
    From a JMS client perspective, the connection ID is zero
    in the traces.
    The ConnectionId field in the MQCNO does not get filled in
    by the qmgr.
    2002 (07D2) x'07D2' (RC2002)  MQRC_ALREADY_CONNECTED
    .
    Additional symptom:
    .
    com.ibm.msg.client.wmq.internal.WMQConsumerShadow.close
    With a JMS application running in an RRS enabled environment,
    when one thread issues a receive call with a timeout of
    zero (unlimited wait).
    On another thread, close() is issued on the
    JMSConnection.
    .
    With the fix for PM82427, the close() call results in
    the waiting thread ending its wait, and the close is able
    to complete as expected.
    NOTE:  The WebSphere Steplib must points to the
    MQ SCSQAUTH dataset that has the fix applied, and restart
    both WMQ and WebSphere AppServer S to ensure that the
    fix is picked up.
    

Local fix

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
    *                 Release 0 Modification 1 and Release 1       *
    *                 Modification 0.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: Publications by other WSAS (WebSphere   *
    *                      Application Server) JMSConnections are  *
    *                      ignored for an application using        *
    *                      bindings mode to connect to the queue   *
    *                      manager and subscribing on a topic with *
    *                      the noLocal option set.                 *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    noLocal indicates that the subscriber should not return
    publications which were made by the subscriber's own
    JMSConnection.
    
    With this configuration, the subscriber correctly ignores
    messages published by the local JMSConnection.  However, it also
    ignores publications by other WSAS bindings JMSConnections, so
    the application is not given messages which it should have been.
    
    The underlying problem is an issue in MQCONNX processing.
    
    The JMS code uses a unique connection identifier in messages to
    determine whether they come from the current connection or not.
    This connection identifier is obtained on the MQCONNX call to
    WMQ, in the MQCNO.ConnectionId field.
    
    For normal MQCONNX calls, the ConnectionId is set in CSQMCUWT if
    the MQCNO is version 5 or higher.
    
    In the WAS bindings mode case, however, the use of RRS contexts
    means that the WMQ JMS code uses the following sequence of calls
    to establish a new connection context:
    
    MQCONN is called to ensure the TCB is connected to WMQ.
    
    A Set context is issued to create a new context.
    
    MQCONNX is called to obtain the ConnectionId.
    
    When processing the MQCONNX call, CSQBCON detects that the TCB
    is already connected to WMQ, and returns MQRC_ALREADY_CONNECTED
    without calling CSQMCUWT.  This causes the ConnectionId to
    remain as all zeros, so the JMS code determines that all
    messages with ConnectionId of zeros come from the subscriber's
    own JMSConnection.
    

Problem conclusion

  • In this situation, the code has been changed to obtain the
    ConnectionId on the MQCONNX call.
    010Y
    100Y
    CSQBCON
    CSQMCUWT
    

Temporary fix

Comments

APAR Information

  • APAR number

    PM82427

  • Reported component name

    WMQ Z/OS V7

  • Reported component ID

    5655R3600

  • Reported release

    010

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2013-02-08

  • Closed date

    2013-04-29

  • Last modified date

    2013-08-14

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

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

    UK93901 UK93902

Modules/Macros

  • CSQBCON  CSQMCUWT
    

Fix information

  • Fixed component name

    WMQ Z/OS V7

  • Fixed component ID

    5655R3600

Applicable component levels

  • R010 PSY UK93901

       UP13/06/14 P F306

  • R100 PSY UK93902

       UP13/06/14 P F306

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":"7.0.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
14 August 2013