Where are the man pages for MQ?

I installed the man pages for MQ 9.1.1, but they were not installed in the standard place. man runmqsc said No manual entry.

I had to use

man -M /opt/mqm/man/ runmqsc


The commands you can specify are

 addmqinf   altauth    altchl    altcomm     altlis
altnl altpro altqa altql altqm
altqmgr altqr altserv altsub alttopic
amqmfsck clearql clearstr crtmqcvx crtmqenv
crtmqinst crtmqm defauth defchl defcomm
deflis defnl defpro defqa defql
defqm defqr defserv defsub deftopic
delauth delcomm deletchl deletelis deleteqa
deleteql deleteqm deleteqr deleteserv deletpro
delnl delrec delsub deltopic dischauth
dischl dischs disclqm discomm disconn
disenauth dislis dislisst disnl dispbsub
dispro disq disqmgr disqmsta disqstat
dissbsta disserv dissub dissvstat distopic
distpstat dltmqinst dltmqm dmpmqaut dmpmqlog
dspauth dspmq dspmqaut dspmqcsv dspmqfls
dspmqinf dspmqinst dspmqrte dspmqtrc dspmqtrn
dspmqver dsprec dspserv endmqcsv endmqlsr
endmqm endmqtrc mqrc pingchl pingqmgr
purgechl rcdmqimg rcrmqobj refclus refqmgr
refsecy resetchl resolchl restclus restqmgr
resuqmgr rmvmqinf rsvmqtrn runmqchi runmqchl
runmqdlq runmqlsr runmqsc runmqtmc runmqtrm
setchaut setlog setmqaut setmqenv setmqinst
setmqm setmqprd setrec stachi stachl
stalsr startserv stopchl stopcon stoplsr
stopserv strmqcfg strmqcsv strmqm strmqtrc
suspqmgr

The verbs are

 mqback   mqbegin  mqbufmh  mqcb     mqcbfunc  mqclose
mqcmit mqconn mqconnx mqcrtmh mqctl mqdisc
mqdltmh mqdltmp mqget mqinq mqinqmp mqmhbuf
mqopen mqput1 mqput mqset mqsetmp mqstat
mqsub mqsubrq

For toilets read server….

I had a weekend away, and my experience of toilets at an airport gave me insight into servers used in computing. In the blog post below – where I say toilet – think server.

When I first joined IBM, 40 years ago we had “opinion surveys” where you could raise issues, and management would ignore them. At one feedback session, someone said we need bigger capacity toilets. There were comments like “We know you are full of ****, do you need bigger bowls?”. He meant that we needed more cubicles, because on a Friday afternoon, when some people came back from the pub, they would sit on the toilet and go to sleep. This was my first insight into the multiple meanings of the term capacity.

Later when I was just starting in performance, they replaced our mainframe machine which had one 60 MIPS CPU, with the newest machine with 6 CPUs each at 10 MIPS. The accountants saw this as the same sized computer. To us, a single CPU-bound transaction took 6 times longer – but you could now do 6 transactions in parallel, so overall the throughput was comparable. Like toilets, most of the time was spent doing I/O.

For my weekend away, I spent time at an airport in Scotland. The departures side has a central section, and a wing on either side. Our departure gate was in one wing. This had one toilet for men, and another for women. The men’s toilet had about 10 cubicles, and so if you needed one you normally did not have to wait very long. If one cubicle was out of service, this did not have a major impact on throughput. Unfortunately these toilets were closed for refurbishment. The closest toilets were back in the central area, but with only two cubicles, and you often had to wait. This showed there was insufficient capacity. If you could not wait, you had to walk further to find the next toilets. These had more capacity, but some times you still had to wait. For the ladies toilet, the queue was out of the door, and along the corridor – so a real lack of capacity – which shows lack of planning (or a male architect).

By the time I had been to the toilet and walked back to my gate, they were closing the flight!

What insight did I learn?

  • If you have several big servers, and one is shut down, you need enough capacity on the other servers to cope.
  • If you shut down one big server, the time spent per transaction will increase, as there is an increased waiting time for the servers.
  • Depending on the location of the servers, you may have extra delay getting to the servers.
  • Routing work to small servers may not help, as the servers may get overloaded. This small server is overloaded, but those two server are not busy – but you cannot route work to them.
  • A larger server can handle peaks in workload better than multiple smaller ones.
  • Some architects are not good at designing systems, for availability and capacity. You need to know the duration of your typical transaction and plan for that. Some transactions may take longer than others. In Copenhagen airport, the toilets are unisex which helps solve the availability and capacity problems!

Ive always wanted a sample MQ server, and a buggy C program

I will be educating some MQ administrators about programming MQ.

For this I needed a simple server, so they could put a message to a server and get a reply. Unfortunately MQ does not provide such a useful little program. The MQ samples have a program to put messages, get messages, and a complex scenario involving triggering, but not a nice simple server.

Ive created one in my MQTools github.

I have also put up a program source which has MQ programming errors, such as trying to put to queue which did not have MQOO_OUTPUT option, I got your message, but where is mine? The aim is that the non programmers have to change one line of code to fix it. If anyone has any suggestions for other common problems, please let me know and I’ll see if I can incorporate them.

