Recently, we have been creating and publishing a lot of material to help educate people about MQ. You can find that here.
But how might you have learned about MQ in its early days? While hunting through archives for something that I was, in the end, unable to find, I did come across one piece of education that was created over 20 years ago.
In 2016 I wrote about how MQ’s resource statistics can work with a number of time-series databases, including Prometheus. This permits monitoring using the same tools that many customers use for monitoring other products. It allows easy creation of dashboards using tools such as Grafana.
Since that original version, we’ve made a number of enhancements to the packages that underpin that monitoring capability. For example, more database options were added; a JSON formatter appeared. One notable change was when we split the monitoring agent programs into a separate GitHub repository, making it easier to work with just the pieces you needed.
And now, I’ve released some changes that allow Prometheus and generic JSON processors to see some key channel status information. In particular, a Grafana dashboard can easily highlight channels that are not running.
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.
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?
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.
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.
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
This post was last updated on November 24th, 2019 at 08:54 pm