A fix is available
APAR status
Closed as program error.
Error description
Change Team finds a client application is doing an MQGET with convert. Conversion of the message data fails. In this case a function is called to determine whether the conversion failure was the result of the data being larger than the available buffer. This function allocates a larger buffer and frees the original one. On return from the function, the calling code gets updated to refer to the new buffer, however there is a pointer into the buffer which does not get updated. This means it still points into the freed buffer leading to the ABEND0C4 when a field is accessed using that pointer.
Local fix
NO LOCAL FIX
Problem summary
**************************************************************** * USERS AFFECTED: All users of WebSphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: Preforming MQGET calls with convert * * through a channel can result in a large * * amount of storage use in the cases * * where the message cannot be converted. * * This results in MQGET calls returning * * MQRC_BUFFER_LENGTH_ERROR (MQRC 2005) * * after a large number of failed MQGETs * * with MQRC_NOT_CONVERTED (MQRC 2119). * **************************************************************** * RECOMMENDATION: * **************************************************************** During the message conversion for the MQGET with MQGMO_CONVERT, the conversion can fail due to the buffer being smaller than required to convert the message. This is expected and the staging buffer used is increased in size to handle this and the conversion is reattempted. However in the scenario where the conversion fails for another reason, the staging area is still increased and the conversion reattempted. This larger staging area is not decreased after this. This can result in a large amount of storage use when a channel performs many MQGET with conversion calls which fail. Additionally when large staging buffers are freed ,in some circumstance the freed staging buffer may still be referenced, resulting in a 0C4 abend.
Problem conclusion
The processing around conversion has been updated to only increase the size of the staging buffer when the conversion failed as the staging buffer is not big enough to hold the converted message. This prevents the staging buffer being increased in size unnecessarily, stopping the storage shortage due to this issue. Additionally after expansion, it ensures that the new staging buffer is referenced. 100Y CMQXRSTF
Temporary fix
Comments
APAR Information
APAR number
PI31467
Reported component name
WMQ Z/OS V7
Reported component ID
5655R3600
Reported release
100
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2014-12-12
Closed date
2015-02-17
Last modified date
2015-05-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
PI34149 UI25204
Modules/Macros
CMQXRSTF
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UI25204
UP15/04/17 P F504
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 May 2015