Author |
Message
|
sebastia |
Posted: Wed Jan 14, 2009 4:03 pm Post subject: why can't I see the trigger messages ? |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
I want to see the trigger messages,
so I did setup a small environment :
The data queue :
QUEUE(QDADES) TYPE(QLOCAL)
INITQ(QINIT) TRIGGER
TRIGTYPE(FIRST)
and the initiation queue :
QUEUE(QINIT) TYPE(QLOCAL)
There is no Trigger Monitor running pointed to QINIT, I know.
But when I put a data msg into QDADES,
I expected to see CURDEPTH of QINIT growing
and be able to browse the Trigger messages
in the Initiation queue (QINIT)
But they are not there. Nothing in QINIT. At all.
Any pointer to the reason why ?
I know it is always been like that.
But I never knew why. And now I want to know.
Sebastian. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Jan 14, 2009 4:24 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
If the INITQ is not open, the QM knows there is no trigger monitor running, so it doesn't produce a trigger message. You are not satisfying one of the documented trigger conditions.
Open the INITQ with a dummy app to make the IPROCS > 0, and your test will work. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 15, 2009 1:31 am Post subject: Re: why can't I see the trigger messages ? |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sebastia wrote: |
Any pointer to the reason why ?
I know it is always been like that.
But I never knew why. And now I want to know.
|
Pointers, reasons and knowledge are in the triggering section of the documentation. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
sebastia |
Posted: Thu Jan 15, 2009 1:57 am Post subject: |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
Peter - I will try it in a minute, thanks.
Vitor - I am reading the whole bunch of manuals, believe me.
2 samples :
======================
(1) Sequence of events
MQ Application Programming Guide, SC34-6064-02, page 194.
# 1. Application A, which can be either local or remote to the queue manager, puts a message on the application queue. Note that no application has this queue open for input. However, this fact is relevant only to trigger type FIRST and DEPTH.
# 2. The queue manager checks to see if the conditions are met under which it has to generate a trigger event. They are, and a trigger event is generated. Information held within the associated process definition object is used when creating the trigger message.
*** here's Peter's 1st point ***
======================
(2) Prerequisites for triggering
MQ Application Programming Guide, SC34-6064-02, page 196.
(1)...(5)
6. Start instances of the trigger monitors (or trigger servers in WebSphere MQ for iSeries) that are to serve the initiation queues you have defined. See "Trigger monitors" on page 206 for more information.
======================
But I still expected to see a trigger message.
Now, I shall try with AMQSGBR or similar.
Thanks you both. Seb. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 15, 2009 2:20 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sebastia wrote: |
6. Start instances of the trigger monitors (or trigger servers in WebSphere MQ for iSeries) that are to serve the initiation queues you have defined. See "Trigger monitors" on page 206 for more information. |
This is indeed a correct step from the documentation
sebastia wrote: |
But I still expected to see a trigger message. |
You expected to see a trigger message? As you previously stated:
sebastia wrote: |
I expected to see CURDEPTH of QINIT growing
and be able to browse the Trigger messages
in the Initiation queue (QINIT) |
This seems an unreasonable expectation as you've just started a trigger monitor who's job is to consume and process these messages.....  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
sebastia |
Posted: Thu Jan 15, 2009 2:26 am Post subject: |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
No, Vitor - I want to examine the trig msg, so ..
Quote: |
There is no Trigger Monitor running pointed to QINIT, I know. |
So, I dont meet the conditions to generate one, now I know.
Thanks.[/quote] |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Jan 15, 2009 2:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
It doesn't actually have to be a trigger monitor.
The queue just needs IPPROCS > 0... So rfhutil would work, for example.
But the trigger message is composed entirely of an MQTMC structure, which is documented in the manuals. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 15, 2009 2:51 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
sebastia wrote: |
No, Vitor - I want to examine the trig msg |
2 distinct options occur to me:
- examine the documented structure
- run the trigger montitor in a foreground window
Moving slightly off-topic, may I enquire why? "Bored" is a valid response here, as is "spirit of adventure and enquiry".
I would sound a cautionary note only if your answer is "to produce a new and better trigger monitor". A laudable goal, possible perhaps, but you'll find the IBM supplied version is a perfectly good wheel and you'll struggle to reinvent a better one. Certainly one that sufficiently rounder to justify the effort.
My personal view, other views equally valid, etc , etc _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Jan 15, 2009 2:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
The IBM supplied trigger monitor is perfectly functional.
It has no notion whatsoever of security, however. |
|
Back to top |
|
 |
sebastia |
Posted: Thu Jan 15, 2009 3:02 am Post subject: |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
Hello, Vitor.
No, I am not pretending to write a better trigger monitor.
The one we have is good enough for me ...
( )
In fact, what I am pursuing (is this the correct verb ?)
is "EnvData" and "UserData",
this is, the parameters passed to the monitor.
I wanted to see them to verify they are passed properly,
as I suspected they were "shifted" somehow.
Thanks a lot. Sebastian. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Jan 15, 2009 3:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
I wonder if you can use a Topic as an INITQ....
Then you could mirror the trigger messages...
That's an interesting thought indeed. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 15, 2009 3:20 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mqjeff wrote: |
I wonder if you can use a Topic as an INITQ....
Then you could mirror the trigger messages...
That's an interesting thought indeed. |
Very interesting.....
I feel some experiments coming on.
(And when I have built my Pub/Sub Trigger Monitor, I shall use it to Rule The World! ) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
sebastia |
Posted: Thu Jan 15, 2009 3:28 am Post subject: |
|
|
 Grand Master
Joined: 07 Oct 2004 Posts: 1003
|
I shall try to "mirror the trigger messages" ...
... but using QM Exit, this is "mirrorq.dll"
I have to recognize I still dont like Pub/Sub ... |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Jan 15, 2009 3:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
No, just use something like amqsbcg or rfhutil as a "trigger monitor". This will satisfy the necessary IPPROC condition, but still allow you to see the trigger message.
Don't bother with mirrorq.
You are running MQ v7, though, so Topics and Queues are "interchangeable". So you could create a Topic that has two subscriber queues, one that is your real initq and one that is your mirrored queue. But it might not be possible to specify that in an INITQ. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 15, 2009 3:34 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
[quote="sebastia"]I shall try to "mirror the trigger messages" ...
... but using QM Exit, this is "mirrorq.dll"
Quote: |
IMHO this is a sledgehammer to crack a nut. There are much easier ways to check the message for data (which btw isn't shifted anywhere).
[quote="sebastia"] I have to recognize I still dont like Pub/Sub ... |
It's good for what it's for. And I'd never have thought of a Pub/Sub trigger monitor, and not entirely clear on what you'd use it for in a real life scenario.
But if you're going to let every little trival objection you'll never get anywhere!
(Come, Igor! The storm reaches it's height!) _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|