Jim,
That was too easy. Thanks for your response.
Thanks,
David Corbett
Work: 651-205-2714
Pager: 651-610-3842
|---------+--------------------------->
| | "Jim Ford" |
| | <[EMAIL PROTECTED]|
| | OM> |
| | Sent by: |
| | "MQSeries List" |
| | <MQSERIES@AKH-Wi|
| | en.AC.AT> |
| | |
| | |
| | 02/18/2003 11:07|
| | AM |
| | Please respond |
| | to "MQSeries |
| | List" |
| | |
|---------+--------------------------->
>-------------------------------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Subject: Re: A question on triggering & queue depth
|
>-------------------------------------------------------------------------------------------------------------------------------|
"However, since the queue depth went back to zero after the first
message was retrieved, another instance of the MQGET application will
be started when the second message arrives even though the first
instance will retrieve the message since it is already waiting on it."
One of the conditions necessary for a trigger message to be generated
is that no process has the main queue open for input. Since your app
is running, IPPROCS will equal 1, and a second process won't be
triggered.
Dave Corbett
<DAVID.CORBETT@US To:
[EMAIL PROTECTED]
BANK.COM> cc:
Sent by: MQSeries Subject: A question on
triggering & queue depth
List
<MQSERIES@AKH-WIE
N.AC.AT>
02/18/2003 10:10
AM
Please respond to
MQSeries List
I have a couple of applications that desire to use triggering in order
to
start processes. Both of these applications will be putting messages
on an
OS/390 box via a direct client connection to the OS/390. I am
planning on
setting the trigger mechanism to: TRIGGER FIRST.
Once the application gets triggered, it will issue the MQGET with a
wait of
as yet unspecified time. After a successful MQGET, the program will
loop
around and issue another MQGET. If there are no messages in the
queue, it
will shut down. My goal is to balance the cost of starting a
transaction
with the cost of keeping a long running transaction active in CICS all
day.
Assuming this is a relatively low volume application (less than 1
message
per second), I was planning on setting the wait time to ten seconds.
My
confusion on triggering is this; If triggering is set as described
above, I
will trigger my MQGETting application when the first message arrives.
The
application will then read the message and wait for ten seconds. If
another message arrives on the queue within these ten seconds, the
application will get the message and loop around again. However,
since the
queue depth went back to zero after the first message was retrieved,
another instance of the MQGET application will be started when the
second
message arrives even though the first instance will retrieve the
message
since it is already waiting on it.
If the messages are semi-sporadic, coming in at one every 2-3 seconds
during heavy use and 1-5 per minute during lighter times, is there a
rule
of thumb for setting wait time limits? Has anybody out there dealt
with
this and what have you found to be an acceptable wait time?
I have applications currently running with messages coming at a speed
of
5-10 per second and yet I never see the queue depth greater than zero
if I
try to monitor it with the standard MVS MQ utility. It seems to me
that no
matter what I set a wait time to, the queue depth will always return
to
zero and therefore continue to spawn instances of the MQGET
application on
every message. It's almost like I should set a minimal wait time of
say 50
milliseconds just to let MQ commit the message from the queue before
the
MQGET times out.
Any thoughts on this are greatly appreciated.
Thanks,
David Corbett
IBM Certified Solutions Expert - MQSeries
Instructions for managing your mailing list subscription are provided
in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive
