MQ Application Compatibility Across A Quarter Century
Mark Taylor has published an excellent new blog post in which he takes unboxing to extremes, opening a copy of MQ for AIX from 28 years ago and testing compatibility with the modern world. It was lovely to reminisce and have validation that the design strategies from all those years ago succeeded. But most importantly it was wonderful to see the dancers logo again which had disappeared from the internet until now. Here’s the intro to Mark’s post and a link to the full article:
I was working on something recently where I had to upgrade various components in the tooling. And I was getting more and more annoyed that the upgrades broke my existing programs and scripts. None of that was MQ’s fault and I’ll write more about the project once it’s available alongside the newly-announced MQ 9.3. But it got me thinking about the efforts we’ve made to keep MQ application compatibility across its lifetime. I wanted to show how we’ve achieved that across a quarter century (and more). And how that has preserved the work that developers have put into their MQ programs. In particular, I want to see if old compiled programs can still work with a current queue manager.
Most people probably understand how the MQ API makes it possible to add new function without fundamentally changing the interface. Using versioned structures means that new fields get added to a structure, and the queue manager code can use the version to decide whether or not to look at or fill in those fields. There are some aspects of the original API design which are hard or near-impossible to extend, and which I wish had been done differently. But the basic idea has held up very well.
It means that you can take application source code written many years ago, and recompile it on a new system, knowing it still builds. Not bumping the “default” version for a structure means that you get the same behaviour as before – you only have to move to an MQCNOv6 if you want to use the CcdtUrl attribute. And that requires that you use a particular version of MQ to recognise it. If you use an MQCNOv6 against an old queue manager, the application will fail. So you can continue to use an older structure version without changing the code as the defaults have not changed.
Application problems on migrating to new versions have typically happened when the app has not been written to expect new message formats or receiving newer error codes, or when MQ has tightened up its validation to catch applications that have not completely followed rules.
Nastel Technologies is the global leader in Integration Infrastructure Management (i2M). It helps companies achieve flawless delivery of digital services powered by integration infrastructure by delivering tools for Middleware Management, Monitoring, Tracking, and Analytics to detect anomalies, accelerate decisions, and enable customers to constantly innovate, to answer business-centric questions, and provide actionable guidance for decision-makers. It is particularly focused on IBM MQ, Apache Kafka, Solace, TIBCO EMS, ACE/IIB and also supports RabbitMQ, ActiveMQ, Blockchain, IOT, DataPower, MFT, IBM Cloud Pak for Integration and many more.
The Nastel i2M Platform provides:
- Secure self-service configuration management with auditing for governance & compliance
- Message management for Application Development, Test, & Support
- Real-time performance monitoring, alerting, and remediation
- Business transaction tracking and IT message tracing
- AIOps and APM
- Automation for CI/CD DevOps
- Analytics for root cause analysis & Management Information (MI)
- Integration with ITSM/SIEM solutions including ServiceNow, Splunk, & AppDynamics