A fix is available
APAR status
Closed as program error.
Error description
A QMGR was disconnecting from the CF structure after receiving the EEPLXESRECOMMENDACTION event, but before processing the USYNC event on the pending queue that was put there as a result of another queue manager in the QSG disconnecting from the CF structure and triggering a EEPLDISCFAILCONNECTION event. When it reconnects to the structure, it runs recovery for its own connection to the structure. After completing phase 2 of the recovery, it will go ahead and initiate pending USYNCs. As the USYNC event from the previous connection is still on the queue, with the previous connection token, the IXLUSYNC call returns with IXLRSNCODEBADCONTOKEN. The structure task issues the 00C51039 abend. . DUMP TITLE=xxxx,ABN=5C6-00C51039,U=SYSOPR,C=R3600.710.CFM -CSQESTE ,M=CSQGFRCV,LOC=CSQELPLM.CSQESTE +00002FC6
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: The queue manager issues abend 00C51039 * * followed by abend 00C510AD and queue * * manager early termination with reason * * 00C510AB. * **************************************************************** * RECOMMENDATION: * **************************************************************** The queue manager loses connectivity to a CF structure whilst still having eRQE elements on the pending usync queue. When the queue manager disconnects, these elements are left on the queue, whilst still holding a reference to the connection token for the connection that is being closed. After the CF becomes available again, the queue manager reconnects to the CF and the structures hosted on it. As part of reconnect processing, pending usyncs are initiated. As the eRQE element on the queue has a reference a now invalid connect token, the IXLUSYNC call fails with IXLRSNCODEBADCONTOKEN and the queue manager abends with 00C51039.
Problem conclusion
The code was changed to clear the pending usync queue of elements referencing the current connection token. Thus when the queue manager reconnects to the CF and the structures hosted on it, there are no eRQE elements with references to the old connection token, preventing the 00C51039 abend from occurring. 100Y CSQESFDP
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PM92901
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
YesHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2013-07-12
Closed date
2013-08-23
Last modified date
2013-10-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK96973
Modules/Macros
CSQESFDP
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UK96973
UP13/09/27 P F309
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.1","Edition":"","Line of Business":{"code":"","label":""}}]
Document Information
Modified date:
04 October 2013