Handling MQ events

I found it hard to find information about MQ events and what to do with them, so Ive documented my thoughts below.

Thanks to Gwydion and Morag for the many corrections!

MQ writes messages to system queues when specific activities occur, for example when a channel is made put(disabled) or a channel stops.  This allows you to have a program take these and take actions.

Ive categorised the actions into

  • When
    • Now – for example queue full – needs to be actioned today(now!)
    • Tomorrow – for example a configuration error – raise a change ticket and get it fixed
  • Who
    • Operations
    • System administrators – who define objects
    • Application programmers – responsible for application queues

Different queues are used depending on the event

Useful links

The one trick magician

Our neighbour’s son came up to me and said “I am a magician – look here is my trick”.   The trick was a good trick, but then I had to explain that being a magician is more than doing just one trick.

I thought of this as I was reviewing some old note books and found the comments I made about a customer visit, and the “MQ architect and lead MQ programmer”.
This architect knew about Request-Reply and Fire-and-Forget, but he was missing other tricks.

The conversation went along the following lines

Messages processed in strict sequence

Me: Do your messages have a requirement to be strictly processed in sequence?
Him:  I dont know, why?

Me:You can only have one putting application, one channel, and one application getting messages.  If you have more than any of these – you can get messages processed in the wrong order.

Availability and scalability

Me: What response time requirements do you have for the end-to-end transaction?

Him: under 5 seconds

Me: If the back end queue manager goes down, how long does it take to restart?
Him:About a minute

Me: So one backend will not provide the availability you need.

Him: But we use clustering!
Me: On how many queue managers is the queue defined on?

Him: One

Me: Do you use different clusters for online and batch traffic?
Him:Why?
Me: To isolate traffic, and ensure that batch does not impact online, either in channel throughput – or filling up the System.Cluster.Transmit.Queue.

and so it went on.

 

 

 

 

 

 

Some MQ Cluster defaults are dangerous

The defaults for many cluster channels are not very good.  For example the values for
CLWLPRTY,  CLWLRANK and CLWLWGHT are all 0, meaning the lowest priority.

If you want to make one connection or queue a lower priority, you have to alter all the cluster receiver channels, and local queues, to have a value  – such as 5, let the definitions propagate round the network, and then change the one you wanted!

It may be worth doing this over an extended period, so you get good values, without disrupting your MQ environment.