PI58256: MQ Z/OS: MQ IS NOT NOTIFIED OF MESSAGES ARRIVING ON A SHARED QUEUE DUE TO A MISSING IXLLIST REQUEST=MONITOR_EVENTQ

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• The initial problem report was that messages remained on a
  shared request queue for the CICS-WebSphere MQ bridge. The
  bridge monitor transaction CKBR was not retrieving the messages
  and was in a GETWAIT. Other types of applications getting from
  a shared queue could also fail to get messages.
  
  Some messages are gotten--presumably ones already on the queue
  when it is opened.  After the last MQGET receives 2033
  MQRC_NO_MSG_AVAILABLE, new messages put to the queue are not
  gotten because MQ's list transition exit is not driven by XCF.
  MQ had not issued IXLLIST REQUEST=MONITOR_EVENTQ.
  
  Under normal circumstances, the REQUEST=MONITOR_EVENTQ is
  issued when the queue manager first connects to an application
  structure when a shared queue is opened. However, if the
  connection request is due to RECOVER CFSTRUCT processing, the
  REQUEST=MONITOR_EVENTQ is not issued. The queue manager should
  disconnect from the application structure once the recover
  processing is complete. Then the next time an application tries
  to open a queue using the structure, the queue manager will
  connect to the structure and issue the REQUEST=MONITOR_EVENTQ.
  In this failing case, the queue manager did not disconnect from
  the structure once the RECOVER CFSTRUCT processing completed.
  
  The missing disconnect is due to a timing window when the queue
  manager's ENF 35 processing (e.g. IXCYEnfFunctionStrAvail)
  or an application trying to open a queue on the structure
  takes place at the same time as RECOVER CFSTRUCT processing
  (this is due to SCB_Open_Count for the Expiry queue containing
  2 when CSQE_Close_Recover processing is performed at the end of
  RECOVER CFSTRUCT processing).
  
  L2 Verification details:
  In IPCS for a dump that includes MQ and the application
  structure (see technote
  http://www.ibm.com/support/docview.wss?uid=swg21177414)
  - VERBX CSQWDPRD 'SUBSYS=qmgr,DMC=1'
    Find the structure name associated with the queue
  
  - VERBX CSQWDPRD 'SUBSYS=qmgr,CFS=1'
    - Find the structure name and record the "Connection Id"
      under the STRB for that structure
    - Find the queue name and record the "Com/Uncom Put List No."
  
  - STRDATA ALLDATA DETAIL
    Find 'EVENT QUEUE CONTROLS DETAIL REPORT' and look for the
    Connection Id and List Number from the step above, for
    example:
  
    Event Queue Controls Connection ID... 01
     Number of EMCs dumped............. 1
     Event Queue Controls Status....... Complete
     Event Queue Type ................. Entry
     Event queue transition exit....... No        <===
     Event queue monitoring active..... No        <===
     Event notification vector index... 0
     Number of EMCs queued............. 1
     Number of state transitions....... 152
  
       Connection ID.................. 01
       List Number.................... 7
       Notification Type ............. First
       Key Type ...................... Entry
  
  
  Additional Symptom(s) Search Keyword(s):
  Queue Sharing Group QSG
  hang hung  curdepth depth
  

Local fix

• To recover from the problem, stop and restart the queue manager
  after the CSQE131I message, which indicates RECOVER CFSTRUCT
  processing has completed.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 *
  *                 Release 1 Modification 0.                    *
  ****************************************************************
  * PROBLEM DESCRIPTION: Applications getting messages from      *
  *                      shared queues and matching on MessageId *
  *                      and/or CorrelId are not notified when   *
  *                      matching messages are put to the queue  *
  *                      when the structure was previously       *
  *                      recovered (by RECOVER CFSTRUCT, or      *
  *                      RECAUTO processing) on the same queue   *
  *                      manager.                                *
  *                      In some cases the structure is not      *
  *                      disconnected correctly at queue manager *
  *                      shutdown, leading to IXL016I reporting  *
  *                      connector termination with              *
  *                      REASON=FAILURE.                         *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  During application structure recovery, a connection is made to
  the failed structure for the duration of the recover operation.
  In most circumstances this connection will only be used by the
  recover operation, and so the connection does not issue
  MONITOR_EVENTQ, as this is not needed for structure recovery.
  
  However it is possible for the connection to be used by another
  task that attempts to use the structure between recovery marking
  the structure as recovered and recovery disconnecting from the
  structure. In these cases, the structure is not disconnected
  and other tasks continue to use the existing connection to the
  structure. If any of these tasks perform operations that are
  reliant on MONITOR_EVENTQ having been issued, such as MQGET
  matching on MessageId or CorrelId, these operations do not
  behave correctly.
  
  In addition, if CSQEENF2 attempts to reconnect to the structure
  in response to an ENF35 event while structure recovery is still
  taking place, a use count is incorrectly set in one of the
  structure control blocks, preventing the structure from being
  disconnected normally, and causing all subsequent tasks using
  the structure to reuse the connection without event queue
  monitoring.
  

Problem conclusion

• CSQECONN is changed to issue a MONITOR_EVENTQ request to start
  event queue monitoring, and to correctly update the structure
  interest map (eSTIM) when connecting is made by structure
  recovery processing, so that the connection is in a suitable
  state to be reused by other tasks.
  CSQEOPEN is changed to prevent ENF 35 processing leaving the
  structure permanently connected.
  100Y
  CSQECONN
  CSQEOPEN
  

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:

  PI58453 UI36214

Modules/Macros

• CSQECONN CSQEOPEN
  

Fix information

• Fixed component name

  WMQ Z/OS V7

• Fixed component ID

  5655R3600

Applicable component levels

• R100 PSY UI36214

     UP16/04/12 P F604 ¢

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.