IBM Support

MQ 7.x, 8.0, 9.0, 9.1 and 9.2 compatibility with previous versions - including usage of CCDT files, JMS .bindings, SSL/TLS

Question & Answer


Question

Are MQ 7.0, 7.1, 7.5, 8.0, 9.0, 9.1 and V9.2 compatible with previous versions?
Can a recent MQ 9.2 client (for example) use a CCDT created with a previous version?
Can an older MQ 7.0 (for example) client use a CCDT created with a newer version?
Can a JMS .bindings file created in 7.1 be used with 9.2 (for example)?
Can a JMS .bindings file created in 9.2 be using with 7.1 (for example)?
Can an older MQ client using an old SSL protocol still work with MQ 9.x?

Answer


Compatibility statement:

MQ 7.x, 8.0, 9.0, 9.1 and 9.2 queue managers and clients inter operate with queue managers and clients from any previous level of the WebSphere MQ or IBM MQ products.

This means that ...

- An MQ client at 7.0, 7.1, 7.5, 8.0, 9.0, 9.1 and 9.2 can connect to all queue managers, non-version 7, as well as version 7.0, 7.1, 7.5, 8.0, 9.0, 9.1 and 9.2.

- An MQ queue manager at 7.0, 7.1, 7.5, 8.0, 9.0, 9.1 and 9.2 can interact with all clients, non-version 7, as well as version 7.0, 7.1, 7.5, 8.0, 9.0, 9.1 and 9.2.
CAVEAT: Keep in mind that the older clients CANNOT exploit new features offered in newer MQ versions when dealing with a queue manager at a newer version.

- The newer version of the code (queue manager / client) knows how to interact with previous versions and it will pretend to be at the same version of the other party. While the older party thinks that it is interacting with a component at the same version.

- If your 7.x, 8.0, 9.0, 9.1 or 9.2 client connects to an MQ 6.0 or earlier queue manager, or use a server-connection channel with the attribute SHARECNV = 0 (which treats the connection as being MQ 6.0), then you cannot use V7 features, and structures in your client application.

- Keep in mind that it is a best practice to use the latest fix pack for each of the versions that you are using.
Why? The latest fix packs could have fixed defects directly or indirectly related to compatibility.



MQ Client 6 and 7.x/8/9.0/9.1/9.2 compatibility

The new features which are available for a version 7.x, 8.0, 9.0, 9.1 or 9.2 client connected to a version 6.0 queue manager are:
- Weighted selection on CLNTCONN channels.
- Reconnecting via a previously used channel.
- Maximum message length increased on MQSERVER environment variable.

The new feature which is available for a version 6.0 client connected to a version 7.x, 8.0, 9.0, 9.1 or 9.2 queue manager is:
- Instance limits on SVRCONN channels.


Caveat

The compatibility statement refers to:
Version.Release

... such as:
An MQ 8.0 client is compatible with an MQ 9.1 queue manager.

This statement does not extend to a more granular specification:
Version.Release.Maintenance.FixPack (V.R.M.F)

If there are known problems at a given V.R.M.F (such as 8.0.0.0), then an upgrade to a more recent fix pack for the same Version.Release will be necessary (such as 8.0.0.10). Notice that the upgrade is within the same Version.Release (8.0) and a migration to a newer Version.Release is not forced.


+ Compatibility of MQ clients and CCDT files

Newer versions of the MQ clients (such as 9.1) know how to handle CCDT files that were created/edited by older queue managers (such as 6.0)

Older MQ clients (such as 6.0) do NOT know how to handle CCDT files that were created/edited by newer queue managers (such as 9.2). That is, older clients do not know what are the new attributes (if any) introduced in newer MQ versions.

Based on the above, if you have a mix of versions of MQ clients that use a common CCDT file, then this CCDT file should be edited from a queue manager at the LOWEST (OLDEST) version. For example, if you are using MQ 6.0, 7.0, 7.1, 7.5, 8.0, 9.0,9.1 and 9.2 clients that use a CCDT file, then the CCDT file must be maintained by the MQ queue manager at version 6.0.
- However, the newer MQ clients (9.2) when using the CCDT created with MQ 6.0 will NOT be able to fully exploit newer features, even when connecting to an 9.2 queue manager because the CCDT will not show the new attributes for those new features.

The following table takes into account the capability added in APARs IT10863 and IT11547 which are discussed later in this article.
MQ CCDT created version     Compatible MQ client versions 
                            (stated version is minimum level, includes later fix packs)
6.0                         6.0   7.0   7.1      7.5      8.0       9.0   9.1  9.2
7.0                               7.0   7.1      7.5      8.0       9.0   9.1  9.2
7.1                                     7.1      7.5      8.0       9.0   9.1  9.2
7.5                                     7.1      7.5      8.0       9.0   9.1  9.2
8.0                                     7.1.0.8  7.5.0.7  8.0       9.0   9.1  9.2
9.0                                     7.1.0.8  7.5.0.7  8.0.0.3   9.0   9.1  9.2
9.1                                     7.1.0.8  7.5.0.7  8.0.0.3   9.0   9.1  9.2
9.2                                     7.1.0.8  7.5.0.7  8.0.0.3   9.0   9.1  9.2

 

