MQ 10 is now generally available. I thought it might be useful to give an update on some of the various application interfaces that many developers use for their programs.
While there are many new features in MQ 10 (and more posts will be following on that site), there’s surprisingly few changes to the MQI. The only new options for application developers are around the quantum-safe cryptographic policies for TLS connections made to the queue manager.
Those options are in the MQCD structure and its analogues in the Go, Python and Node.js bindings for MQ. They are not yet available in Java, and hence not exposed via Spring Boot configuration.
But there are some other aspects to the developments of these interfaces that may be interesting (or just something for you to read about and forget).
Go (v5.7.2)
This was the smallest update of all, just requiring the new MQCD channel fields to be mapped. Provided you have installed the MQ 10 client, you can now do
mqcd.QuantumSafeAlgorithm = ibmmq.MQQS_MLKEM
mqcd.QuantumSafeRequired = ibmmq.MQQSR_REQUIRED
when programmatically creating a client channel. Of course, the equivalent qm.ini fields work too if you don’t want to change the application code.
There were a lot of other changes in the metrics package that is part of the repo, and then in the related mq-metrics-samples repo that makes use of it. But nothing that is directly relevant to regular application developers. Many changes involved deleting code rather than adding new function. You can see those described in the CHANGELOG file. As there are some breaking changes, I gave the metrics repo a new major number instead of keeping the same value as in the core Golang repo.
Node.js (v2.1.9)
Again, the only visible API change was to expose the quantum-safe options. Behind the scenes however, there were larger pieces of work needed to ensure the package could still be installed by npm with current versions of node.
You might have seen some recent news about changes to npm. It will soon be rejecting, by default, any package (like ibmmq) that uses custom installation scripts. It’s part of how people are trying to harden the Node.js ecosystem against malware. How this affects the MQ module is something I plan to investigate further and write about in a separate post later.
But for now, depending on which version of npm you have installed, you might see ignorable warnings about scripts executed by the the installation process. Until npm v12 is available, these are only warnings. After that point, you will have to make decisions on how to proceed.
Python (v2.1.0)
As the newest addition to the family of MQI language interfaces, there was a lot more going on in the Python release. Some of the changes were driven from the use of this library within the new MQ Agent tooling. These were either bug fixes or functional enhancements, primarily to do with PCF message processing. There were also some consistency updates, for example to ensure that testcases used the preferred form of spelling an operation. And I added classes and a sample program to show how you could write an MQ trigger monitor program in Python.
One thing I found when looking at some of the Agent team’s requests was how inefficient the MQGET processing could be. If your message was larger than 4K, an MQGET would do 2 malloc/free operations. And the next MQGET – even if the message was the same size – would repeat these malloc/free calls. Hopefully, the changes I’ve put inside the MQGET layers to cache buffers so they can be reused will prove beneficial. One PCF operation recently added to queue managers is the ability to return the contents of the error logs. As this is almost guaranteed to return significant amounts of data, it found several issues in how the Python layer processed large responses to administrative operations.
On the subject of PCF-style messages, I updated the hdr_browse sample to show how to handle MQ Event messages. It’s nothing like as comprehensive as the amqsevt sample program in the product, but does at least show the principles.
And on the subject of AI tooling, I used one of the LLMs (‘Bob’) in an experiment to add typing information to some of the Python functions that did not have any such description. It seemed to do a good job, correctly adding the annotations. And that in turn ought to help application developers when they validate their code. For example, via a linter that pays attention to data types. I will look at any missing public interfaces for a future release.
I also wanted to add prebuilt binary packages (“wheels”) for the most common application platforms in this release. So pip install ibmmq should not require a local compiler. Unfortunately, there were difficulties with creating a Linux wheel that I wasn’t able to overcome in time. At least the public repo now has all the pieces in the right shape to make further trials simple.
If your application is running on Windows or MacOS, installing the MQ Python library should not now require a compilation step. Though it still requires installation of the MQ client for runtime. I have an idea on how to overcome the Linux issues, and hopefully that can be done as part of the next update to the package.
Spring Boot (4.1.0)
I’ve written about the MQ 10 updates to the Spring Boot module in a separate post so I’m not going to repeat that here.
Summary
A new MQ LTS release gives an opportunity to look at all the components that application developers might use. For these public repositories, there have been several structural changes. Even though there’s only small MQI changes visible. The intention is to make sure we’ve got a suitable base for future updates.
You can of course comment here, or on any of the mentioned language interface repositories. I’d be very pleased to hear what people think.