MQ

 View Only

IBM MQ Little Gem #28: EVENT Switches

By Morag Hughson posted Thu October 26, 2017 12:00 AM

  
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
z/OS Dist
Queue Manager Authority AUTHOREV SYSTEM.ADMIN.QMGR.EVENT
Start and Stop STRSTPEV SYSTEM.ADMIN.QMGR.EVENT
Local LOCALEV SYSTEM.ADMIN.QMGR.EVENT
Remote REMOTEEV SYSTEM.ADMIN.QMGR.EVENT
Inhibit INHIBITEV SYSTEM.ADMIN.QMGR.EVENT
Command Command CMDEV SYSTEM.ADMIN.COMMAND.EVENT
Configuration Configuration CONFIGEV SYSTEM.ADMIN.CONFIG.EVENT
Channel and bridge Channel CHLEV SYSTEM.ADMIN.CHANNEL.EVENT
Channel Auto-definition CHADEV SYSTEM.ADMIN.CHANNEL.EVENT
SSL SSLEV SYSTEM.ADMIN.CHANNEL.EVENT
IMS Bridge BRIDGEEV SYSTEM.ADMIN.CHANNEL.EVENT
Performance Queue Depth PERFMEV SYSTEM.ADMIN.PERFM.EVENT
Queue Service Interval PERFMEV SYSTEM.ADMIN.PERFM.EVENT
Logger Logger LOGGEREV SYSTEM.ADMIN.QMGR.EVENT

 

Morags_MQ_Gems_28.jpgAll 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

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)

Channel Events

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.


Morag Hughson is an MQ expert. She spent 18 years in the MQ Devt organisation before taking on her current job writing MQ Technical education courses with MQGem. She also blogs for MQGem. You can connect with her here on IMWUC or on Twitter and LinkedIn.

#Little-Gem
#IBMMQ
#ChampionsCorner
0 comments
26 views

Permalink