A fix is available
APAR status
Closed as program error.
Error description
The channel which encounters a problem is a multiplexed SVRCONN with SSL enabled. The following processing occurred in the run-up to the 0C4 abend: - The channel has several conversations active, but none of them have been actively doing any MQ work for some time. - As there has been no proper activity on the channel, the last few requests are all heartbeat flows which check that the channel connection is still ok while no real work is being done. - Because the channel is using SSL, and the qmgr is configured with an SSL key reset value, the first piece of work after a heartbeat results in an SSL key reset being negotiated. - The last request from the client before the abend is the start of the processing for an SSL key reset, asking the server to pause channel activity (e.g. asynchronous consumers) so that the key reset can proceed uninterrupted. - The failing function, ccxReceiveThreadFn, is responsible for processing incoming requests from the client, and has a loop which handles one request at a time. While processing the pause request, it attempts to obtain a value from a field in the session control block (TraceIdentifier). The pointer to the session block (psess) is invalid, resulting in the 0C4. For the pause request, the psess variable isn't initialized, so it would contain a residual value from a previous client request. Generally this would still be a valid session for one of the conversations on the channel so the pause would work ok in most circumstances. In this case the last request before the heartbeats was a request to end a conversation. This would have resulted in psess being set to the session block for the conversation which is ending, and the session block would have been freed as part of the clean-up of the conversation.
Local fix
Problem summary
**************************************************************** * USERS AFFECTED: All users of IBM MQ for z/OS Version 9 * * Release 1 Modification 0 and Release 2 * * Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: When using a multiplexed SSL channel * * with multiple conversations, if an SSL * * key reset interval is specified, then a * * precise FAP flow involving a * * conversation disconnecting can result * * in an ABEND0C4 in the CHIN. * **************************************************************** As part of end of conversation processing, the CHIN frees control blocks which it no longer needs. A flaw in the multiplexed receiver code can result in one of these freed conversation blocks being reused. This code is primarily driven when performing an SSL key reset, and depending on whether the storage page has been released by RSM, an ABEND0C4 may occur.
Problem conclusion
The multiplexed receiver code has been changed to no longer reference freed MQ control blocks.
Temporary fix
Comments
APAR Information
APAR number
PH29229
Reported component name
IBM MQ Z/OS V9
Reported component ID
5655MQ900
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2020-09-07
Closed date
2020-10-13
Last modified date
2021-01-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UI72042 UI72043
Modules/Macros
CSQXCCAX
Fix information
Fixed component name
IBM MQ Z/OS V9
Fixed component ID
5655MQ900
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.
[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"100"}]
Document Information
Modified date:
05 January 2021