PM19855: MQ DOESN'T QUIECSE AFTER STOP QMGR REQUEST BECAUSE CICS IS UNABLE TO DISCONNECT.

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• MQ will not quiesce if the CSQCAPX exit makes MQ API requests
  and the following flow events occur:    .
  1) The QMGR is started while CICS is down.
  2) CICS is started and then connects to MQ using either the
     MQCONN=YES or the CKQC Start method.
  3) MQ is STOPped MODE=QUIESCE
    MQ will wait while CICS disconnects, but CICS is unable to
  disconnect because it thinks that there is a task still using
  MQ when there isn't.
    The CICS / MQ connection in CICS is set to Quiescing and the
  MQLOC will have it's CTTASKS (at +x'7C') set to 1.  The CTTASKS
  is not decremented to 0.  The various invocations of a CSQCAPX
  exit that makes MQ API requests (and drives the DFHMQTRU) may
  increment the CTTASKS count but not decrement it.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION: The WMQ address space hangs when        *
  *                      shutdown via the console using          *
  *                      +MQnn STOP QMGR MODE(QUIESCE)           *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  An attempt is made to quiesce a WMQ QMGR, connected to a CICS
  region which has the CICS-WMQ crossing exit CSQCAPX enabled,
  using the +MQnn STOP QMGR MODE(QUIESCE) console command, but
  the QMGR hangs indefinitely.
  This is because the Crossing Exit has been called incorrectly
  by CICS-WMQ Adapter code when issuing its own WMQ API calls.
  This has resulted in a task counter being incremented without
  ever being decremented, leading the Adapter to believe there
  is an active task still using it, when no such task exists.
  

Problem conclusion

• DFHMQTRU has been changed such that, when the clot is being
  initialized, if the code is being driven by DFHMQCON
  (ie cics_mq_connect_processing is on), flag
  dfhmqlot.fSkipApiexit is set on, causing the invocation of
  CSQCAPX to be by-passed.
  

Temporary fix

• FIX AVAILABLE BY PTF ONLY
  

Comments

APAR Information

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

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

  UK60996

Modules/Macros

•    DFHMQTRU
  

Fix information

• Fixed component name

  CICS TS Z/OS V4

• Fixed component ID

  5655S9700

Applicable component levels

• R600 PSY UK60996

     UP10/10/06 P F010

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.