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.
We’ve recently made available a new repository at https://github.com/ibm-messaging/mq-exits that is intended to hold the source code for various MQ Exits of different kinds.
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.
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 post was last updated on August 7th, 2020 at 08:45 am
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.
Like many in recent months I’ve been doing a lot more communication using web conferencing solutions. All meetings are virtual, you can’t kick a person under the table to shut them up, you get very familiar with some nostrils from their camera angles, there are some who sound like they are talking through several layers of mud.
After the first few calls I had where there were comments about the drinks cabinet behind me (and at least one person proposing to measure the height of the fluid in each bottle to see how it changed by the next meeting) I decided to change the picture. And the audio. But not the bottles.
This post will talk about my setup and its use of a few technologies to make it all seem a bit more professional. I might not use all of this capability for internal discussions with one or two other people. But I think it helps particularly when doing presentations and education sessions to customers.
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 dep and 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.
A separate post talks about changes in the mq-metric-samples repository that exploits these packages and enables monitoring in tools like Prometheus and Influx.
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 product documentation and the sample amqsaxe0.c exit.