APAR status
Closed as program error.
Error description
A JMS application connected to an EBCDIC character set encoded Queue-Manager (eg. a z/OS queue manager configured with CCSID 500) fails to open the backout queue (BOQ), or the dead-letter-queue (DLQ), when an attempt was made to consume a message where the backout count of the message was equal to or exceeded the backout threshold (BOTHRESH) of the queue the message was being consumed from. The application is connecting to the queue manager over a channel which has the following attribute value defined: SHARECNV(0) When this problem is encountered, the messages are not moved to the dead-letter queue either, with the application which attempted to consume the message receiving an exception of the form: javax.jms.JMSException: MQJMS1075: Error writing dead letter header. at com.ibm.msg.client.wmq.compat.jms.internal.ConfigEnvironment.new Exception at com.ibm.msg.client.wmq.compat.jms.internal.DLH.write at com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.dea dLetter at com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rem oveBadMessage 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.receiveNo Wait at com.ibm.mq.jms.MQMessageConsumer.receiveNoWait at myApplication.myMethod Caused by: java.nio.charset.UnmappableCharacterException: Input length = 1 at java.nio.charset.CoderResult.throwException at sun.nio.cs.StreamEncoder.implWrite at sun.nio.cs.StreamEncoder.write at java.io.OutputStreamWriter.emptyBuffer at java.io.OutputStreamWriter.flush at com.ibm.msg.client.wmq.compat.base.internal.MQMessage.writeStrin g at com.ibm.msg.client.wmq.compat.jms.internal.DLH.writeDLHFields at com.ibm.msg.client.wmq.compat.jms.internal.DLH.write ... 10 more Instead the message is left on the queue which the application was consuming the message from, with an incremented backout count.
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: This problem ONLY affects applications using the IBM MQ classes for JMS when they are running in MQ messaging provider migration mode. This mode is a IBM MQ V6 compatibility mode, which does not offer any of the enhanced function which was provided by IBM MQ V7.0 and beyond product. Migration mode is enabled on one of two ways: (a) If the channel attribute 'SHARECNV' is configured with the value '0', the IBM MQ classes for JMS application will run in migration mode when connecting to this channel. (b) If the ConnectionFactory property: PROVIDERVERSION has been configured with the value "6". This includes setting the property via the MQConnectionFactory method: com.ibm.mq.jms.MQConnectionFactory.setProviderVersion(java.lang. String version) Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: When the IBM MQ classes for JMS consume a message from a queue where the message's backout count is greater than 0, its backout count is compared against the queue attribute: BOTHRESH If the backout count equals or exceeds the backout threshold (BOTHRESH) value, then an attempt is made to move the message to the backout queue (BOQNAME). When operating in migration mode, the backout queue name is read when the MessageConsumer object is created. If the queue manager the application was connected to was running in an EBCDIC character encoding, such as CCSID 500 on a z/OS queue manager host system, and the IBM MQ classes for JMS was not running on a JVM with a compatible default character set, then the value for the backout queue was not correctly interpreted. The result of this was that when the IBM MQ classes for JMS attempted to open the backout queue to move the message to it, the open operation would fail, which would lead to the IBM MQ classes for JMS attempting to move the message to the dead letter queue instead. This is a similar issue to that reported under APAR IV75442, which fixed the issue for IBM MQ classes for JMS versions: 7.1 7.5 8.0 However the problem was not fixed for the IBM MQ versions 9.0 and beyond. This initial problem was not reported directly back to the application. If the IBM MQ classes for JMS trace was enabled, then an exception of the following form would be seen in trace: c.i.m.j.remote.api.RemoteFAP ----+----+--- X MQOPEN(Hconn,MQOD,int,Phobj,Pint,Pint,RemoteHobj)<catchIndex 4> CC=2;RC=2330;AMQ6047: Conversion not supported. [1=java.lang.String,2=500(IBM500) Unmappable Action: REPORT, Unmappable Replacement: 63, spaceByte: 64] [com.ibm.mq.jmqi.JmqiException] at: com.ibm.mq.jmqi.internal.JmqiDC.writeFieldDC com.ibm.mq.jmqi.internal.JmqiDC.writeMQField com.ibm.mq.jmqi.internal.JmqiDC.writeMQField com.ibm.mq.jmqi.MQOD.writeToBuffer com.ibm.mq.jmqi.remote.api.RemoteFAP.MQOPEN com.ibm.mq.jmqi.remote.api.RemoteFAP.MQOPEN com.ibm.mq.ese.jmqi.InterceptedJmqiImpl.MQOPEN com.ibm.mq.ese.jmqi.ESEJMQI.MQOPEN com.ibm.msg.client.wmq.compat.base.internal.MQSESSION.MQOPEN com.ibm.msg.client.wmq.compat.base.internal.MQQueueManager.acces sQueue com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.bac koutRequeue com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.get Message com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rec eiveInternal com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rec eive com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receiveIn boundMessage com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl.receive com.ibm.mq.jms.MQMessageConsumer.receive myApplication.myMethod The exception reported back to the application concerned a second problem which occurred when the IBM MQ classes for JMS was attempting to write the dead-letter-header, to send the message to the dead letter queue as a result of the failure to open the backout queue. This would be an exception of the form: javax.jms.JMSException: MQJMS1075: Error writing dead letter header. at com.ibm.msg.client.wmq.compat.jms.internal.ConfigEnvironment.new Exception at com.ibm.msg.client.wmq.compat.jms.internal.DLH.write at com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.dea dLetter at com.ibm.msg.client.wmq.compat.jms.internal.MQMessageConsumer.rem oveBadMessage 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.receiveNo Wait at com.ibm.mq.jms.MQMessageConsumer.receiveNoWait at myApplication.myMethod Caused by: java.nio.charset.UnmappableCharacterException: Input length = 1 at java.nio.charset.CoderResult.throwException at sun.nio.cs.StreamEncoder.implWrite at sun.nio.cs.StreamEncoder.write at java.io.OutputStreamWriter.emptyBuffer at java.io.OutputStreamWriter.flush at com.ibm.msg.client.wmq.compat.base.internal.MQMessage.writeStrin g at com.ibm.msg.client.wmq.compat.jms.internal.DLH.writeDLHFields at com.ibm.msg.client.wmq.compat.jms.internal.DLH.write ... 10 more
Problem conclusion
The IBM MQ classes for JMS have been updated such that when running in MQ messaging provider migration mode (compatibility mode), they now take the CCSID of the queue manager into account when inquiring the backout queue name of the queue which the application is consuming messages from. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v9.0 LTS 9.0.0.12 v9.1 LTS 9.1.0.9 v9.2 LTS 9.2.0.4 v9.x CD 9.2.4 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
IT36701
Reported component name
IBM MQ BASE M/P
Reported component ID
5724H7261
Reported release
900
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2021-05-11
Closed date
2021-06-30
Last modified date
2021-06-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
IBM MQ BASE M/P
Fixed component ID
5724H7261
Applicable component levels
[{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Version":"All Versions"}]
Document Information
Modified date:
01 July 2021