IT17427: JMS message properties corrupted after consuming while using migration mode with a non-ASCII based JVM file.encoding

APAR status

• Closed as program error.

Error description

• When running a JMS application that connected to a z/OS queue
  manager with the v8.0.0.5 MQ classes for JMS, a
  javax.jms.JMSException was thrown during an attempt to consume a
  message from a queue.  The exception had the form:
  
  javax.jms.JMSException: MQJMS1000: Failed to create JMS message.
  at
  com.ibm.msg.client.wmq.compat.jms.internal.ConfigEnvironment.new
  Exception
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.isM
  essageSelected
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.get
  Message
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rec
  eiveInternal
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rec
  eive
  at
  com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receiveIn
  boundMessage
  at
  com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receive
  at com.ibm.mq.jms.MQMessageConsumer.receive
  at MyApplication.myMethod
  Caused by: java.nio.charset.MalformedInputException: Input
  length = 1
  at java.nio.charset.CoderResult.throwException
  at java.nio.charset.CharsetDecoder.decode
  at com.ibm.mq.jmqi.system.JmqiCodepage.bytesToString
  at com.ibm.mq.jmqi.system.JmqiCodepage.bytesToString
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQJMSMessage.createJM
  SMessage
  at
  com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.isM
  essageSelected
  ... 8 more
  
  When the exception is thrown, the persistent message is not
  consumed from the queue.
  

Local fix

• Switch the JVM to use an ASCII compatible character encoding,
  such as UTF-8.
  This can be achieved by using the JVM startup argument:
  
    -Dfile.encoding=UTF-8
  
  Alternatively reconfigure the MQ-JMS application to not use
  migration mode to communicate with the queue manager.
  

Problem summary

• ****************************************************************
  USERS AFFECTED:
  Users of the IBM MQ classes for JMS, who are running their
  MQ-JMS classes in migration mode.
  
  Migration mode is configured in a number of alternative ways,
  including:
  
  (a) Setting the ProviderVersion property of a ConnectionFactory
  to the value "6", for example:
  
       MQConnectionFactory.setProviderVersion("6");
  
  (b) Connecting to a queue manager over a CHANNEL which has the
  SHARECNV value set to '0'.
  
  (c) Connecting to a queue manager which is earlier than version
  7.0.  Migration mode cannot be disabled in this scenario.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  When running in migration mode, the IBM MQ classes for JMS used
  the JVM's default character set to interpret some of the fields
  within the MQ message, during the translation to a
  javax.jms.Message object.
  
  The JVM's default character set is that returned by the method
  call:
  
    java.nio.charset.Charset.defaultCharset()
  
  This returned value is used to encode some of the character data
  fields within the MQMD, during the construction of the MQ
  representation of the JMS message, before then using the MQMD
  supplied CCSID field to convert them back into character data.
  
  The net result of this was that the CharsetDecoder would throw
  an exception if the byte sequence was not valid for the given
  JVM default CharacterSet.
  
  Because by default the MQMD character data is encoded using
  CCSID 1208 (UTF-8), in practice, this meant that the application
  received a JMSException when attempting to receive a message if:
  
  (a) The Format field as specified in the MQMD was not blank, or
  not the value "MQSTR   "
  
  (b) The JVM's file.encoding was set to a value which was not
  ASCII compatible, such as "IBM-500" (which is EBCDIC encoding)
  as commonly found when using a JVM on z/OS.
  
  
  If the MQMD Format field was set to "MQSTR   ", and the JVM is
  using a non-ASCII compatible file.encoding such a "IBM-500",
  then an exception would not be thrown when the application
  requested the message from the queue.  However the data stores
  on the JMS Message object was corrupted, for example the
  javax.jms.Message.toString() method might return data of the
  form:
  
  ----------------------------------------------------------
  JMSMessage class: jms_text
   JMSType:          null
   JMSDeliveryMode:  1
   JMSDeliveryDelay: 0
   JMSDeliveryTime:  0
   JMSExpiration:    0
   JMSPriority:      4
   JMSMessageID:
  ID:c3e2d840d4d8d6f84040404040404040d18345bb597ebc08
   JMSTimestamp:     -2244308363897810
   JMSCorrelationID: null
   JMSDestination:   null
   JMSReplyTo:       null
   JMSRedelivered:   false
     JMSXAppID: ????@@@@@@@@@@@@@@@@@@@@@@
     JMSXDeliveryCount: 1
     JMSXUserID: ????????@@@@
     JMS_IBM_Format: MQSTR
     JMS_IBM_MsgType: 8
     JMS_IBM_PutApplType: 28
     JMS_IBM_PutDate: ????????
     JMS_IBM_PutTime: ????????
  ----------------------------------------------------------
  
  If the JVM's file.encoding was not ASCII or EBCDIC compatible
  (such as UTF-16), then even with an MQMD Format value of "MQSTR
    " would result in an exception being thrown when attempting to
  receive the message.
  
  
  Finally, while investigating this problem it was also noticed
  that the JMSTimestamp property (which is intended to record the
  epoch time when the message was sent to the messaging provider)
  was being incorrectly calculated on JVMs which were not running
  with an ASCII compliant file.encoding.  This secondary issue
  occurred both when using migration mode (ProviderVersion="6")
  and in normal mode of operation.  This problem often resulted in
  a negative value being set in the JMSTimestamp property, as seen
  in the above example.
  

Problem conclusion

• The IBM MQ classes for JMS have been updated so that they use
  consistent String->byte[]->String character conversion during
  the process of receiving of a message.
  
  The calculation of the JMSTimestamp property has also been
  updated such that it now functions correctly for non-ASCII
  compliant JVM file.endcoding values.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v8.0       8.0.0.6
  v9.0 CD    9.0.2
  v9.0 LTS   9.0.0.1
  
  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 BASE MULTIP

• Fixed component ID

  5724H7251

Applicable component levels

• R800 PSY

     UP