A fix is available
APAR status
Closed as program error.
Error description
IMS was recycled while MQ stayed up. After the recycle, MQ would not reconnect. START OTMA failed; no error message issued to the joblog; MQ / IMS connection hang. The 'partner active' request for IMS 'A' is queued-up waiting for the CSQ2CTL0 task to process it. However, the CSQ2CTL0 task is waiting for the CSQ2MEM0 task associated with IMS 'B' to end. However, the CSQ2MEM0 is waiting for an IME in IMS 'B' to end. There is code in CSQ2MEM1 to force any IME's to end, but there is a window in which an IME can be created which will cause CSQ2MEM0 to hang as seen here. (which will then cause the connect/disconnect of other IMS systems to hang as seen here).
Local fix
Recycle MQ
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 0 Modification 1 and Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: IMS disconnected from a Qmgr while * * processing an IMS Bridge task but * * is unable to reconnect. * **************************************************************** * RECOMMENDATION: * **************************************************************** IMS is shutdown (or a STOP OTMA command is issued). When it is started again (or a START OTMA command is issued) it does not reconnect to the Qmgr. The CSQ2011I and CSQ2010I messages are not seen at the Qmgr. When IMS is stopped, CSQ2MEM1 is invoked during shutdown processing. It will check to see if there any active CSQ2QCP0 and CSQ2QCP1 SRBs and posts them to complete due to Shutdown, then waits for them to finish before continuing. However, in this case, there is a timing window where a CSQ2QCP1 IMS Bridge task is not active at the time the check is done, but does become active just after, which means it is never posted. CSQ2MEM1 will continue to wait for the SRB to finish and the disconnect is never done. The Qmgr cannot use the IMS Bridge and has to be cancelled because it will not shut down in this situation.
Problem conclusion
CSQ2MEM1 has been altered to check in KillQCP1 and WaitForQCP1 if a Shutdown Post has already been issued and if not to do one. 010Y 100Y CSQ2MEM1
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PI10147
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
010
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-01-22
Closed date
2014-06-12
Last modified date
2014-08-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI18774 UI18775
Modules/Macros
CSQ2MEM1
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
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":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.0.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
04 August 2014