MQ

Hi Sebastian,

If you are using trigger first / depth on shared queues then when the trigger criteria are met a trigger message is generated on each active queue manager. So the behaviour you are getting is by design.

What are your message arrival patterns? Do lots of messages come in, or is it only a few? Is the 2042 really a big issue?

Regards, Matt.

Hey Matt,

it is unfortunately, since the the STC does not come back automatically from the 2042 and goes on vacation unless someone bounces it.

It's not a whole lot of messages, but they usually some in smaller batches scattered around the day. We did try it with trigger settings first and depth, but we have had the feeling that the way things were designed ages ago just are not up to what we need anymore.

I'm afraid we do have to redesign the old code after all or live with the manual labour of running a dedicated init queue, albeit knowing that it is the SPOF we tried to eliminate.

If you are getting small batches of messages which are processed quickly then you could consider KEYRNOTIFYDELAY: https://www.ibm.com/docs/en/ibm-mq/10.0.x?topic=zos-tuning-coupling-facility-list-monitoring

If you set that on the CF structure the queue manager will initially only generate one trigger message, with a second coming in after the delay time. The question is whether you can come up with a reliable number for the time. Its also worth pointing out that KEYRNOTIFYDELAY affects all shared queues on the structure so you probably want to have a dedicated structure for it. I imagine some experimentation might be required. 

Is it really such a big issue that both jobs are started? It means you get the redundancy it sounds like you need. 

Regards, Matt.

I'll try my luck with the KEYRNOTIFYDELAY parameter, this may help us in this situation.

In terms of infrastructur, I agree, it is normal and good redundancy. However, the developer and the deparment that works with the data has issues with that (Don't ask me what the issues are, I don't understand it either, but it's not a technical issue)

I will do some testing and report our findings.

Cheers

This might be a possibility. Change the shared queue to trigger a CSQUTIL job that will MOVE QLOCAL the message on the shared queue to another non-shared queue (e.g. Q1). Also, change the configuration so that Q1 is the queue that triggers the application batch job. On both queue managers, the CSQUTIL MOVE QLOCAL job will probably be triggered to run at the same time, but only one CSQUTIL MOVE QLOCAL job should win to move the message from the shared queue to its local Q1. This will result in the application batch job only running on one queue manager.