IBM Support

PM53107: WMQ: STARTUP OF A SHARED CHANNEL HANGS. OTHER ATTEMPTS TO START IT GET CSQX478E CHANNEL IS ACTIVE, CONNECTION TAG IN

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Error DescriptionÏ
    The reported environment was:
    All the LPARs in a Queue Sharing Group (QSG) were IPL'd.
    Afterwards, the MSTR and CHIN jobs all started and appeared to
    be working. However, shared inbound channels had problems. Any
    connection coming in using the QSG VIPA name hung if it was
    sent to the first queue manager up. If it was sent to one of
    the other QSG members first, it worked.  In the hang scenario,
    if the others queue managers then tried to start the shared
    channel, they got
    CSQX478E CSQXRCTL Channel <channel_name) is active  on
    <qmgr_id>, connection tag in use
    .
    Once the first queue manager up was stopped, everything worked
    fine. The queue manager was then restarted and worked fine also.
    .
    The channel hang was due to a deadlock. A channel was
    waiting for the XSCS semaphore as requested by routine
    rriInitSess. The DPRO that was holding the XSCS semaphore was
    waiting for the XSTA semaphore, requested by routine
    rriAddStatusEntry. The XSTA semaphore was held by a DPRO that
    was waiting to be dispatched on a particular dispatcher TCB.
    The DPRO running on that dispatcher TCB was currently in a
    WAIT, in CSQXLOCT, waiting for a conversion table to be loaded
    by the CSQXSUPR TCB. However, the CSQXSUPR TCB was in routine
    riiCheckChannels waiting for the XSTA semaphore. So, there was
    a deadly embrace.
    

Local fix

  • Local Fix&#207;
    Restart the channel initiator or entire queue manager that is
    suffering the deadlock.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
    *                 Release 0 Modification 1.                    *
    ****************************************************************
    * PROBLEM DESCRIPTION: Deadlock occurs between supervisor TCB  *
    *                      and dispatcher TCB. Channel initiator   *
    *                      commands are not processed and channels *
    *                      on the affected dispatcher will hang.   *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    A timing window exists where it's possible for a channel to
    obtain the XSTA channel status table semaphore and yield control
    to another channel process on the same dispatcher TCB, which
    then requests a load of a data conversion table be performed by
    the supervisor TCB. The supervisor TCB is unable to process this
    load request as it is attempting to obtain the XSTA semaphore
    held by the first channel in order to process any channels in
    retry.
    
    Because the channel requesting the load of the conversion table
    does not correctly yield control back to the dispatcher code,
    the first channel is not given an opportunity to execute and
    therefore is unable to release its semaphore. This results in a
    deadly embrace between the dispatcher and supervisor TCBs.
    

Problem conclusion

  • When waiting for a data conversion table to be loaded, a channel
    process will now correctly issue a dispatcher wait rather than
    an MVS wait to ensure that other channels running on the same
    dispatcher TCB are able to release any semaphores they are
    holding.
    010Y
    CSQDLOCT
    CSQXCNVT
    CSQXLOCT
    CSQXSPRT
    

Temporary fix

Comments

  • &#215;**** PE12/07/25 FIX IN ERROR. SEE APAR PM69566  FOR DESCRIPTION
    &#215;**** PE13/05/07 FIX IN ERROR. SEE APAR PM81886  FOR DESCRIPTION
    

APAR Information

  • APAR number

    PM53107

  • Reported component name

    WMQ Z/OS V7

  • Reported component ID

    5655R3600

  • Reported release

    010

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    YesHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2011-11-29

  • Closed date

    2012-02-28

  • Last modified date

    2013-06-17

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

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

    PM58956 UK76598

Modules/Macros

  • CSQDLOCT CSQXCNVT CSQXLOCT CSQXSPRT
    

Fix information

  • Fixed component name

    WMQ Z/OS V7

  • Fixed component ID

    5655R3600

Applicable component levels

  • R010 PSY UK76598

       UP12/04/11 P F204

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:
17 June 2013