It was asked recently on the List-Server whether there was an easy way to determine which MQI channels were being used. The asker also raised an RFE to request Channel Statistics be output by the queue manager for these channels as well as the MCA channels that do currently have statistics.
While that facility would indeed help to show which channels were being used, and for what amount of time/traffic and so on, if the problem at hand is only to determine which channels are used and which are not, for example so that unused ones can be deleted, then a current facility of the queue manager is available to discover that.
The Channel Authentication (CHLAUTH) rules which block connections into the queue manager have two modes, blocking and warning. This is controlled by the WARN(YES|NO) attribute. This was briefly discussed in my blog post CHLAUTH – the back-stop rule, to alleviate any concern of initially blocking all connections into a currently working queue manager.
Now here’s another use for WARN(YES).
If you already use CHLAUTH and already have a back-stop rule that covers all channels, then you know that only those you have positive CHLAUTH rules in place for can be being used.
If you don’t already use CHLAUTH, or at least your use of it is not applied to all channels, you could put a rule very similar to the back-stop rule in place, but using warning mode, and then see which channels are being used over time.
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) WARN(YES)
Alternatively, if you’re just trying to figure out if a specific channel (or channels) is actually ever used, you could make the rule specific to that channel name.
SET CHLAUTH(MORAG.SVRCONN) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) WARN(YES)
Either way, to see useful output from this, you should enable channel events, and monitor for the event messages emitted by the queue manager.
ALTER QMGR CHLEV(EXCEPTION)
Here’s an example event message that would be seen by a channel called MORAG.SVRCONN connecting into the queue manager. As you can see, you are shown the channel name, connection name (i.e. the IP address where the client resides), the client side user id and the application name (in this case q.exe). All very useful for working out what it was that ran and caused this channel to be used.
[ 224 bytes] Message Content [ 224 bytes] Event Header (MQCFH) Version :1 Command :46 (Channel Event) Sequence No. :1 Reason :2578 (Channel Blocked Warning.) Parm Count :7 [ 188 bytes] String (MQCFST) Parameter Id :2015 (QMgr Name) String Length:4 Value :'MQG2' [ 164 bytes] String (MQCFST) Parameter Id :3506 (Connection Name) String Length:9 Value : [ 132 bytes] Integer (MQCFIN) Parameter Id :1020 (Reason Qualifier) Value :23 [0x'17'] MQRQ_CHANNEL_BLOCKED_NOACCESS [ 116 bytes] String (MQCFST) Parameter Id :3501 (Channel Name) String Length:13 Value : [ 80 bytes] String (MQCFST) Parameter Id :3567 (Client User Id) String Length:5 Value : [ 52 bytes] String (MQCFST) Parameter Id :3024 (Appl Name) String Length:16 Value : [ 16 bytes] Integer (MQCFIN) Parameter Id :1 (Appl Type) Value :11 [0x'B'] MQAT_WINDOWS_NT
N.B. When trying this out for yourself, if you truly only want a logging style use of CHLAUTH and you don’t want anything else to be affected while you do this, including SYSTEM channels and remotely asserted privileged user ids, then you’ll have to first remove the default provided CHLAUTH rules.
I was prompted to write this post as a result of this list-server question.