IBM Support

IT00642: JMS APPLICATION RECEIVES JMSCMQ1006: VALUE FOR JMS_IBM_CHARACTER_SET X-IBM964 IS NOT VALID

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • When an attempt is made to send a message to a WMQ queue,
    the WebSphere MQ classes for JMS attempt to look up a
    CharacterSet name "x-IBM964" which results in the following
    found in the WebSphere Application Server SystemOut.log:
    
      JmqiCodepage.getJmqiCodepage(x-IBM964): NOT FOUND
      .
      [:] Caught exception: java.lang.NumberFormatException:
          For input string: "x-IBM964" in class:
      .
      java.lang.NumberFormatException: For input string:
      "x-IBM964"
      .
      com.ibm.msg.client.jms.DetailedJMSException
      JMSCMQ1006: 'JMS_IBM_Character_Set':'x-IBM964' ?????
    

Local fix

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    This problem can affect a number of different users depending on
    the use of the WebSphere MQ classes for JMS API usage. However
    the most common use case which is affected by the issue is that
    where an application consumes a message from a WebSphere MQ
    queue, and then send the same JMS Message object back to a
    WebSphere MQ queue.
    
    This processing pattern occurs when a 'poison message' is
    consumed from the queue - which is where the message's backout
    count is greater than the queue's backout threshold (BOTHRESH) -
    at which point the WebSphere MQ classes for JMS consumes the
    message from the queue and attempts to put it to the backout
    queue (BOQUEUE) - at which point the problem may be encountered
    depending upon which CCSID the message's character data was
    encoded in.
    
    This includes users of the WebSphere Application Server who are
    consuming messages from WebSphere MQ.
    
    
    Platforms affected:
    z/OS, MultiPlatform
    
    ****************************************************************
    PROBLEM SUMMARY:
    When a JMSTextMessage is sent to a queue manager using the JMS
    API, character data within the message body needs to be encoded
    according to predefined character encoding.
    
    For example, a WebSphere Application Server application may have
    configured the JMS Destination to have a CCSID 964 value, a
    Traditional-Chinese based character encoding, by setting the
    value '964' in the CCSID field in the Administration Console
    when administering the JNDI entry for the Destination object.
    
    In order for this encoding to take place, the JVM must be told
    which Java CharacterSet the message bytes should be encoded in.
    JVMs make use of a CharacterSet string to identify character
    encodings, where as WebSphere MQ makes use of CCSID integer
    values to define character encodings of MQ Messages.
    
    In order to encode the bytes within the JVM to the CCSID
    encoding scheme, the JVM must therefore be informed which
    CharacterSet name corresponds to the defined CCSID value. The
    WebSphere MQ classes for JMS provides this mapping between the
    character encoding format systems.
    
    This mapping is created in two stages, the first during the
    compilation of the WebSphere MQ classes for JMS, and secondly on
    the JVM where the application is running, to account for
    differences in CharaterSet names used by the runtime JVM (note
    that there may be numerous JVM CharacterSet names which are
    associated with a single CCSID integer value).
    
    Two maps are created:
    
      (a) One which maps CCSID numbers to CharacterSet names
      (b) One which maps CharacterSet names to CCSID numbers
    
    When a JMS message is sent to or received from the queue
    manager, the Java CharacterSet name is determined, and the value
    stored within the JMSTextMessage object under the property
    named:
    
        "JMS_IBM_Character_Set"
    
    For example, for the CCSID 964 character encoding, the WebSphere
    MQ classes for JMS creates the mapping:
    
      CCSID "964" maps to the Java CharacterSet name "IBM-964"
    
    which permits messages to be received or new messages to be sent
    to the queue manager, encoded in the CCSID 964.
    
    However, between different operating systems and different
    versions of the JVM, some CharacterSet names change for a
    specific CCSID integer value:
    
    At compilation time, the build system's Java 1.5 JDK may have
    mapped CCSID "964" to "IBM-964", which is the CharacterSet name
    used to decode a message received from a WebSphere MQ queue.
    
    But at runtime, a Java 1.6 JVM is interrogated and it is
    determined that the actual CharacterSet name for the "IBM-964"
    CharacterSet alias is "x-IBM964".
    
    
    The consequence of this is that when the WebSphere MQ classes
    for JMS sends a new JMSTextMessage or receives a message encoded
    in CCSID 946, the value of the JMS_IBM_Character_Set property is
    set to:
    
      x-IBM964
    
    while no map exists within the WebSphere MQ classes for JMS to
    translate between "x-IBM964" and the CCSID value 964.
    
    
    This allowed a new message to be sent, or a message to be
    received and correctly interpreted by the JVM, but if the JMS
    application then chose to send that same message object back to
    a queue manager, the WebSphere MQ classes for JMS would be asked
    to map the CharacterSet name "x-IBM964" to a CCSID value - for
    which no such mapping existed within its tables.
    
    This would be externally observed by the Java exception:
    
    ----------------------------------------------------------------
    --------
    com.ibm.msg.client.jms.DetailedJMSException: JMSCMQ1006: The
    value for
    'JMS_IBM_Character_Set':'x-IBM964' is not valid.
    The value 'x-IBM964' for property 'JMS_IBM_Character_Set' is not
    correct.
    Check the linked WebSphere MQ exception reason and completion
    code.
            at
    sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
    Method)
            at
    sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeCons
    tructorA
    ccessorImpl.java:85)
            at
    sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Delega
    tingCons
    tructorAccessorImpl.java:57)
            at
    java.lang.reflect.Constructor.newInstance(Constructor.java:541)
            at
    com.ibm.msg.client.commonservices.j2se.NLSServices.createExcepti
    on(NLSSe
    rvices.java:314)
            at
    com.ibm.msg.client.commonservices.nls.NLSServices.createExceptio
    n(NLSSer
    vices.java:228) Page 20 of 23
            at
    com.ibm.msg.client.wmq.common.internal.messages.WMQMarshalUtils.
    calculat
    eMessageBodyCcsid(WMQMarshalUtils.java:724)
            at
    com.ibm.msg.client.wmq.common.internal.messages.WMQSendMarshal.c
    onstruct
    MessageBuffers(WMQSendMarshal.java:134)
    ----------------------------------------------------------------
    --------
    
    and the message would not be sent to the queue manager.
    
    
    
    This problem would also be seen when performing poison message
    handling - that is when a JMS message's backout count has
    exceeded the queue's backout threshold, and the message
    character data was encoded in the CCSID value which was
    different to that determined during the complication of the
    WebSphere MQ classes for JMS.
    
    In this instance, the WebSphere MQ classes for JMS receives the
    messages, compares the backout count with the backout threshold
    and then attempts to send the message to the backout queue -
    which would fail with the above exception stack.
    

Problem conclusion

  • The WebSphere MQ classes for JMS have been updated such that the
    algorithm which created the map of CharacterSet names to CCSID
    values can no longer assigns a value to the
    JMS_IBM_Character_Set property of the JMS message which it is
    unable to map back to a CCSID value.
    
    Although the example used above was for the CCSID 964 value, it
    affects other values, including for example:
    
    CCSID 964 Traditional Chinese EUC
    CCSID 1141 Austrian/German ECECP
    CCSID 1148 International 1 ECECP
    
    ---------------------------------------------------------------
    The fix is targeted for delivery in the following PTFs:
    
    Version    Maintenance Level
    v7.1       7.1.0.5
    v7.5       7.5.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

    IT00642

  • Reported component name

    WMQ BASE MULTIP

  • Reported component ID

    5724H7241

  • Reported release

    750

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2014-03-27

  • Closed date

    2014-04-23

  • Last modified date

    2014-04-30

  • 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

    5724H7241

Applicable component levels

  • R750 PSY

       UP

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"Business Unit":{"code":"BU053","label":"Cloud \u0026 Data Platform"},"Product":{"code":"SSFKSJ","label":"WebSphere MQ"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"7.5"}]

Document Information

Modified date:
24 September 2021