IBM Support

IV75442: JMS CLIENT CONNECTED TO EBCDIC QUEUE-MANAGER FAILS TO OPEN THE BACKOUT QUEUE AND THE MESSAGE IS PUT TO THE DLQ

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • A JMS application connected to an EBCDIC Queue-Manager (eg. a
    z/OS queue manager) fails to open the backout queue, because its
    name is not interpreted correctly.
    
    Instead, the message is written to the dead-letter-queue (DLQ).
    
    MQJMS1081: Message requeue failed.
    
    It should be noted that this problem ONLY affects the WMQ-JMS
    classes when they are running in migration mode. Migration
    mode is a WMQ V6 compatibility mode, which does not offer any
    of the enhanced function which was provided by the WMQ V7
    product.
    
    If the channel attribute 'SHARECNV' is configured with the
    value '0', it's forcing the WMQ-JMS classes to run in migration
    mode.
    

Local fix

  • Disable migration mode, for example by setting the CHANNEL
    attribute:
    
        SHARECNV
    
    to any positive integer value other than 0.
    

Problem summary

  • ****************************************************************
    USERS AFFECTED:
    Users of the WebSphere MQ classes for JMS who meet the specific
    conditions shown below:a
    
    (1) WebSphere MQ classes for JMS application running in
    migration mode (either by communicating with a queue manager
    over a channel defined to have the SHARECNV attribute to have
    the value '0'), or by setting "PROVIDERVERSION"
    ConnectionFactory property to "6".
    
    (2) The application connects to a queue manager where the bytes
    representing characters being communicated between the queue
    manager and JMS application are not able to be interpreted using
    the JVM's default character encoding scheme.
    
    For example, the scenario where the queue manager is running on
    a z/OS system, running in CCSID 500, communicating with a JMS
    application running on a Linux (x86-64) system with a default
    JVM character encoding of "UTF-8" (CCSID 1208).
    
    (3) A message on the queue which is being consumed by the
    application, where the backout count of the message equals or
    exceeds the backout threshold (BOTHRESH) as defined on the
    queue.
    
    (4) A backout queue (BOQUEUE) defined on the queue.
    
    
    Platforms affected:
    MultiPlatform
    
    ****************************************************************
    PROBLEM DESCRIPTION:
    When the WebSphere MQ classes for JMS encounters a message on a
    queue which has a backout count which equals or exceeds the
    backout threshold for the queue, the WMQ-JMS classes will
    attempt to move the message from the queue to the backout queue,
    if it is defined.
    
    In order to do this, the WMQ-JMS classes make an MQINQ API call
    to inquire the name of the backout queue.  This queue name is
    transmitted to the WMQ-JMS classes as character data, but was
    being interpreted incorrectly by the WMQ-JMS classes, not taking
    into account the character encoding which the data has been
    encoded with.
    
    If the JVM's default character encoding was not compatible with
    the transmitted data, for example when using a JVM on Linux
    using the "UTF-8" default encoding scheme and communicating with
    a z/OS queue manager where the data was being encoded in an
    EBCDIC encoding such as CCSID 500, the character data
    representing the backout queue name was incorrectly interpreted.
    
    The consequence of this was that if the message needed to be
    backed out, the WMQ-JMS API would attempt to open the backout
    queue using this incorrectly interpreted data, which would not
    match a queue name on the queue manager and the MQOPEN would
    fail.  This exception would not necessarily be thrown back to
    the application, because the behaviour of the WMQ-JMS API after
    the MQOPEN had failed is to attempt to put the message to the
    dead letter queue under this circumstance.
    
    If the dead letter queue was not defined (it is not defined by
    default), then an exception of the following form would be
    passed back to the application:
    
    (stack from WMQ-JMS 7.1.0.7):
    
    Exception caught: javax.jms.JMSException: MQJMS1079: Unable to
    write message to dead letter queue.
    javax.jms.JMSException: MQJMS1079: Unable to write message to
    dead letter queue.
    at
    com.ibm.msg.client.wmq.v6.jms.internal.ConfigEnvironment.newExce
    ption(ConfigEnvironment.java:374)
    at
    com.ibm.msg.client.wmq.v6.jms.internal.MQMessageConsumer.deadLet
    ter(MQMessageConsumer.java:1691)
    at
    com.ibm.msg.client.wmq.v6.jms.internal.MQMessageConsumer.removeB
    adMessage(MQMessageConsumer.java:4627)
    at
    com.ibm.msg.client.wmq.v6.jms.internal.MQMessageConsumer.getMess
    age(MQMessageConsumer.java:2842)
    at
    com.ibm.msg.client.wmq.v6.jms.internal.MQMessageConsumer.receive
    Internal(MQMessageConsumer.java:4544)
    at
    com.ibm.msg.client.wmq.v6.jms.internal.MQMessageConsumer.receive
    (MQMessageConsumer.java:4032)
    at
    com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receiveIn
    boundMessage(JmsMessageConsumerImpl.java:817)
    at
    com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receive(J
    msMessageConsumerImpl.java:501)
    at
    com.ibm.mq.jms.MQMessageConsumer.receive(MQMessageConsumer.java:
    212)
    
    
    At this point, the message was left on the original queue, and
    the message receive operation had failed with the above
    exception - the result of which would likely be that the next
    message receive attempt attempted on this queue would fail in
    the same repeating way.
    

Problem conclusion

  • The WebSphere MQ classes for JMS have been updated such that
    when running in migration mode, the CCSID encoding of the
    backout queue name is taken into consideration, which permits
    the MQOPEN for the backout queue to be performed against the
    defined BOQUEUE.
    
    ---------------------------------------------------------------
    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

    IV75442

  • Reported component name

    WMQ AIX V7

  • Reported component ID

    5724H7221

  • Reported release

    710

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2015-07-27

  • Closed date

    2016-02-26

  • Last modified date

    2016-02-26

  • 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 AIX V7

  • Fixed component ID

    5724H7221

Applicable component levels

  • R710 PSY

       UP

[{"Line of Business":{"code":"LOB36","label":"IBM 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