PH41987: MQ Z/OS:QMGR SHUTDOWN HANG THAT OCCURS FOLLOWING AN ABEND IN THE EXPIRY TASK

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The client hit QMGR ssidMSTR  fails to stop by command stop
  qmgr mode(force) until it's canceled(CHINIT can be stopped
  normally). It's recorded in MSTR joblog and system log but in
  MSTR trace it printed STOP QMGR NORMAL COMPLETION .
  The QMGR common dump taken at shutdown tells the qmgr shutdown
  process is stuck waiting for the expiry tasks to end - the dump
  shows that 4 of the 5 expiry workers have completed normally.
  The 5th task had already ended abnormally, shortly after the
  queue manager was started:
  13.21.07 STC03600 CSQY291E CSQWDSDM SDUMPX FAILED,
  RC=00000B08,CSQM,ABN=5C6-00C90900,LOC=CSQILPLM.CSQIEXP2+00002D70
  This abnormal termination of the task did not decrement the
  count of running tasks, leading to the shutdown hang. The
  earlier abend occurred when an unexpected record is found on a
  page while looking for expired messages on the pagesets.
  The 5C6 abend dumps tells the 5C6 abends are occurring when the
  expiry task attempts to locate expired messages on queues
  during startup.
  For the dump provided, the abend occurs when processing queue
  Q1 and the page at the head of the priority 0 persistent
  subqueue, psid 2 page 00396B, has been loaded. When examining
  the contents of this page, it doesn't contain the expected IRH8
  records for the queue - instead it contains the IRH9 record for
  a message put to Q2 with timestamp: 2021/05/20 12:57:42.789435.
  As this is not expected, it results in the task abending.
  ADDITIONAL SYMPTOM :
  Attempts to DELETE a queue may fail with errors : CSQM110I
  indicating the queue HAS INCOMPLETE UNITS OF RECOVERY, even
  though DIS QSTATUS indicates UNCOM(NO). Dump analysis will
  indicate no X LOCK associated with the named queue. In trace
  error code > CSQI_UNCOMMITTED_ACTIVITY constant(00c9001Cx) <
  can be checked for if diagnostic is active during DELETE attempt
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of IBM MQ for z/OS Version 9       *
  *                 Release 2 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Queue manager hangs during shutdown     *
  *                      following an earlier expiry task        *
  *                      abend.                                  *
  ****************************************************************
  During queue manager startup one of the expiry tasks detected
  an error condition while looking for expired messages and
  abended, leaving the remaining expiry tasks to perform expiry
  processing.
  Later, when the queue manager was stopped CSQIESTP resumed the
  expiry tasks and waited until they had all completed and
  decremented the count of active tasks. However as the failed
  task had not decremented this count when it abended, CSQIESTP
  waits indefinitely.
  

Problem conclusion

• CSQIEXP2 is changed to decrement the count of active expiry
  tasks when ending abnormally.
  

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:

  UI78652

Modules/Macros

• CSQIEXP2
  

Fix information

• Fixed component name

  IBM MQ Z/OS V9

• Fixed component ID

  5655MQ900

Applicable component levels

• R200 PSY UI78652

     UP22/02/10 P F202

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.