| Author |
Message
|
| artrod |
 Posted: Mon Jan 22, 2007 2:16 pm Post subject: Changing the trigger interval |
 |
|
Novice
Joined: 30 Mar 2005
Posts: 23
|
| When I change the trigger interval on the queue manager properties do I need to restart the queue manager for the changes to take effect? |
|
| Back to top |
|
 |
| wschutz |
| Posted: Mon Jan 22, 2007 2:54 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
No... why are you doing that? What problem are you trying to solve?
_________________
-wayne |
|
| Back to top |
|
|
| artrod |
| Posted: Mon Jan 22, 2007 3:30 pm Post subject: |
|
|
Novice
Joined: 30 Mar 2005
Posts: 23
|
| wschutz wrote: |
| No... why are you doing that? What problem are you trying to solve? |
We have not decided to change the trigger interval yet but are considering it. The queue is set to trigger on first. Messages are delivered from an ordering system throughout the business day. As they arrive the triggered application processes them into an order file. At night the flow of messages stops and the order file is processed by a batch job to create pick lists for next day delivery. For reasons we have not been able to determine sometimes the messages are not processed by the triggered app, or only some of the messages are processed. The trigger is on and there are no messages on the initq. We were considering setting the trigger interval to a value of about 1 hour (3600000 msec) to generate a new trigger message if they start to pile up on the queue. |
|
| Back to top |
|
|
| KevinF23492 |
| Posted: Mon Jan 22, 2007 4:56 pm Post subject: |
|
|
Novice
Joined: 26 Dec 2006
Posts: 22
|
The 'out of the box' default is another one of IBM's greatest brain-fart moments but even so it would be better to determine why the trigger isn't firing and the application messages aren't getting through correctly before changing a global setting.
It sounds like a syncpointing issue to me but then I don't have all the facts/logs etc.
 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 22, 2007 4:59 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'd be more inclined to guess that an app isn't properly closing the queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Jan 22, 2007 7:46 pm Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| The reason you mentioned above is a very good one for setting up the trigger interval. AFAIK, the TRIGINT doesn't need a QMGR restart on distributed platforms. I am not aware of z/OS platform though. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Jan 22, 2007 10:32 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| We were considering setting the trigger interval to a value of about 1 hour (3600000 msec) to generate a new trigger message if they start to pile up on the queue |
please keep in mind that the arrival of a message is still a condition to fire the trigger. You can specify what you want in TRIGINT, if no message arrives no trigger will be created.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| artrod |
| Posted: Tue Jan 23, 2007 10:54 am Post subject: |
|
|
Novice
Joined: 30 Mar 2005
Posts: 23
|
| Thanks for all the good feedback! We believe one of our problems is the lack of triggered apps running in the background. This can tie up the trigger monitor as there are several triggered apps on the problem servers, and we want to keep the initq and trigger monitor to 1 per system. The original design called for all triggered processes to run as background tasks to free up the trigger monitor, but someone decided they knew better. We are currently testing the apps to be started with the &. |
|
| Back to top |
|
|
|
|
