CODEWITHSUNDEEP
ibm-mq
AnilReddy
AnilReddy

Reputation: 222

Triggering for events

I have a queue definition like below:

DEFINE QLOCAL(TRIG.QLOCAL) + 
       DESCR('Example Queue for Triggering') + 
       DEFPRTY(0) + 
       DEFSOPT(SHARED) + 
       GET(ENABLED) + 
       MAXDEPTH(5000) + 
       MAXMSGL(4194304) + 
       MSGDLVSQ(PRIORITY) + 
       PUT(ENABLED) + 
       QDEPTHHI(80) +
       QDPHIEV(ENABLED)+
       RETINTVL(999999999) + 
       TRIGTYPE(EVERY) + 
       PROCESS(TRIG.PROCESS) + 
       INITQ(TRIG.INITQ) + 
       USAGE(NORMAL) + 
       REPLACE

I have defined the process like below: 

DEFINE PROCESS(TRIG.PROCESS) APPLTYPE(UNIX) +
       APPLICID(/appn/sy31/QdepthHiAlert.sh) +
       ENVRDATA(' ') +
       USERDATA(' ') 
       DESCR('PROCESS FOR TESTING QDEPTH HIGH EVENT') +
       REPLACE

I have a trigger monitor running as service like below: 

   SERVICE(TRIGGER_MONITOR)                STATUS(RUNNING)
   PID(49610840)                           SERVTYPE(SERVER)
   CONTROL(QMGR)                           STARTCMD(/usr/bin/runmqtrm)
   STARTARG(-m PACOHB20 -q SYSTEM.DEFAULT.INITIATION.QUEUE)

Here are my questions:

  1. I thought, all the trigger messages will be processed by trigger monitor script. If we don't configure it on the INITQ, process which is associated with the queue will not run. Is that correct?
  2. If Yes, Our trigger monitor is not running on the queue's INITQ(TRIG.INITQ). Must we run the trigger monitor on the INITQ too?
  3. When we are configuring the transmission queues for triggering, we have defined the trigger data and process definitions. Though we didn't configure the trigger monitor on the initiation queue, the channel is started since we have runmqchi on the system.channel.initiation.queue. So runmqtrm and runmqchi function similarly?
  4. In here, we have the triggering for EVERY message and queue depth high event. In both the cases, trigger message will be placed to the same INITQ. So, how do we know what kind of alert we are receiving?

Upvotes: 2

Views: 1169

Answers (1)

T.Rob
T.Rob

Reputation: 31832

OK, let's take these one at a time.

I thought, all the trigger messages will be processed by trigger monitor script. If we don't configure it on the INITQ, process which is associated with the queue will not run. Is that correct?

If I understand what you are asking, it is whether the process is fired if there's nothing listening on the initiation queue. That is correct. The application queue must have TRIGGER set and specify the INITQ value. The specified initiation queue must have an open input handle in order for MQ to format and place the trigger message.

If Yes, Our trigger monitor is not running on the INITQ : TRIG.INITQ. do we must run the trigger monitoring on the INITQ too?

Yes. The queue's INITQ is where the QMgr will place any trigger messages. The QMgr will not place the trigger messages unless there is an open input handle on that initiation queue, and that handle had better be from a trigger monitor it it won't work.

When we are configuring the transmission queues, for triggering, we have defined the trigger data and process definitions. Though we didn't configure the trigger monitor on the initiation queue, channel got run since we have runmqchi on the INITQ. So runmqtrm and runmqchi function similarly?

The channel initiator is a LOT more forgiving of sloppy configuration than is the trigger monitor. It's easy to work out from the channel definition which transmission queue it uses. So MQ figures that if the administrator defined a queue of type XMITQ set it to TRIGGER then the intent must be to start a channel. It then works backward from the channel defs to discover which channel is associated with that queue.

But there are no such safe assumptions with runmqtrm. You must connect the dots from the queue's INITQ and PROCESS attributes to the trigger monitor listening on the specified INITQ and the associated process starting, correctly reading the trigger message, and then processing the queue as intended.

In here, we have the triggering for EVERY message and queue depth high event. In both the cases, trigger message will be placed to the same INITQ. So, how do we know what kind of alert we are receiving?

These are two different things. Only one type of triggering can be specified on a queue and it is one of FIRST, DEPTH, or EVERY. You can also specify that the QMgr will emit an event message to an event queue (not an initiation queue) when the queue depth exceeds some threshold.

The two things are related but completely different types of instrumentation. The triggering instrumentation is designed to start processes under certain conditions. The queue depth events are designed to feed real-time operational information to monitoring agents listening on the event queues.

For more about triggering, including a mini-tutorial built around a useful application and sample scripts to implement it, please see Mission:Messaging: Easing administration and debugging with circular queues

Upvotes: 6

Related Questions