IT14911: IBM MQ 8 CLIENT APPLICATION FAILS TO CONNECT TO WMQ 7.0.1 QUEUE MANAGER VIA MQ IPT WITH MQRC 2539 - MQRC_CHANNEL_CONFIG_ERROR

APAR status

• Closed as program error.

Error description

• An IBM MQ 8 client application fails to connect to a WebSphere
  MQ 7.0.1 queue manager via WebSphere MQ Internet Pass-Thru
  (MQIPT) reason code 2539 - MQRC_CHANNEL_CONFIG_ERROR.  This
  issue happens when SSL/TLS is enabled between the client and
  MQIPT but not enabled between MQIPT and the 7.0.1 queue manager.
  .
  The MQIPT route config shows:
    SSLCLIENT=TRUE
    SSLSERVER=FALSE
  
  An application log will show an exception similar to:
  
      MQXMSConsumer.Program.Main,[Message][InnerLevel]0,[Message]
      CWSMQ0006E: An exception was received during the call to the
      method ConnectionFactory.CreateConnection: CompCode: 2,
      Reason: 2539.
  
      During execution of the specified method an exception was
      thrown by another component.  See the linked exception for
      more information.,[StackTrace]
      at IBM.XMS.Client.WMQ.Factories.WmqConnectionFactory.
        CreateProviderConnection(XmsPropertyContext
        connectionProps)
      at IBM.XMS.Client.Impl.XmsConnectionFactoryImpl.
        CreateConnection(String userID, String password)
      at IBM.XMS.Client.Impl.XmsConnectionFactoryImpl.
        CreateConnection()
  
  The MQ error log will show the following error as well:
  
    1/1/2016 01:23:45 - Process(12345.1) User(test)
      Program(QXMSConsumer.exe) Host(ABCD(1414))
      Installation(Installation1) VRMF(8.0.0.1)
  
    AMQ9503:Channel negotiation failed.
    EXPLANATION: Channel 'TO.TESTQMGR' between this machine and
      the remote machine '1.2.3.4(5678)' could not be established
      due to a negotiation failure. In some cases the channel name
      can not be determined and so is shown as '????'.
  
      The last control data received was type 5 with associated
      error code -1.
  
    ACTION: Tell the systems administrator, who should attempt to
      identify the cause of the channel failure using problem
      determination techniques.  For example, look for FFST files,
      and examine the error logs on the local and remote systems
      where there may be messages explaining the cause of failure.
      More information may be obtained by repeating the operation
      with tracing enabled.
  
  
  When reviewing concurrent traces, the following errors were
  captured.  The MQ client trace shows:
  
    -----------}! cciTcpReceive (rc=rrcI_SSL_WOULD_BLOCK)
    ----------}!  cciTcpSslReadCallback (rc=Unknown(FFFFFFFF))
      RetCode = 20009503, rc1 = 5, rc2 = -1,
      Comment1 = 'TO.TESTQMGR', Comment2 ='1.2.3.4(5678)'.
  
  
  The queue manager trace shows:
  
      RetCode = 20009503, rc1 = 1, rc2 = -2,
      Comment1 = 'TO.TESTQMGR', Comment2 = '1.2.3.4',
    ----}! rrxError rc=rrcE_BIND_FAILED
  

Local fix

• Enable SSL/TLS between MQIPT and the MQ 7.0.1 queue manager:
  
      SSLCLIENT=TRUE
      SSLSERVER=TRUE
  

Problem summary

• ****************************************************************
  USERS AFFECTED:
  This issue affects users of IBM MQ Internet Passthru (MQ IPT),
  who are using an IPT route between a version 8 MQ client or
  queue manager and a version 7.1 (or earlier) client or queue
  manager, and have enabled the SSLCLIENT option for the route,
  but have not enabled the SSLSERVER option.
  
  
  Platforms affected:
  MultiPlatform
  
  ****************************************************************
  PROBLEM DESCRIPTION:
  When MQ IPT is configured to only use SSL/TLS on one half of the
  route, it must modify some internal MQ data flows before
  forwarding to ensure that the user information passed on the
  connection is in an appropriate format for the receiving
  endpoint.
  
  This takes place during the initial negotiation of the MQ
  connection call (MQCONN).
  
  A coding error meant that one such modification was made
  incorrectly to a data flow when negotiating a connection where
  one end of the connection was at the 7.1 level or earlier. This
  caused the connection to be negotiated with a protocol level
  which was not available when using MQ 7.1 or earlier. Because
  this protocol level was not suitable, this caused the
  negotiation process to fail, and the queue manager to terminate
  the connection.
  

Problem conclusion

• MQ IPT has been updated so that it will not attempt this
  modification to the negotiation when one end of the route is at
  MQ 7.1 or earlier.
  
  ---------------------------------------------------------------
  The fix is targeted for delivery in the following PTFs:
  
  Version    Maintenance Level
  v2.1       2.1.0.3
  
  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 BASE MULTIP

• Fixed component ID

  5724H7251

Applicable component levels

• R800 PSY

     UP