IV74821: WHEN UPGRADING MQ CLIENT FROM 6.0.2 TO 7.1 MESSAGE DATA IN IS UNREADABLE AND ONLY "?" ARE DISPLAYED.

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 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