This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.
I asked the team during the recent "IBM MQ: Ask Us Anything" event, what their favourite little feature of IBM MQ was. Amy McCormick's answer was about the MQ compatibility between different versions and different platforms. So let's learn a little about that little gem of a feature today.
Different Versions
IBM MQ channels were designed from day one, to have a negotiation phase at start up where the two ends determine what level of the FAP (the channel protocol) they can both understand. For the most part a user would never need to know what level of the FAP was in use, but if you are interested, you can discover the number through a channel exit using the MQCXP field called FAPLevel.
The FAP level determines which features of the channel can be used and which will not be understood by the lower level partner. The known FAP level of the partner ensures it isn't sent questions about features it doesn't understand.
For example, heartbeat interval is a negotiated feature of channels. To determine what value to use for heart beating, the negotiation compares what is defined at each end of the channel, and if the two ends are configured differently, they take the least frequent interval - which might be to turn off heart beating completely if one end is configured with zero.
Channel heartbeats were added in MQSeries for MVS/ESA V1.2 and MQSeries for Distributed Platforms V5.0 (a long time ago now), and they were part of FAP level 4. If a channel tried to connect to a partner who did not support FAP level 4, the question about what heart beating value should be used, would not even be asked as part of the negotiation. There have been quite a number more FAP levels since those versions of MQ.
Different Platforms
IBM MQ runs on many different platforms which have different code pages in use, e.g. some ASCII platforms and some EBCDIC platforms. They also have different encodings for numbers, e.g. some Big endian systems, such as z/OS and IBM i, and some Little Endian systems, such as x86. In order to make the first communication in the above negotiation phase be understood regardless of what is at the other end of the socket, the initial flow includes the endianness and the codepage of the data. This means that regardless of the two platforms trying to communicate, the negotiation flows will be understood.
The channel is able to talk to any other partner channel on any other platform because data conversion is available for the channel to convert the flow into its own code page to work with. Once the flow from the partner is converted, it can be understood, and replied to, and negotiation can begin. The caveat to this is the occasional combination of platforms where there is no conversion available between the two codepages in use. This is usually resolved by either changing the code page of one machine, or installing extra code page support.
Other considerations
Of course, compatibility between systems is not just about version and platform compatibility. There are a number of other factors too, and these are well covered in this IBM Support Doc.
To finish, let's listen to a snippet of the Ask Us Anything webinar, where Amy McCormick describes this feature in her own words.
You can watch the full replay of that webinar here.
#Little-Gem#IBMMQ#ChampionsCorner