PI20391: Z/OS SYSTEM HANG DUE TO MQ 14/06/20 PTF PECHANGE

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The z/OS system hung, and an IPL was required. A standalone dump
  showed that many jobs, including *MASTER*, DMPSRV, CONSOLE,
  OMVS, JES2, and user jobs such as brokers, were in an ENQ wait
  for resource NAME=MAJOR=NETMAGDB (a resource for a 3rd party
  product).  The ENQ was held by a broker job that was going
  through MEMTERM processing due to an ABENDS40D.
  .
  The dump of the *MASTER* address space showed that the TCB for
  memterm processing for the ENQ owner was waiting in MQ. SYSTRACE
  of the *MASTER* address space showed that the MEMTERM TCB was in
  a loop of WAIT, STORAGE RELEASE, and STORAGE OBTAIN  every
  second. The WAIT PSW was in CSQ3RRSX+x'185C' (UK94940) in
  routine SETDIE.  It was called from EBACTL_RETRY2 to wait for 1
  second at a time for EBACTL to be turned on for a thread for the
  broker job. The TCB for that thread was alrady gone.
  .
  The MQ change team found that the code added by PM75418 can
  cause memterm processing to hang indefinitely. Presumably the
  fact that memterm processing hung prevented subsequent memterm
  processing by z/OS from releasing the NETMAGDB ENQ.
  .
  Additional Symptom(s) Search Keyword(s):
  hang MQ NETMAGDB looping ABEND40D S40D ABEND 40D SAD
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
  *                 Release 0 Modification 1 and Release 1       *
  *                 Modification 0.                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: After applying the PTF for PM75418,     *
  *                      UK91873 / UK91874, MEMTERM processing   *
  *                      for an address space connected to MQ is *
  *                      hanging.                                *
  *                      The LPAR may potentially become         *
  *                      unresponsive.                           *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  The connected address space has experienced abends, and has then
  been MEMTERM'ed with S40D. During MEMTERM processing, context
  services has invoked CSQ3RRSX for END_CONTEXT processing. The
  ACE associated with the context has EBACTL set off, indicating
  that it is in MQ code. CSQ3RRSX therefore waits for EBACTL to be
  set back on.
  However, EBACTL will never get set back on as the address space
  that it was running under has been MEMTERM'ed.
  

Problem conclusion

• The code was changed to not wait for EBACTL to be turned back on
  if the connected address space has been MEMTERM'ed, preventing
  the hang from occurring.
  010Y
  100Y
  CSQARIB
  CSQMCLMT
  CSQMCTXE
  CSQMCTXS
  CSQ3AAES
  CSQ3AMT3
  CSQ3RRSF
  CSQ3RRSI
  CSQ3RRSM
  CSQ3RRSR
  CSQ3RRSX
  CSQ3RRXF
  CSQ5CONN
  CSQ5MONR
  

Temporary fix

• *********
  * HIPER *
  *********
  

Comments

APAR Information

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

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

  UI19493 UI19494

Modules/Macros

• CSQARIB  CSQMCLMT CSQMCTXE CSQMCTXS CSQ3AAES
  CSQ3AMT3 CSQ3RRSF CSQ3RRSI CSQ3RRSM CSQ3RRSR CSQ3RRSX CSQ3RRXF
  CSQ5CONN CSQ5MONR
  

Fix information

• Fixed component name

  WMQ Z/OS V7

• Fixed component ID

  5655R3600

Applicable component levels

• R010 PSY UI19493

     UP14/07/22 P F407 «

• R100 PSY UI19494

     UP14/07/22 P F407 «

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.