APAR status
Closed as program error.
Error description
An MQ classes for JMS application configures a JMS Connection Factory with the property: JmsConstants.USER_AUTHENTICATION_MQCSP set to the boolean value: true to enable MQCSP authentication mode, as described in the following page of the IBM Knowledge Center: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm .mq.sec.doc/q118680_.htm The application also uses a Client Channel Definition Table (CCDT) to connect to an MQ V8 queue manager. The JMS API calls to create a JMS Connection or JMS Context object fail with the exception: Exception in thread "main" com.ibm.msg.client.jms.DetailedJMSRuntimeException: JMSWMQ2020: Failed to connect to queue manager '<queue_manager_name>' with connection mode 'Client' and supplied CCDT URL 'file:/<path_to_AMQCLCHL.TAB>', see linked exception for more information. Check the queue manager is started and if running in client mode, check there is a listener running. Please see the linked exception for more information. at com.ibm.msg.client.jms.DetailedJMSException.getUnchecked(Detaile dJMSException.java:267) at com.ibm.msg.client.jms.internal.JmsErrorUtils.convertJMSExceptio n(JmsErrorUtils.java:173) at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl.createCont ext(JmsConnectionFactoryImpl.java:584) Caused by: com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2539' ('MQRC_CHANNEL_CONFIG_ERROR'). at com.ibm.msg.client.wmq.common.internal.Reason.createException(Re ason.java:203) at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnecti on.java:422) at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createV7Pr oviderConnection(WMQConnectionFactory.java:8475) at com.ibm.msg.client.wmq.factories.WMQConnectionFactory.createProv iderConnection(WMQConnectionFactory.java:7814) at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl._createCon nection(JmsConnectionFactoryImpl.java:299) at com.ibm.msg.client.jms.admin.JmsConnectionFactoryImpl.createCont ext(JmsConnectionFactoryImpl.java:562) ... 1 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2539;AMQ9204: Connection to host '<host>(<port>)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2539;AMQ9523: Remote host detected a protocol error. [3=<channel_name> ]],3=<host>(<port>),5=RemoteConnection.analyseErrorSegment] at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java: 2273) at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java: 1285) at com.ibm.mq.ese.jmqi.InterceptedJmqiImpl.jmqiConnect(InterceptedJ mqiImpl.java:376) at com.ibm.mq.ese.jmqi.ESEJMQI.jmqiConnect(ESEJMQI.java:560) at com.ibm.msg.client.wmq.internal.WMQConnection.<init>(WMQConnecti on.java:355) ... 5 more Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2539;AMQ9523: Remote host detected a protocol error. [3=<channel_name>] at com.ibm.mq.jmqi.remote.impl.RemoteConnection.analyseErrorSegment (RemoteConnection.java:4378) at com.ibm.mq.jmqi.remote.impl.RemoteConnection.initOAMUserAuth(Rem oteConnection.java:2224) at com.ibm.mq.jmqi.remote.impl.RemoteConnectionSpecification.getSes sion(RemoteConnectionSpecification.java:310) at com.ibm.mq.jmqi.remote.impl.RemoteConnectionPool.getSession(Remo teConnectionPool.java:146) at com.ibm.mq.jmqi.remote.api.RemoteFAP.jmqiConnect(RemoteFAP.java: 1721) ... 9 more The queue manager to which the application attempt to connect reports the following in its error log file: AMQ9504: A protocol error was detected for channel '<channel_name>'. and generates an FFDC similar to the below: | WebSphere MQ First Failure Symptom Report | ========================================= | | Date/Time :- Tue April 11 2017 15:13:31 GMT Daylight Time | UTC Time :- 1491920011.255000 | UTC Time Offset :- 60 (GMT Daylight Time) | PIDS :- 5724H7251 | LVLS :- 8.0.0.6 | Product Long Name :- WebSphere MQ for Windows (x64 platform) | Vendor :- IBM | O/S Registered :- 1 | License Type :- Production | Probe Id :- RM680047 | Application Name :- MQM | Component :- rriBadDataReceived | SCCS Info :- | ...ot1\p800_P\src\com.ibm.mq.common\base\src\cmqxrfpt.c, | Line Number :- 2380 | Build Date :- Jan 17 2017 | Build Level :- p800-006-170117 | Build Type :- IKAP - (Production) | UserID :- MUSR_MQADMIN1 | Process Name :- C:\Program Files\IBM\MQ\bin64\amqrmppa.exe | Arguments :- -m QM1 | Addressing mode :- 64-bit | Process :- 00022020 | Thread :- 00000014 RemoteResponder | Session :- 00000000 | QueueManager :- QM1 | UserApp :- FALSE | ConnId(1) IPCC :- 102 | ConnId(3) QM-P :- 24 | Last HQC :- 1.6.6-119872 | Last HSHMEMB :- 0.0.0-0 | Last ObjectName :- | Major Errorcode :- rrcE_PROTOCOL_ERROR | Minor Errorcode :- OK | Probe Type :- MSGAMQ9504 | Probe Severity :- 2 | Probe Description :- AMQ9504: A protocol error was detected for channel | '<channel_name>'. | FDCSequenceNumber :- 0 MQM Function Stack ccxResponder rrxResponder ccxReceiveThreadFn cciProcessOne cciProcessUserData cciProcessAsyncRcv rriServerAsyncRcv rriMQIServerReceive rriConvertValidate rriBadDataReceived xcsFFST This issue also affects MQ classes for Java applications that enable MQCSP authentication and use CCDTs to obtain the client connection information.
Local fix
Workarounds can include: - Set the heartbeat interval (HBINT) value on the client connection channels used by the application to the value 1 to ensure it is re-negotiated with the queue manager during the initial flows when establishing a connection. - Set the maximum message size on the client connection channels used by the application such that the value is higher than on the partner server-connection channels to ensure it is re-negotiated. - Configure the sharing conversations value (SHARECNV) on the client-connection and server-connection channels to be greater than 1. Note that 10 is the default value. - Use a BINDINGS transport mode connection is the application and queue manager are located on the same server. - Do not use a client channel definition table Client Channel Definition Table (CCDT) and instead specify the individual connection details (hostname, port, channel etc).
Problem summary
**************************************************************** USERS AFFECTED: This issue affects users of: - IBM MQ V8 classes for JMS - IBM MQ V8 classes for Java - IBM MQ V8 JCA Resource Adapter - IBM MQ V9 classes for JMS - IBM MQ V9 classes for Java - IBM MQ V9 JCA Resource Adapter - WebSphere Application Server V9 MQ messaging provider who have enabled MQCSP authentication and use a Client Channel Definition Table (CCDT) within their application to provide the CLIENT transport mode connection information. The client-connection and server-connection channels have been configured with the value 1 for the sharing conversations (SHARECNV) attribute. Platforms affected: MultiPlatform **************************************************************** PROBLEM DESCRIPTION: After a TCP/IP socket is created from the MQ classes for JMS or MQ classes for Java client application to a queue manager, a set of "initial data flows" are exchanged starting with a flow from the client to the server. These flows between the client and server are used to negotiate commonly supported connection parameters. The value for the channel property heartbeat interval (HBINT) is one such example of a negotiated connection parameter. If the first initial data flow from the MQ classes for JMS or MQ classes for Java clients to the queue manager was accepted, because all of connection parameter values are supported by the queue manager (this can occur when using a Client Channel Definition Table to provide the connection information), then the password protection algorithms used for the MQCSP structure, as described in the IBM Knowledge Center: https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm .mq.sec.doc/q118710_.htm were not initialised correctly. The result of this was that the MQCSP passed to the queue manager while establishing the connection was corrupted, resulting in the queue manager reporting a rrcE_PROTOCOL_ERROR.
Problem conclusion
The MQ classes for JMS and MQ classes for Java have been updated to ensure that password protection algorithms used for the MQCSP structure are initialised when the connection parameter values specified in the first initial data flow from the client are accepted by the queue manager. --------------------------------------------------------------- The fix is targeted for delivery in the following PTFs: Version Maintenance Level v8.0 8.0.0.8 v9.0 CD 9.0.4 v9.0 LTS 9.0.0.2 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
IT20122
Reported component name
WMQ BASE MULTIP
Reported component ID
5724H7251
Reported release
800
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt / Xsystem
Submitted date
2017-04-07
Closed date
2017-08-08
Last modified date
2017-08-14
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
5724H7251
Applicable component levels
R800 PSY
UP
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0.0.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
14 August 2017