| Author |
Message
|
| MQWays |
 Posted: Wed Apr 30, 2008 4:49 am Post subject: Setting up process trigger |
 |
|
Acolyte
Joined: 20 Jan 2008
Posts: 61
|
I am attempting to setup runmqdlq trigger as a process with following definitions
DIS QL(DEAD.Q)
...
INITQ(SYSTEM.CHANNEL.INITQ) ...............
... PROCESS(ROUTEDLQ)
TRIGGER TRIGTYPE(EVERY)
TRIGDATA()
DIS PROCESS(ROUTEDLQ)
PROCESS(ROUTEDLQ) APPLYTYPE(UNIX)
APPLICID(/opt/mqm/bin/runmqdlq) ENVRDATA( )
USERDATA(< /var/mqm/qrule.rul) DESCR( )
.... .....
I don't see the runmqdlq kicking in though. Do you see any obvious errors with the above configuration. The rules table is ok as I tested runmqdlq from command-line. The value of USERDATA includes redirector and the rules table. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Apr 30, 2008 4:50 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This is a very very very bad idea.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| MQWays |
| Posted: Wed Apr 30, 2008 5:00 am Post subject: |
|
|
Acolyte
Joined: 20 Jan 2008
Posts: 61
|
I would like to run runmqdlq continuously, however I think it cannot be terminated except via the kill command which I would avoid.
So the other alternative is WAIT(NO) in rules tables and configure runmqdlq as a trigger. This is what the IBM Help says
"Specify WAIT (YES) for busy DLQs, and WAIT (NO) or WAIT (nnn) for DLQs that have a low level of activity. If the DLQ handler is allowed to terminate, re-invoke it using triggering."
And my understanding is that an application can only be triggered by defining the PROCESS. TRIGDATA is mainly used to trigger channels. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 30, 2008 5:08 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| MQWays wrote: |
| I would like to run runmqdlq continuously |
This is also a very bad idea.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| MQWays |
| Posted: Wed Apr 30, 2008 5:13 am Post subject: |
|
|
Acolyte
Joined: 20 Jan 2008
Posts: 61
|
| So what could be the other alternative. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 30, 2008 5:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Lots of discussion on this topic.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 30, 2008 5:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQWays wrote: |
| So what could be the other alternative. |
As a start, don't specify TRIGGER(EVERY)!!
Taking a step back, what requirement are you meeting with this? Messages entering the DLQ indicate a configuration or emergency condition, so typically (but I accept not always) result in a problem ticket of some type and runmqdlq being run once the problem is resolved.
If you're getting stuff in the DLQ sufficiently often that you need to automate it's removal in this way, there could be an underlying problem you should look at.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MQWays |
| Posted: Wed Apr 30, 2008 5:30 am Post subject: |
|
|
Acolyte
Joined: 20 Jan 2008
Posts: 61
|
Well, my rules table is as follows
INPUTQM('QMGR') INPUTQ('DEAD.Q') WAIT (NO) RETRYINT (300)
ACTION (RETRY) RETRY (3)
ACTION (FWD) FWDQ (REAL.DEAD.Q) HEADER (YES)
This is to retry any failure thrice on the DEAD.Q and still if it doesn't go through then move it to the REAL.DEAD.Q. This is to further reduce the numbers on DLQ if possible and eventually only REAL.DEAD.Q should be monitored.
One more thing ..... is it possible to shoot out an email notification once the message reaches REAL.DEAD.Q via runmqdlq. This is on HP-UX and Linux. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Apr 30, 2008 5:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MQWays wrote: |
| This is to retry any failure thrice on the DEAD.Q and still if it doesn't go through then move it to the REAL.DEAD.Q. This is to further reduce the numbers on DLQ if possible and eventually only REAL.DEAD.Q should be monitored. |
What kind of scenario do you forsee that would cause a message to go to the DLQ, and be fixed in 900 seconds? 
Are you possibly confusing the DLQ with a backout queue?
| MQWays wrote: |
| One more thing ..... is it possible to shoot out an email notification once the message reaches REAL.DEAD.Q via runmqdlq. This is on HP-UX and Linux. |
Not via runmqdlq, but it's a modest task to write a triggered application of your own to send a mail. This doesn't prevent runmqdlq manually once the problem has been fixed (as I describe above).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Apr 30, 2008 5:50 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
When a process is started by the trigger monitor a TMC structure is passed as the first argument. runmqdlq parses the first argument as the qmgr name, and the TMC structure does not contain the qmgr name in the form expected by the app.
If you must do this, start a script which discards the TMC structure, or parses the qmgr name out of it, and then starts runmqdlq with the proper cmmd line arguments.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
|
|