Notes:
- There was no change in the MQCD length between 7.1 and 7.5. Therefore the CCDT created on 7.5 can be used on 7.1.
- Unless documented otherwise, CCDTs created on higher level maintenance releases (for example 9.2.0.1) are compatible with lower level (for this example: 9.2.0.0) MQ clients running the same MQ version and release.

Update on July 2016:
There are 2 APARs that allow OLDER MQ clients to use NEWER CCDT files!
These APARs relax the restriction by allowing newer CCDTs to be used on older clients but with the caveat that the older client cannot make use of any of the newer channel attributes. These attributes will assume their default values when the CCDT is negotiated with the queue manager.
.
For Java/JMS client applications:

http://www.ibm.com/support/docview.wss?uid=swg1IT10863
IT10863: WEBSPHERE MQ CLASSES FOR JAVA/JMS APPLICATIONS CAN NOT USE CCDT FILES GENERATED ON A NEWER LEVEL QUEUE MANAGER

Version Maintenance Level
v7.0 7.0.1.14
v7.1 7.1.0.8
v7.5 7.5.0.6
v8.0 8.0.0.3

For C based (and non-Java/JMS) client applications:

http://www.ibm.com/support/docview.wss?uid=swg1IT11547
IT11547: WEBSPHERE MQ CLIENT APPLICATIONS CANNOT USE CCDT FILES GENERATED ON A NEWER LEVEL QUEUE MANAGER.
This applies to C based and non-Java/JMS applications.
Version Maintenance Level
v7.1 7.1.0.8
v7.5 7.5.0.7
v8.0 8.0.0.3


+ Compatibility of MQ clients and JMS .bindings files

- A JMS .bindings file that was created at an older version (such as 7.1) than the MQ JMS client (such as 8.0) will be used without version related errors by the client.

- A JMS .bindings file that was created at a newer version (such as 8.0) than the MQ JMS client (such as 7.1), will be used without version related errors by the client. If there are any new attributes in the JMS administered objects that the older client cannot read, they are ignored.


+ Compatibility of SSL/TLS cipher specifications

There have been changes in recent fix packs related to the compatibility of SSL/TLS cipher specifications. For example, if you have a MQ Client at 7.1.0.1 connecting to a MQ 8.0.0.1 queue manager using an older SSL cipher specification, after applying Fix Pack MQ 8.0.0.2 to the queue manager, the connectivity may be broken because the queue manager indicates that the older SSL cipher spec is now deprecated.

For more details on the compatibility of SSL/TLS cipher specifications, see the following blog entry:

https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/ssl_and_tls_cipher_specification_deprecations_for_the_mq_product?lang=en
SSL and TLS Cipher Specification Deprecations for the MQ Product
Miguel A. Rodriguez
May 2016
Due to the recent security vulnerabilities (for example, POODLE Attack), the latest MQ product Fix Packs come with stricter, default security requirements that affect the use of the compromised Secure Socket Layer (SSL) and Weak Transport Level Security (TLS) Cipher Specifications. Since these Cipher Specification deprecations are disabled in MQ Fix Packs by default, review the article for the changes separated by MQ versions and Fix Pack levels.
.

+ Article in the Knowledge Center:

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.1.0/com.ibm.mq.mig.doc/q006350_.htm
IBM MQ 9.1.x / IBM MQ / Maintaining and migrating / Migrating IBM MQ / Coexistence, compatibility, and interoperability /
Application compatibility and interoperability with earlier versions of IBM MQ
.
+ begin excerpt
.
Connecting an application that is built against libraries shipped with a later version of IBM® MQ to an earlier version IBM MQ is not supported. Avoid building applications against a later version, and redeploying them to a queue manager running at an earlier version, although some applications do work in practice.

IBM MQ applications do interoperate with applications running on earlier versions of IBM MQ, as long as they use no new function. IBM MQ clients can connect to queue managers running at an earlier version than the client, as long as the client uses no new functions.

An IBM MQ application that uses only functions provided by an earlier version of a queue manager can continue to send messages to the earlier version. It does not matter what version of IBM MQ an application is built on and connected to. It can exchange messages with an application connected to an earlier version of IBM MQ, as long as it does not use new function.

Consider these four cases; the first two cases are not supported though they might work in practice, the last two cases are supported. The first two cases require compatibility with an earlier version of IBM MQ. The last two cases rely on the interoperability between all versions of IBM MQ
.
...
.
+ end excerpt

+++ end +++

[{"Line of Business":{"code":"LOB15","label":"Integration"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"ARM Category":[{"code":"","label":""}],"Platform":[{"code":"","label":"Platform Independent"}],"Version":"All Version(s)"}]

Product Synonym

WMQ MQ

Document Information

Modified date:
30 October 2020

UID

swg21312967