WMQ 7.0.1 and 7.1.0: Client channels using a shared listener and SHARECNV>1 may experience orphaned channel status entries, causing a build-up of rows in the CSQ.ADMIN_B_SCST table in DB2

Reported symptoms have included:

• Delayed responses when trying to do a STOP CHANNEL or DISPLAY CHSTATUS for a SVRCONN channel.
• Displayed response when displaying the channels using the ISPF panels ('List Channels'), and the count of channels given in the Active column is higher than expected.
• High CPU in the CHIN and MSTR address spaces.
• A high count for the number of channel status in response to a DISPLAY CHSTATUS(..) SHORT command, e.g.
CSQN205I COUNT= 149862, RETURN=00000000, REASON=00000000
  or the CSQOLCAA List Channels panel has a status with a high number such as
149862 RUN
• CSQX489E CSQXRESP Maximum instance limit 50 exceeded because the stop of the current channels is taking so long to complete

To prevent orphaned status entries, do one of the following:

• Do not connect WMQ clients through a shared listener.
  It is not recommended to have a client connect to a shared listener as advised in the topic Shared inbound channels. It is better to connect through an INDISP(QMGR) listener together with Sysplex Distributor and DVIPA.
• Specify SHARECNV(0) in the SVRCONN channel definition.
  See Performance implications of sharing conversations on client-connection channels
• Until a PTF is available for PM81116, obtain an ++APAR from the support center.

Clean up the orphaned status entries.

The work-arounds above will not clean up entries that were already orphaned. The options below will take a while depending on how many rows there are:

• Restart the CHIN.
  Deletion of the orphaned entries will take place while the CHIN is terminating, so there may be a delay before it can be started again.
• Run a SPUFI command:
  DELETE FROM CSQ.ADMIN_B_SCST WHERE CHLNAME='<channelname>'
  AND QSGNAME='<qsgname>';
  where <channelname> and <qsgname> are replaced as appropriate for your system.
  
  There might be contention for the table.
  
  You will get CSQX485E "Shared channel status error" and an FFST if a client ends after its entry has been deleted. These will not be a big impact, if there are not too many active clients at the time.
• Delete and redefine the SVRCONN channel.
  This option will have more overhead than the SPUFI option due to the involvement of the MSTR and CHIN jobs in doing the clean-up.