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

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