A fix is available
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 8 * * Release 0 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. 000Y CSQECONN CSQEOPEN
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI58453
Reported component name
WMQ Z/OS 8
Reported component ID
5655W9700
Reported release
000
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2016-03-03
Closed date
2016-03-15
Last modified date
2016-05-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI36217
Modules/Macros
CSQECONN CSQEOPEN
Fix information
Fixed component name
WMQ Z/OS 8
Fixed component ID
5655W9700
Applicable component levels
R000 PSY UI36217
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.
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
04 May 2016