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":"LOB45","label":"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