WebSphere MQ 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
A WebSphere MQ (WMQ) Client using shared conversations connects to the queue manager through the shared listener (INDISP(GROUP)). An entry (row) is added into the shared channel status table CSQ.ADMIN_B_SCST. The shared status entry will be orphaned (not deleted) if the last conversation to end is not the first conversation started, when SHARECNV is greater than 1 on the SVRCONN definition.
The problem will be fixed by PM81116. The following details the steps required to avoid the problem and to cleanup the orphaned rows.
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
- 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:
- Apply PM81116.
Until the fix can be applied, circumventions include:
- 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
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>'
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.