A requirement I’ve seen a couple of times recently asked how to save an MQ queue manager’s configuration in a different format than MQSC. This short post shows one way to do that.Continue reading “Save MQ configuration as JSON”
A new option in MQ 9.2.1 on Unix/Linux platforms gives more flexibility in user management, with no need to make operating system definitions for application users. This post describes why you might want this, how you can use the option and gives a simple example to demonstrate it. Note that this does not apply to Windows or the MQ Appliance.Continue reading “More flexibility for user management in MQ”
One tool I created a few years ago deals with formatting SMF records from z/OS. I designed it to take MQ’s 115 and 116 records and generate output that users could import to spreadsheets and SQL databases. I made a video about the original version of the tool here, and I wrote about more enhancements to that tool in this post.
If you want to know more about how to use the data after formatting, then Lyn has a lot of posts at her blog site talking about analyses she has run and lessons she has learned.
Most recently I’ve added (with help) some formatting options to deal with a couple of additional record types. That work showed how non-standardised SMF records are, and how much manual work is needed to create formatters. This post will talk about how something that supposedly has a common format does not really.Continue reading “Formatting SMF records”
A few days ago, I had a really clever idea.
At least, it seemed like that at the time. In this post I’ll write about something that didn’t quite pan out as I’d hoped.Continue reading “Sometimes things don’t work out”
For a web conference session I was giving this afternoon, I’d written a script. Although I might not follow it exactly, it was meant to give a structure and ensure I didn’t forget points I wanted to make. But reading it while looking down at a printed page would make it difficult to look at the camera. And looking at the camera would make it difficult to read the words. Not to mention the problem of driving the slides through, by clicking on the presentation application in a browser. Putting things on the laptop’s 2nd monitor would mean frequent eye movement so I was not “looking at” the audience. Not very satisfactory.
With an hour to go, I had a brainwave – I could use my standby laptop propped up behind the main system and use that screen. And because of the need to both click on the presentation system AND to scroll through the script, while not looking down to move cursors or switch between applications, I’d be able to use another mouse. I grabbed an empty box to act as a stand, copied a PDF to the other machine, and tried it out. I had left-hand for the teleprompter scrolling mouse; right-hand for the presenting mouse.
And it all seemed to work pretty well from my perspective. Other than running short on time. But that was not the technology’s fault.
This week I’ve been preparing material for two virtual events that are happening at the same time: SHARE and IBM’s Integration Technical Conference. In normal times, I’d have had to make a choice as to which conference to attend, but both are now using remote presentations. So I can give talks (different ones) at both.
The TechCon event is using “live” presentations, streamed with the presenter talking from home. I’ve been doing a lot of presentations like that already over the last few months – I talked about that in another recent post. While the platform running the TechCon stream is different, and some details will change, it’s probably not really going to affect how I work with that material.
The SHARE event is a little more interesting technically as they want the sessions to be prerecorded, submitted as a video, and then having just a short live Q&A at the end. I guess that helps with risky situations like bandwidth restrictions or network failures at the presenter’s end. Running everything centrally makes it more controllable. But I found a couple of challenges doing the recordings.Continue reading “Presentations for virtual events”
The MQ metric exporters are a set of Go programs that deliver queue manager statistics and status to databases such as Prometheus and Influx. They have recently been updated, giving more consistent function and a much easier configuration. This post will explore and explain these changes.
For an introduction to these exporters, see some of my earlier posts in this blog.
The Go language and toolchain did not have a good version control system when created. Systems built on Go could not easily define the levels of the dependencies underpinning the system. Various tools were developed to help with that such as
glide. But more recently, the Go compiler environment has defined modules as the way forward. The MQ Go packages are now available in a format that works with modules, with a major number version update to match. This post describes what has been done in the core MQ packages.
In the past few months I seem to have been been sent a bunch of questions about MQ API Exits from a variety of developers. Some of the questions were repeated so I thought I’d try to collect them, tidy them up, and turn them into an FAQ article.
API Exits were originally made available for one platform in MQSeries V5.2 and then extended to the rest of the Distributed family in V5.3 so they have been around for a while.
Exits are an advanced topic and I’m not planning on going into much general information about these exits. I will assume that someone interested in this article already knows the basic principles and is comfortable working in this environment. For more information on the interfaces see the KnowledgeCentre and the sample amqsaxe0.c exit.