IBM Support

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

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

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 number

    IT17427

  • Reported component name

    WMQ BASE MULTIP

  • Reported component ID

    5724H7251

  • Reported release

    800

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2016-10-10

  • Closed date

    2016-10-28

  • Last modified date

    2017-06-01

  • 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

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0.0.0","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
01 June 2017