PM19863: CICS MQ ADAPTER FAILS TO RESTART AFTER QUEUE MANAGER IS SUCCESSFULLY RESTARTED

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• - MQ queue manager is stopped with MODE(FORCE) or it abends.
  - The CICS region that was connected to that queue manager does
  not complete the disconnect from MQ because of tasks that were
  using MQ and don't abend right away.
  - Before the connection completes disconnection, MQ comes back
  up.
  - When all the tasks that are holding up the connection finally
  go away, CICS fully disconnects from MQ, then automatically
  reconnects to MQ, and then it automatically disconnects again.
  - When the dust settles, CICS is not connected to MQ.  It takes
  a manual re-connect to get CICS reconnected to MQ
  Additional Keywords: DFHMQ0309, 2059 , DFHMQ0341, DFHMQ0332 ,
  DFHMQ0364, DFHMQ0334, DFHMQ0307
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All                                          *
  ****************************************************************
  * PROBLEM DESCRIPTION: The CICS/WMQ adapter fails to           *
  *                      reconnect following a restart of the    *
  *                      WMQ QMGR address space after a forced   *
  *                      shutdown.                               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  When a forced shutdown of the CICS/WMQ adapter occurs, the
  monitor task CKAM will attempt to force any CICS/MQ tasks
  currently in-flight. In this case however, the CICS/MQ task in
  question does not end immediately because the program has a
  HANDLE ABEND which has caused the task to go into a lengthy
  delay. Consequently the task stays in the system whilst the
  CICS/MQ adapter has been successfully restarted.
  The task stays in the system because, after attempting the task
  force purge, CKAM will then run down the PEB (Pending Event
  Block) chain to see if any tasks are still active. In this
  case, it sees just one task is still running (ie the "last"
  task) so removes the entry from the PEB chain and posts onto
  the PEB2 chain to indicate that when this last task eventually
  finishes CKAM is free to honour the outstanding close of the
  connection.
  So, we then force purge this delayed task and its last action
  is to post another entry onto the PEB2 chain. We now have two
  entries on the PEB2 chain, but CKAM only purges the first one
  then completes the original connection close request.
  CKAM then restarts the connection (as the QMGR address space has
  been successfully restarted). However, during restart the PEB2
  chain is processed once again and the outstanding entry is
  found so CKAM immediately closes the connection again
  erroneously.
  

Problem conclusion

• DFHMQMON has been altered such that any duplicate Type2 Pending
  Event Blocks (PEBs) which may exist on the PEB chain are removed
  during shutdown of the CICS-MQ adapter connection.
  

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:

  PM22335 UK61586

Modules/Macros

•    DFHMQMON
  

Fix information

• Fixed component name

  CICSTS V3 Z/OS

• Fixed component ID

  5655M1500

Applicable component levels

• R500 PSY UK61586

     UP10/10/29 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.