Bitesize Blogging: MQ V8 - Simple Suppression of Console Messages on z/OS
MattLeming 120000MN5R Visits (3727)
Another in the series of bitesize blog posts about features in MQ V8. Check out the whole series here.
Have you ever got annoyed by the volume of certain console messages output by the z/OS queue manager and channel initiator? Did you wish that there was a simple way of turning them off? If so, then this blog post is for you.
Here in the world of MQ development, we like to think that we only issue console messages when we really need to, and that when they are issued, they are of use to you. However for those messages that are issued regularly this might not be the case, and those messages might be viewed as an annoyance which you want to suppress.
Prior to MQ 8 there were ways to suppress console messages which you didn't want, for example using the message processing facility, or a WTO/WTOR installation exit. However as a queue manager administrator you might not have the authority to set these up. And even if you did there is still a CPU cost associated with the queue manager issuing a message, only for it to be suppressed.
MQ 8 introduces the EXCLMSG parameter which can be used to suppress a subset of console messages before the queue manager issues them. For example to suppress the messages issued when a SVRCONN channel starts (CSQX511I) and stops (CSQX512I), issue the following command:
SET SYSTEM EXCLMSG(X511,X512)
That's it, you are done, you will not get annoyed by CSQX511I and CSQX512I messages again! Note that this approach will only work until the queue manager is next shut down. If you want these messages permanently suppressed the EXCLMSG parameter can also be specified as a system parameter using the CSQ6SYSP macro.
This is also a good time to point out that the CSQX511I and CSQX512I messages are new in MQ 8. In earlier versions the CSQX500I and CSQX501I messages were used to indicate when all types of channels were starting or stopping. Now these messages are only issued for channels that aren't SVRCONNs.
More information on this can be found in the IBM Knowledge Center here.