APAR status
Closed as program error.
Error description
When using the WebSphere MQ classes for Java API to get messages from a WebSphere MQ queue, where the CCSID of the message is 1200 and Format is of type MQSTR, a call to the method readStringOfByteLength(int) on the MQMessage object returns a string of question mark characters, '?', and not the expected message data. This issue occurred after upgrading from the WebSphere MQ v6 classes for Java to the WebSphere MQ v7.1 classes for Java.
Local fix
Change the WebSphere MQ classes for Java application to use the get message option (GMO) "MQGMO_CONVERT" to request that the queue manager performs the conversion of the message payload data before returning it to the client.
Problem summary
**************************************************************** USERS AFFECTED: This issue affects users of the: - WebSphere MQ v7.1 classes for Java - WebSphere MQ v7.5 classes for Java - IBM MQ v8 classes for Java who have applications which receive MQSTR messages from a WebSphere MQ queue, where the bytes of the message payload are encoded in UTF-16LE (UnicodeLittle) but the Coded Character Set Identifier (CCSID) of the message is 1200, 13488 or 17584 (the UCS-2 family of character encodings). Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: When consuming a message with a format of MQSTR using the WebSphere MQ classes for Java, if the Coded Character Set Identifier (CCSID) of the message was 1200 then the bytes of message payload would be interpreted using the Java code page UTF-16. This is not the valid convention used by WebSphere MQ for the UTF-16 family of character encodings. For WebSphere MQ, when using a 2-byte Unicode encoding (eg. CCSID 1200, 13488, or 17584), the byte order of the Unicode data is dictated by the 'Encoding' value of the corresponding MQ message header. For example, in the case where the message payload follows on from the MQMD, the MQMD's 'Encoding' value is used to determine the byte order of the UTF-16 character sets, and not the CCSID value alone. The mapping of CCSID values 1200, 13488 and 17584 to the Java java.nio.charset.Charset names should therefore have been as follows: Encoding = 0x111 (int 273), --> UTF-16 Encoding = 0x222 (int 546), --> UTF-16LE UnicodeBigMarked (when using the property documented in APAR IV08982) However, for a WebSphere MQ classes for Java application, the Encoding value was not used to to determine the byte order of the message character data and as a result, a CCSID value of 1200 was always mapped to UTF-16. This meant that if the character data contained within the message payload had been encoded in UTF-16LE, it was not interpreted correctly and the application received a Java String containing corrupted data from returned String object from a call to the method: com.ibm.mq.MQMessage.readStringOfByteLength(int numberOfbytes)
Problem conclusion
The WebSphere MQ classes for Java code to manage the interpretation of messages which are encoded in one of the CCSID values: 1200 13488 17584 was modified such that the mapping of the CCSID to Java code page is based on the value of the 'Encoding' field in the MQMD of message like so: UTF-16 (for Encoding = 0x111 or int 273) UnicodeBigMarked (with property from IV08982) UTF-16LE (for Encoding = 0x222 or int 546) Note that the current convention for CCSID mapping used outside of the WebSphere MQ environment is: CCSID 1200 = UTF-16 big endian encoded CCSID 1202 = UTF-16 Little endian encoded CCSID 1204 = UTF-16 with byte order mark Because this interpretation differs from that used by WebSphere MQ, APAR IV40180 added an additional property to the WebSphere MQ classes for JMS, that has now been extended to the WebSphere MQ classes for Java, to enable compatibility with other resources. By default this property is disabled to maintain behaviour for WebSphere MQ according with its documentation. To change this behaviour, the property and value to enable the alternative function is: com.ibm.mq.cfg.CCSID.MapUtf16ByteOrderByCCSID=YES When this is enabled, the WebSphere MQ message's property 'Encoding' is not used to determine the byte order of the character data. The result of this is that the WebSphere MQ message's CCSID is solely used to decode the byte data into character form. For example, a message encoded in CCSID 1200 will always be decoded using the "UTF-16" Java Character set encoding, independent of WebSphere MQ message's 'Encoding' property. In addition, this APAR also forward ports APAR IV08982: http://www-01.ibm.com/support/docview.wss?uid=swg1IV08982 to the IBM MQ v8 classes for JMS. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v7.1 7.1.0.8 v7.5 7.5.0.7 v8.0 8.0.0.5 The latest available maintenance can be obtained from 'WebSphere MQ Recommended Fixes' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006037 If the maintenance level is not yet available information on its planned availability can be found in 'WebSphere MQ Planned Maintenance Release Dates' http://www-1.ibm.com/support/docview.wss?rs=171&uid=swg27006309 ---------------------------------------------------------------
Temporary fix
Comments
APAR Information
APAR number
IV74821
Reported component name
WMQ LIN X86 V7
Reported component ID
5724H7224
Reported release
710
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2015-07-06
Closed date
2015-12-31
Last modified date
2016-01-04
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following:
Fix information
Fixed component name
WMQ LIN X86 V7
Fixed component ID
5724H7224
Applicable component levels
R710 PSY
UP
[{"Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSFKSJ","label":"WebSphere MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.1"}]
Document Information
Modified date:
08 March 2021