This is part of a series of blog posts which will cover features of IBM MQ that I happen to be using this week. I spend a lot of time using MQ, and not everything counts as an MQ Little Gem, or a Quirk, but is still interesting to hear about. Read other posts in this series.
In the new version of IBM MQ, V9.4.3, which has just been released, one of the features is a new set of event messages known as positive authority events which allow you to collect and keep an audit trail of all those successful requests to connect to the queue manager or open an object such as a queue.
To enable this new feature you must first have the original authority event switch enabled, and also extend the scope of authority events to cover these positive cases as well.
ALTER QMGR AUTHOREV(ENABELD) AUTHEVSC( FAILURES | ALLCONNS | ALLCHECKS )
You can think of these three possible values in the new AUTHEVSC attribute as being an increasing scope of the data emitted by the queue manager.
- With
AUTHEVSC(FAILURES) you will only have failure authority checks emitted.
- With
AUTHEVSC(ALLCONNS) you will have failures and all successful connections emitted.
- With
AUTHEVSC(ALLCHECKS) you will have failures, all successful connections and all successful resource checks too.
Some examples of the contents of these events are shown later on in this post.
In addition to the above configuration, there is also one other decision you need to think about and that is whether you want to see event messages for repeated MQOPEN calls by the same application, of the same object. This is most likely to occur for an application that uses MQPUT1 on the same queue (instead of opening it once, putting various messages, and then closing it).
So to protect against this sort of application behaviour resulting in lots of excess, identical, event messages; IBM MQ, by default, will only show you the first one an application makes and will suppress all the others for that connection.
To change this behaviour, you can utilise a qm.ini parameter.
TuningParameters:
EventMinDuplicationDelayTime=10
The number you supply can be:
- -1: which is the default behaviour, and suppresses all subsequent successful open events that duplicate the one already reported for this application connection.
- 0: Sends every individual successful open event, even if it duplicates one you have already reported for this connection.
- Number greater than zero: This gathers up the duplicate events that would have been reported (or suppressed) and only reports them once every so many seconds. When this is used, the event message also contains a count of how many events have been gathered up and the time of the first event in the collection. The time of the last event in the collection is the Put Time of the event message itself. In this situation, the first open call is reported on its own, and then the second (and subsequent) duplicate open calls are gathered up. You can see an example of these fields in the output below.
Here are a few example event messages for you to get the idea.
Connection Authorized
In the display below I have snipped the output of some of the long fields as they are a bit unwieldy to display in a blog post. The Connection Name, Connection Tag, SSL Peer Name and SSL Issuers Name have been truncated.
There's lots of great information in this event message to show all the connection time data about an inbound client connection that has successfully made a connection to your queue manager - great for an audit log.
[ 1400 bytes] Message Content
Command :44 (QMgr Event)
Reason :3391 (Authorized)
Parameter Id :2015 (Queue Manager Name)
Value :'MQ943 '
Parameter Id :1020 (Reason Qualifier)
Value :65 [0x'41'] MQRQ_CONN_AUTHORIZED
Parameter Id :3025 (User Identifier)
Value :'mqgemusr '
Parameter Id :1 (Application Type)
Value :11 [0x'B'] MQAT_WINDOWS_NT
Parameter Id :3024 (Application Name)
Value :'MQGem Software MO71 '
Parameter Id :3501 (Channel Name)
Value :'MQGEM.TLS.SVRCONN '
Parameter Id :3506 (Connection Name)
Value :'127.0.0.1.............. ...
Parameter Id :7006 (Connection Id)
Value :414D51434D51393433202020202020209A3A5A68003C0040
Parameter Id :7038 (Connection Tag)
Value :4D514354 39413341 35413638 30303343 30303430 ...
Parameter Id :1645 (Security Protocol)
Value :4 [0x'4']
Parameter Id :3544 (SSL/TLS Cipher Spec)
Value :'ECDHE_RSA_AES_256_GCM_SHA384 '
Parameter Id :3545 (SSL/TLS Peer Name)
Value :'SERIALNUMBER=65:0F:6F:62:25:B3:C2:89,CN=Morag,O=MQGem Software ...
Parameter Id :2130 (SSL/TLS Certificate Issuer)
Value :'CN=MQGem CA,O=MQGem Software ...
Parameter Id :3561 (Remote Product)
Value :'MQCC'
Parameter Id :3560 (Remote Version)
Value :'09040000'
Open Authorized
This example event message also shows the two fields that are added when duplicate events have been gathered up and output together.
[ 908 bytes] Message Content
Command :44 (QMgr Event)
Reason :3391 (Authorized)
Parameter Id :2015 (Queue Manager Name)
Value :'MQ943 '
Parameter Id :1020 (Reason Qualifier)
Value :66 [0x'42'] MQRQ_OPEN_AUTHORIZED
Parameter Id :2016 (Queue Name)
Value :'SYSTEM.ADMIN.QMGR.EVENT '
Parameter Id :1022 (Open Options)
Value :00100008
00000008 Browse
00100000 Read Ahead
Parameter Id :3025 (User Identifier)
Value :'mqgemusr '
Parameter Id :1 (Application Type)
Value :11 [0x'B'] MQAT_WINDOWS_NT
Parameter Id :3024 (Application Name)
Value :'MQGem Software MO71 '
Parameter Id :3501 (Channel Name)
Value :'MQGEM.TLS.SVRCONN '
Parameter Id :3506 (Connection Name)
Value :'127.0.0.1............................. ...
Parameter Id :7006 (Connection Id)
Value :414D51434D51393433202020202020209A3A5A68003C0040
Parameter Id :7038 (Connection Tag)
Value :4D514354 39413341 35413638 30303343 30303430 ...
Parameter Id :1478 (Event Duplicate Count)
Value :3 [0x'3']
Parameter Id :3232 (Event Duplication From)
Value :'2025-06-25T05:48:45.375Z.............. ...
I hope you agree that these event messages are a great new addition to MQ's monitoring data.
#Using-MQ-feature
#IBMMQ
#IBMChampion