How do I print the reason string for a reason code in my C program?

Easy:

#include <cmqstrc.h> 
MQCONN(argv[1], &hConn, &mqcc,&mqrc);
printf ("MQ conn to %s cc %i rc %i %s\n",argv[1], mqcc, mqrc,MQRC_STR(mqrc));

cmqstrc.h has code

char *MQRC_STR (MQLONG v) 
{
char *c;
switch (v)
{
case 0: c = "MQRC_NONE"; break;
case 2001: c = "MQRC_ALIAS_BASE_Q_TYPE_ERROR"; break;
case 2002: c = "MQRC_ALREADY_CONNECTED"; break;
case 2003: c = "MQRC_BACKED_OUT"; break;

...

You could write an mqstrerror, or mqerror function and include it at linkage time instead of compile time.

Which terminal am I in?

I use Ubuntu as my main work station, and found I was getting confused with so many terminals windows open. I found the following helped me manage it.

From a terminal Ctrl-Alt-T gives you a new tab with a new terminal.

I can quickly move between them using Ctrl-PgDn and Ctrl-Pg-Up – just like in a browser.

I can rearrange them using Ctrl-Alt-PgDN and Ctrl-Alt-PgUp, so my commonly used tabs are adjacent.

I can colour the terminal sessions. Select a terminal, right click, preferences. You can now create more profiles, such as “Blue” or “QMPROD” and select the colour of the font and background. I can then, from my terminal, right click, profiles, and select “Blue”. As long as I remember what I use each colour for – it is a great help.

Big disasters from little problems grow

I was talking to someone about how major accidents occur, and found it very interesting. I told a friend about it, and he said that he had found the same when he was writing critical software for an aircraft control system.

How major accidents occur.

The first guy told me about an incident which started off with the smallest problem.

  • On a ship, the light at the top of the stairs stopped working, and it was not reported (even though many people saw the light was not working)
  • Someone carrying some oil, spilled some at the top of the steps, but because the light was not working, failed to spot this.
  • The ship was coming into harbour
  • Someone else came along to go down the ladder, slipped on the oil, and bumped all the way down the ladder(10 steps) on his coccyx (the bone at the bottom of his spine) and cracked it – ouch!
  • There were not many crew on the boat, and every one rushed to help, including a first aider who should have been helping the ship to dock .
  • The ship crunched into the harbour wall. No major damage done to the ship – but an embarrassing front page photo in the local newspaper.

From a small incident, this led to a chain of incidents of increasing severity.

Critical software for an airplane control systems.

My software developer friend said he was working on a software which controlled an airplane. They tests were 99% ish successful, but there was just one test which consistently failed (in the simulator). The symptoms were that the software would sometimes freeze for about 1 second and then recover. A lot can happen in a 1 second.

They tracked it down to one line of code. In a nested set of ‘if’ statements, an ‘else’ statement was attached to the wrong ‘if’ statement due to bad indentation! This meant a field was not initialized and had garbage in it. This in turn caused a loop to be iterated over 2 million times, instead of twice.

Once they had found the problem, they then used static analysis tools (like lint) and found they had lots of “little problems”. Who would have thought the number of spaces in a line would cause a problem. Fortunately there were no real “disasters” from these little problems, and they fixed all of the little problems.

I thought it interesting how the same sort of process problems occur in totally different fields, and how important it is to fix these small niggles.

This reminds me of the time when adding a comment to a program caused it to fail to compile. Adding one more line made the file bigger and not fit in memory, so an intermediate file was used. There was a bug in this code. This was a case of “I just added a comment” actually did cause problems.

I attended a talk by one of the US astronauts who flew on the space shuttle. he said they made a point of regularly visiting the software development teams so the teams got to know the people whose lives depended on their code. If there was a problem in the software these nice people (who brought coffee and doughnuts) might die. This tended to focus the minds of the developers.

Using the monitoring data provided via publish in MQ midrange.

In V9, MQ provided monitoring data, available in a publish/subscribe programming model. This solved the problem of the MQ Statistics and Accounting information being written to a queue, and only one consumer could use the data.

You can get information on the MQ CPU usage, log data written, as well as MQ API statistics.

A sample is provided (amqsruaa) to subscribe to and print the data, but this is limited and not suitable for an enterprise environment. See /opt/mqm/samp/ amqsruaa.c for the source program and bin/amqsrua bin/amqsruac for the executables, bindings mode and client mode.

I tried to use this new method in my mini enterprise, and found it very hard to use, and I think some of the data is of questionable value.

Overall, I found

  1. The documentation missing or incomplete
  2. The architecture is poor, it is hard to use in a typical customer environment
  3. The implementation is poor, it does not follow PCF standards and has the same id for different data types.
  4. Some of the data provided is not explained, and some data is not that useful.

There is information from an IBM blog post here.

Ive written several pages on the Monitoring data in MQ midrange, I was going to blog it all – but I did not think there would be a big audience for it.