| Author |
Message
|
| brenti |
 Posted: Mon Sep 22, 2003 6:55 am Post subject: STOP TRIGGER PROCESS |
 |
|
Novice
Joined: 15 Sep 2003
Posts: 15
Location: Montreal, Quebec, Canada
|
Hello all,
I would like to be able to stop the arrival of a message on a queue from triggering a batch jcl to be submitted.
i have set up a local queue with the following trigger definition:
Trigger Definition
Trigger type . . . . . . . : F F=First,E=Every,D=Depth,N=None
Trigger set . . . . . . : Y Y=Yes,N=No
Trigger message priority : 0 0 - 9
Trigger depth . . . . . : 1 1 - 999999999
Trigger data . . . . . . :
Process name . . . . . . : TRIGGER.PROCESS
Initiation queue . . . . : TRIGGER.INITIATION.QUEUE
I have a batch trigger monitor program waiting for a message to arrive on the initiation queue. When a message arrives it submits a batch job.
What i would like to do is stop the trigger process then runs some batch jobs and then start the trigger process again.
I read about a few possible options:
1) disable and enable the gets on the initiation queue. GET(DISABLED) GET(ENABLED)
if i use this method where do the messages accumulate? on the local or initq? when the gets are enabled will the trigger montior start to
submit the batch jobs again?
2) turn on and off the trigger set option on the local queue.
Could someone please suggest the "preferred" method?
Thank you in advance. |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Mon Sep 22, 2003 9:17 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I would turn off triggering and then turn it back on when you are ready for it. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Mon Sep 22, 2003 9:24 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
The problem is going to be the trigger type.
If you disable the Queue for GETs (presumably to stop the trigger monitor from reading them), this won't stop applications PUTting messages onto the queue therefore changing the depth of the queue.
Disabling the triggering on the queue will not stop them either.
Disabling the queue for PUT will stop applications from writting messages to the queue but it the PUTting applications will have to check for this condition.
I suspect the best way to achieve what you want to do is to stop the trigger monitor for the duration. Of course you could change the trigger monitor code to 'Suspend' operations depending on on an external event.
I take it you don't want to lose the trigger messages while you process whatever it is that requires you to turn triggering off? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 23, 2003 8:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The original requirement in the question was to only stop triggering for this one queue. It had no problems with new messages arriving.
The best way to do this is to turn triggering off for the one queue.
Stopping/suspending the trigger monitor is to severe. It also stops triggering for any other queues that have triggering on and use this init queue.
By the way, if you stop/suspend the TM, you will not get any trigger messages at all. The Queue Manager is smart enough to know that if the init queue is not open, there is no TM running, so why bother writing a trigger message?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Sep 23, 2003 9:17 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
If he isn't concerned about messages arriving 'while he is out'. Then you are quite correct, disabling the queue for triggering is the way to go. I was merely pointing out the potential pitfalls of doing this with a trigger type of first.
I am accutely aware that no trigger message is written if the trigger monitor isn't running and if he doesn't want to generate a trigger message then this is not a problem.
I had sort of 'assumed' (and I know what that does too!  ) that he was using the IBM batch trigger monitor support pack and that he was only monitoring one queue. If that were the case then stopping the trigger monitor shouldn't be a big issue. I do accept though that it is a little bit of a sledgehammer to crack a nut.
I guess it really depends on what the real requirement is. Is it simply to prevent people from submitting batch work at certain times? or is it to prevent certain jobs running (or being submitted) while others are already running? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 23, 2003 9:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
potential pitfalls of doing this with a trigger type of first.
|
Can you elaborate? I am not aware of anything about Trigger Type First that would make the decision to turn triggering on or off any different than if the queue was triggered by depth or on every.
By the way we use the MA12 support pac (the IBM batch trigger monitor)and it watches an Init queue that is used by many application queues. The one batch trigger monitor is responsible for many batch applications.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Sep 23, 2003 10:09 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
The only 'pitfall' (and it is also there for DEPTH too) would be that if an application wrote a message to the queue while it wasn't triggered. Then when they switch triggering back on for the queue as the depth is now not 0 it will never trigger for a trigger type of FIRST.
All I am saying is that a little caution may need to be exercised....but this is true no matter what the solution is going to be. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 23, 2003 10:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
As soon as you turn triggering back on, if there are more than 0 messages for trigger type first, or more than n - 1 messages for a queue that is triggered on depth of n, you will get a trigger event.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Sep 23, 2003 11:35 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| As soon as you turn triggering back on, if there are more than 0 messages for trigger type first, or more than n - 1 messages for a queue that is triggered on depth of n, you will get a trigger event. |
Yes. In fact this can be one way to create additional trigger messages should one need them - turn triggering off and then on again.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 23, 2003 11:41 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
And if you are really nosy and want to se these trigger messages, do the following:
Stop the trigger monitor.
Use an app to open the init queue with the shared ioption, and have the app just sith there with the queue open (no MQGET).
Now the queue has an IPROCS of one, so the QM is tricked into thinking the init queue is being serviced by a trigger monitor.
Create a trigger event, and watch the trigger message land in the init queue. Use another app to browse that message. This is really handy to learn about triggering. No only does it show you how triggering works according to the manuals, but more importantly it lets you see when the queue manager actually generates trigger messages, which is not always clear. 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Sep 23, 2003 1:27 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Interesting. What level of MQ Series are you running?
I have just started up a trigger monitor (admittedly homegrown) and dropped a test message on a queue with a trigger type of FIRST and the message popped a trigger message (as expected). I turned triggering off for that queue (leaving the monitor running) and dropped a message onto the queue. (as expected nothing happened). I set triggering back on (leaving the message on the queue) and again nothing happened (which is what my experience has always been). So I dropped another test message onto the queue. Still no trigger message is generated. Now the depth is 2 on the queue. As my understanding of trigger type of FIRST is when that it is really a trigger when the DEPTH goes from 0 to 1 this didn't really surprise me.
I assume from what you are both saying, that this is not what should happen? We are at 5.2 (going to 5.3 next weekend) so is this an issue with 5.2? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 23, 2003 1:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
It works the same for both 5.2 and 5.3.
The following is the relevant part of the Conditions for Triggering section of Chapter 14 from the Application Programming Guide for version 5.2. You can see the 5.2 version of the manual (November 2000) here:
http://www-3.ibm.com/software/integration/mqfamily/library/manualsa/csqzal05/csqzal05tfrm.htm
From the details you provided, you should have gotten triggered when you turned triggering back on. I would suggest reading all of Chapter 14 if you already haven't. Maybe there is a detail you failed to mention that conflicts with one of dozen or so requirements for triggering to happen.
| Quote: |
The queue manager creates a trigger message when the following conditions are satisfied:
.
.
.
13.
a.
The following conditions are satisfied using MQSET or a command:
TriggerControl is changed to MQTC_ON
or
TriggerControl is already MQTC_ON and the value of either TriggerType, TriggerMsgPriority, or TriggerDepth (if relevant) is changed,
and there is at least:
One (MQTT_FIRST or MQTT_EVERY)
or
TriggerDepth (MQTT_DEPTH)
messages on the queue of sufficient priority (condition 2), and conditions 4 through 10 (excluding are also satisfied.
This is to allow for an application or operator changing the triggering criteria, when the conditions for a trigger to occur are already satisfied.
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Wed Sep 24, 2003 9:51 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
I am offsite for a few days and can't really check on the full circumstances. It may be our Triginterval that is causing it but i want to also check that the monitor is behaving itself when it removes the message that caused the trigger. Our trigger monitor actually reads the message that caused the trigger so it may be that it isn't doing it's own housekeeping properly.
I will take a look at it further when I return to the office (Monday)
L8R |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 24, 2003 4:08 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If the "trigger monitor" consumes the trigger messages, and the application messages, what is being triggered? If this application you call a trigger monitor is up all the time watching the init queue, why not just have it up all the time and just watch the application queue only? There is no point in triggering here at all.
Kevin, if this is truly the way it is, (the "trigger monitor" consumes both trigger messages and app messages), you must reconsider this design.
P.S. TriggerInterval will only ever help you get triggered, it will never prevent triggering.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Sep 25, 2003 10:09 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Peter,
The main problem with the application/trigger monitor that we have is that we use the program to do lots of different things none of which is submit a batch job. Our site doesn't allow jobs to submit other jobs through the INTRDR (not my doing).
It is true that we could have several address spaces running monitoring the application queues but we try to keep the number of started tasks down to a minimum. Waiting for a batch job to get in and deal with the messages is not an option for us, so we deal with then within the one address space (different subtasks, but one address space).
It may not be the 'perfect world' design, but so far it works for us. |
|
| Back to top |
|
|
|
|
