PH35587: IBM MQ IN A QSG, WHEN ISSUING STOP CHANNEL INBOUND CONNECTION REQUESTS MAY STILL BE ALLOWED TO START THE MQ CHANNEL

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• If the STOP CHANNEL commands are issued while an active channel
  instance still exists, then the processing works as intended
  and future connections are not allowed.
  It is when there are no active connections that STOP CHANNEL
  processing does not work as intended. The first channel
  disposition stopped will be blocked, but the second will not.
  As an example, if STOP CHANNEL CHLDISP(SHARED) is issued first
  then an inbound request for a private connection is not being
  blocked. Similar behaviour occurs if STOP CHANNEL
  CHLDISP(PRIVATE) is issued first, in which case inbound
  requests for a SHARED connection are not blocked.
  -
  Hursley analysis finds that when there are no active
  connections, the first STOP CHANNEL doesn't find an in-memory
  copy of the channel status, so goes ahead and creates a
  disabled entry with the disposition provided in the CHLDISP.
  The second STOP CHANNEL then finds this entry and notes that
  it's only a partial match. Due to the current logic, it decides
  not to create a disabled entry for that disposition and instead
  issues a CSQX613I message.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 1 Modification 0 and Release 2       *
  *                 Modification 0.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: When using both INDISP QMGR and INDISP  *
  *                      GROUP listeners for inbound             *
  *                      connections, to prevent a SVRCONN from  *
  *                      accepting inbound connections, both the *
  *                      SHARED and PRIVATE CHLDISP need to be   *
  *                      stopped. If there are no active         *
  *                      connections when the STOP CHANNEL       *
  *                      commands are issued, then connections   *
  *                      may still be accepted.                  *
  ****************************************************************
  A SVRCONN channel defined on a QMGR in a QSG has two separate
  CHSTATUS entries, one for inbound connections on the group
  listener, and the other for inbound connections on the QMGR
  private listener. Each of these instances is handled separately,
  and needs to be started/stopped separately. A defect in the code
  results in only one of the channel dispositions creating a
  disabled channel status entry if the STOP CHANNEL commands are
  issued while there are no active connections. The second
  disposition to be stopped will be accompanied by a CSQX613I
  message in the CHIN.
  

Problem conclusion

• The code has been corrected to always block connections when
  issuing a STOP CHANNEL command for a particular disposition. A
  STOP CHANNEL command for both the SHARED and PRIVATE CHLDISP
  will still be needed to block both inbound connection routes.
  

Temporary fix

Comments

APAR Information

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

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

  UI75304 UI75306

Modules/Macros

• CSQXRCMS
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R100 PSY UI75306

     UP21/05/29 P F105

• R200 PSY UI75304

     UP21/05/29 P F105

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.