Messaging, Music and Moving Around
MQ Application Activity reports have a lot of detail. This post shows a simple way to extract key fields for simpler processing.
Application Activity Trace is a mechanism on the MQ Distributed platforms that give a report of all the MQI calls made by a program. Originally configured via a text file, MQ V9 enhanced them by allowing a monitoring application to subscribe to topics that describe the application or channel of interest.
See how to extract key fields from events
In November, I wrote about a new language binding to MQ, making it possible to use Javascript in a Node.JS environment to access the MQ API. I published the first release of that code only through GitHub which required that you clone it locally before you could use it. Once the initial public exposure proved some stability to the interface, I added the ibmmq package to the npm repository meaning that you could simply refer to it in the descriptors (package.json) for your programs and npm would automatically download and install it.
But there was still one drawback. The package builds on, and requires, the MQ C client runtime libraries. That needed a separate operation to complete the installation, as those libraries came from product installation media or required you to login to an authorised location before they could be accessed.
No longer though.
Recent updates to the MQ Redistributable Client package and then to the MQ Node.js component have made it much simpler to get an MQ application running, and to create standalone containers for those applications.
Continue reading “Easier use of the Node.js interface for MQ”
Turn MQ SMF data into JSON for simple consumption and analytics. Use a free open source tool for Windows and Linux to process your mainframe statistics.
On z/OS, MQ produces a lot of information about its usage through SMF records. One tool I published on GitHub a couple of years ago was designed to take collected SMF data and process it into a more consumable format. The goal was to create something that did nothing more than format the data, rather than try to analyse it in the manner of SupportPac MP1B. The analysis would be done using independent tools.
The comma-separated-value format is ideal for importing into spreadsheets and databases. Many of our z/OS customers have been helped by reports created from their data, and analysed through SQL queries.
While I didn’t write about it in a blog post then, I did publish a short video showing it in action. And since the original release, I’ve made regular updates to the code. Mostly these have been to simplify the SQL processing.
I’ve now updated the program to give a further output format option. It is intended to make it easy to feed SMF information to other analytics tools, many of which work with JSON structures. Other aspects of MQ administration can now be done with JSON-format data – the error logs on Distributed platforms, an event formatter (which is also available in MQ V9.0.5), the REST APIs for administration and messaging – and this is one further piece of a consistent story.
Application developers who are working in Java, using the JMS interface, often choose to work with the Spring Framework. Spring can simplify the coding of new applications by providing templates for common patterns, and has been successfully used for many
years with the MQ JMS classes. The JmsTemplate class in Spring is the key interface here, but it still relies on having dependencies and configurations defined or coded.
The Spring Framework includes several modules for different capabilities. One of these components is Spring Boot. Spring
Boot starters conveniently pull in all the dependencies and auto-configuration libraries required to use a particular technology. This makes it very easy to get going with a new application and technology, faster than working directly with classes like JmsTemplate. So how can we enable this easy access for MQ applications?
In this post I described how MQ’s Java classes are available for direct download from Maven Central Repository. And we have now exploited that to create a Spring Boot Starter for MQ. You can download full source code for the module from GitHub.
This post talks about a simpler way to develop Java applications for MQ, using a Maven repository to automatically install dependencies.
Application development for MQ requires access to the language-specific interfaces, libraries, headers, DLLs etc. You write an application and, depending on the language, the MQ-provided components are used within the IDE while you are writing code, checked during build processes, or referenced at runtime. If you want to make your application available to other people, then they will need access to at least the runtime MQ interfaces.
We made it much easier to distribute applications with the release of the MQ Redistributable Client packages.
And now we’ve also made it easier to write Java applications, so that you do not need to explicitly install anything before using MQ’s interfaces.
See more about setting up dependencies for your Java program
MQ has always supported a wide range of API styles, languages and environments to enable applications to be written in whichever way a developer feels at home. There is the full-function procedural API, often called from C or Cobol programs; object-oriented varieties of that interface such as for Java and C#; and there is the JMS model.
One of my previous projects involved creation of a Go binding for MQ. There are client APIs and protocols with simpler interfaces that can also connect to MQ, such as MQ Light and MQTT. And there are more than just these examples – the new REST messaging API is yet another. One environment where a lot of new applications are developed is Node.js, with JavaScript being the associated programming language.
And so, as part of making it easy for people to access MQ from Node, I’ve now published a JavaScript API implementation on github.
MQ V9 added resource monitoring statistics that you can subscribe to. In this post I’m going to show how you can generate similar statistics from your own applications using the same model. For example, you may want to track how many successful and how many failed messages are being processed.
IBM and Salesforce recently announced a partnership to deliver various solutions based around the different companies products.
As part of that initiative, MQ is now shipping a component that enables MQ applications to receive events caused by updates to Salesforce data, or driven by applications running in the Salesforce environment.
This new bridge, an optionally installable element of MQ V9.0.2 on the x64 Linux product, listens for these events and republishes them to MQ topics. Any MQ application using the normal publish/subscribe programming interfaces can get these messages, and then take action based on the contents. One of those MQ applications could be IIB, which has a node for Salesforce integration, allowing further work with that Salesforce data to be triggered through a message flow.
Along with this re-publication, the bridge program also contributes monitoring data to show how much traffic is being processed. The MQ Console can show this in its graph widgets:
There is an accompanying demo video to go with this post that shows the whole thing working
In something a bit different, I’ve decided to look back in time. That’s because, while digging through some old files recently, I realised that IBM MQ on Linux is
SupportPac MA57, as far as I can find, made MQ the first IBM product to have any kind of public support for Linux and was released on 1 Feb 1996. There might have been some research projects or tools before then, and there were certainly other products considering options, (my email archives suggest that several corporate lawyers rapidly got involved, as IBM got to grips with GPL and other open source licenses) but I don’t remember anything else officially released at the time.
Read about SupportPac MA57
IBM MQ has always been able to generate event messages when something “interesting” has occurred in the queue manager. These events could be showing that a queue is full, or that there has been an authorisation failure; someone needing an audit trail might want to capture the command and configuration events. These events are written as MQ messages to well-known queues, using PCF structures which can be decoded to give the full description of the event.
See how these events can now be fed to JSON-aware processors
