A fix is available
APAR status
Closed as program error.
Error description
The problem occurs when a message that was put at V6 is got by a client with SHARECNV > 0 (SHARECNV greater than 0) and the size of the message is greater than 4016. . The queue-manager will obtain a new get-buffer for the client as the size of the default get-buffer is not large enough for the message. However, if a message from V6 is being processed, CSQIMGE5 does not update its pointers to address the new get-buffer. This results in the client being returned incorrect message data. . +CSQX208E ?xx CSQXRESP ERROR RECEIVING DATA, CHANNEL ChannelName, CONNECTION xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxxx) (QUEUE MANAGER ????) TRPTYPE=TCP RC=00000461 (ECONNRESET) REASON=00000000
Local fix
Code SHARECNV=0
Problem summary
**************************************************************** * USERS AFFECTED: All users of Websphere MQ for z/OS Version 7 * * Release 1 Modification 0. * **************************************************************** * PROBLEM DESCRIPTION: A client issued MQGET may return * * incorrect message data when getting * * large (over 4016 byte) persistent * * messages that were PUT by a V600 queue * * manager. * **************************************************************** * RECOMMENDATION: * **************************************************************** Persistent messages over 4016 bytes in size, that were put to a queue prior to a migration from V600 may return incorrect message data. The buffer returned to the client application may not contain the message that was initially put to the queue. A larger buffer has to be obtained to service the MQGET of the large messages held on the queue. Due to the messages being originally put by a V600 queue manager, when the large message is retrieved, the buffer returned to the client does not contain the correct message data. Once a new buffer is obtained it is used while large messages continue to be retrieved and subsequent client MQGET requests will return the correct message data. As such this scenario may only occur on the first request for a larger message.
Problem conclusion
The internal call used when a client application attempts to retrieve a message through a MQGET in this circumstance has been changed to ensure the new buffer is referenced after being obtained. As such the buffer returned to the calling client will contained the correct message data. 100Y CSQIMGE5
Temporary fix
********* * HIPER * *********
Comments
APAR Information
APAR number
PM82857
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-02-15
Closed date
2013-02-26
Last modified date
2013-05-06
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
UK92013
Modules/Macros
CSQIMGE5
Fix information
Fixed component name
WMQ Z/OS V7
Fixed component ID
5655R3600
Applicable component levels
R100 PSY UK92013
UP13/04/04 P F304
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:
06 May 2013