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

Obtain the fix for this APAR.

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Ï
  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 1 Modification 0.                    *
  ****************************************************************
  * 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.
  
  In addition, This fix addresses the same problem when conversion
  occurs as a result of specifying CONVERT(YES) on a Sender
  Channel.
  

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.
  100Y
  CSQACCF
  CSQACSTR
  CSQACS64
  CSQALOCT
  CSQAVICD
  CSQXADPM
  CSQXCNVT
  CSQXLOCT
  CSQXSPRT
  HMS7100J
  

Temporary fix

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

Comments

APAR Information

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

  PM53107

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

  UK83859

Modules/Macros

• CSQACCF  CSQACSTR CSQACS64 CSQALOCT CSQAVICD
  CSQXADPM CSQXCNVT CSQXLOCT CSQXSPRT HMS7100J
  

Fix information

• Fixed component name

  WMQ Z/OS V7

• Fixed component ID

  5655R3600

Applicable component levels

• R100 PSY UK83859

     UP13/01/16 P F301 Ž

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.