This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.
IBM MQ has a number of different types of events that can be emitted by the queue manager. Below is a table summarising them.
|Event Type||Event Sub-Type||Event Switch||Event Queue||Platform Availability|
|Start and Stop||STRSTPEV||SYSTEM.ADMIN.QMGR.EVENT||✔||✔|
|Channel and bridge||Channel||CHLEV||SYSTEM.ADMIN.CHANNEL.EVENT||✔||✔|
|Queue Service Interval||PERFMEV||SYSTEM.ADMIN.PERFM.EVENT||✔||✔|
All these switches have the values ENABLED and DISABLED to turn on or turn off the event notifications.
This is probably something that you're already aware of though, and doesn't really constitute a less likely to be noticed feature of IBM MQ. However, some of these event switches have more than the standard two values. That's what this post is about.
Command events are notifications for any command, MQSC or PCF, that is issued to the command server. For example, someone issues the REFRESH CLUSTER command at peak time of the day, you can see from a command event who did that, and from what environment.
However, there are some commands that you might not be as interested in. Specifically, you might not be interested in all the DISPLAY commands that are issued. These are non-destructive commands, and perhaps you feel they just detract from the real commands that are issued.
Well if this is so, you can set your command events switch, not to ENABLED, but to another third value, NODISPLAY. This third value indicates that you are interested in command event notifications for all commands except DISPLAY commands.
ALTER QMGR CMDEV(NODISPLAY)
Channels events include notifications for channels starting and stopping when they are supposed to and also channels reporting errors which caused them to end in error, and go into retry. In essence channel events mimic all in the information you find about channels in the error log, but in a way that can be consumed by a monitoring application, or indeed any remotely connected user that can't look at the error log because they are not able to look at the files on the machine.
However, if all your channels do most of the time is start when they are supposed to and end when they are supposed to, this can be less than useful information. What you really want to know is the interesting stuff, and by that I mean, the stuff that goes wrong!
So there is a third value for the channel event switch. You can set it to EXCEPTION. This indicates that you want channel events to be turned on, but not to bother with the start and normal end events, and only give out notifications for the exceptions, the channels that ended abnormally.
ALTER QMGR CHLEV(EXCEPTION)
So now you know that events are not all just on or off. Review your event switches and see if you can gain any efficiencies by not generating events that you choose to throw away anyway.