I understand about the indexing. That was why I specifically excluded it
from consideration.
"Potkay, Peter M
(PLC, IT)" To: [EMAIL PROTECTED]
<[EMAIL PROTECTED] cc:
RTFORD.COM> Subject: Re: MQGMO-WAITINTERVAL
Sent by: "MQSeries
List"
<[EMAIL PROTECTED]
AC.AT>
07/18/2003 10:44 AM
Please respond to
"MQSeries List"
If you index your queue by CorrelId or Message ID, whichever you method you
use to select your messages, you will see big performance gain.
We have an IMS app that does a get by CorrelID. Once, the reply queue had
3,000 orphans (don' t ask, its been fixed). Anyway, while that queue had
3,000 messages on it, the IMS performance folks were howling on all the CPU
being used by MQ. I cleared out the queue and they were happy.
I indexed the queue, put 10,000 dummy messages in the queue, and asked the
IMS performance folks what they saw now. No CPU usage problems at all.
-----Original Message-----
From: Dave Adam [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2003 10:31 AM
To: [EMAIL PROTECTED]
Subject: Re: MQGMO-WAITINTERVAL
I guess I should have included our design specs, this was a receiver
only channel from NT to ZOS (I am the CICS guy not MQ)
as it hit ZOS there was a trigger on the queue that would call a
process that made a request to our scheduling package to submit a job
to off-load the queue to a VSAM file for a daily process (and the
structure of the data was that each detail line was a separate
message and could consist of up to 5000 messages per entity
when I started to look at this I made some suggestions, one was get
the entity to a single message, which we have done
now we took the wait out and no delays, but are in the process of
removing the trigger and scheduling the off-load job to run a couple
times a day, and as the first step of the daily process
however, we have a second application, that requests thousands of
jobs that do the same thing to DB2, and I was hoping to add a wait so
I could cut the jobs to a handful, by keeping the off-load alive
longer (none of this goes through CICS)
but you mentioned orphans that increase in numbers making your
process run slower and have a possibility of not meeting goals
could you not write an audit trail when the request is made in CICS,
so you could schedule a process that could determine if the orphan
could be deleted
for our SYSPlex, we use the coupling facility for Temp Storage and I
run a task every 2 hours that (by queue) determines if it is still
valid, and if not, I delete it, and some of the queues have up to a
24 hour lag time
you are absolutely correct about the level of understanding on my
part, and I can relate to your situation, but even with the lack of
knowledge, I removed 90% of the definitions in our MQ system, and we
now are running without calls to the help desk
I'll be the first one to admit that I don't know or understand MQ,
but I will also tell you I have had alot of fun redoing this
environment, eliminating errors, having programmers make changes and
actually see the results they expected
maybe we have too simplistic an environment now, but I can't seem to
find the complexity people said we had
so your insight into the real-time distributed process hits home and
is one I will pass on to our Architects, who I hope take ownership of
MQ here
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
If one of the engines on a two engine plane fails
The other engine will always get you to the site of the crash
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ronald Weinger <[EMAIL PROTECTED]>
Sent by: MQSeries List To:
<[EMAIL PROTECTED]> [EMAIL PROTECTED]
cc:
Subject: Re:
07/18/2003 07:28 AM MQGMO-WAITINTERVAL
Please respond to MQSeries List
Does anyone understand the internal process? Consider: (Assume
priorities
and any other MQ and CICS settings are the same, and no indexing)
Assume it takes up to 30 seconds for a remote application to process
a
reply. In that time, 10 CICS transactions in 1 second intervals send
requests and issue a GET-WAIT with CORRELID for 40 seconds against
the
same reply queue. After 10 seconds there would be 10 suspended CICS
transactions waiting for a response. Since we do not know what the
requests were, or where they went, but only that they all come back
to the
same reply queue, we can not assume they will be processed in order.
Within
a 4 second period,replies are received, for the 10th transaction,
7th,6th
and 3rd, in that order. MQ has to 'read' the queue and determine
which
message belongs to which transaction, provide that transaction with
the
message, and get it dispatched, or it has to determine which
transaction
belongs to the message, have that transaction dispatched so it can
re-issue
the MQGET . Which of those 4 transactions will be 'given the reply
first?
If there are 600 previously 'orphaned' messages on the queue (that
were not
picked up because of previously expired waitintervals), does MQ have
to
loop though these messages each time and somehow check them against
curent
requests, since it can not know that any of the older messages are
orphaned, until it reaches the 'new' replies? As the reply queue
depth
increases , that would take longer and longer. What if one of the
'current' replies arrives at 39.995 seconds. With a 40.000 sec
waitinterval, the response came back in time, but could the
transaction
timeout before MQ can process the reply message? If there are
messages on
the reply queue that MQ hasn't somehow 'processed' against waiting
requests it can not ligitimately have those transactions that exceed
the
waitinterval sent a 2033, or can it?
"Tim Armstrong"
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
OM> cc:
Sent by: Subject: Re:
MQGMO-WAITINTERVAL
"MQSeries List"
<[EMAIL PROTECTED]
n.AC.AT>
07/17/2003 06:52
PM
Please respond to
"MQSeries List"
However this may well be the desired behaviour in that it saves the
overhead involved in connecting to the queue manager and opening
queues for
each message that arrives. Also if you use trigger on first and close
the
queue and disconnect while messages are still on the queue another
trigger
message gets fired, its designed this way to handle the small
interval in
which a message can arrive between the time your get fails with
rc=2033(no
more messages) and you issue the close for the queue. However it can
also
cause a triggering loop and your application should check the backout
count
of the messages it retrieves.
Regards
Tim A
Dave Adam
<[EMAIL PROTECTED] To:
[EMAIL PROTECTED]
RVALU.COM> cc:
Sent by: MQSeries Subject: Re:
MQGMO-WAITINTERVAL
List
<[EMAIL PROTECTED]
N.AC.AT>
18/07/2003 05:30
Please respond to
MQSeries List
thanks
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
If one of the engines on a two engine plane fails
The other engine will always get you to the site of the crash
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"Potkay, Peter M (PLC, IT)"
<[EMAIL PROTECTED]> To:
Sent by: MQSeries List [EMAIL PROTECTED]
<[EMAIL PROTECTED]> cc:
Subject:
Re: MQGMO-WAITINTERVAL
07/17/2003 01:34 PM
Please respond to MQSeries List
"the batch job would get triggered on the message entering the queue,
then
sit in the initiator for up to 30 seconds, in case another message
comes
along, and the trigger would be nonfunctional for that 30 seconds "
>>>Correct, if the queue that is triggered is currently opened by an
app,
then no more trigger message will be generated for that queue.
"I assume that the timer gets reset to 30 seconds on every message
that
comes through, so the job could stay active all day if we get 1
message
every 20 seconds"
>>>Correct.
-----Original Message-----
From: Dave Adam [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2003 2:24 PM
To: [EMAIL PROTECTED]
Subject: Re: MQGMO-WAITINTERVAL
okay, I finally found this part in my book
WaitInterval
The WaitInterval field specifies the maximum time (in milliseconds)
that
the MQGET call waits for a message to arrive on the queue when you
use the MQGMO_WAIT option. If no message arrives within the time
specified in WaitInterval, the call completes and returns a reason
code
showing that there was no message that matched your selection
criteria on
the queue.
the sample program had 2 parts, but said the default was 5 minutes
compute mqgmo-option = mqgmo-wait + ...
and a move of 30000 to mqgmo-waitinterval
I take it, that:
the batch job would get triggered on the message entering the queue,
then
sit in the initiator for up to 30 seconds, in case another message
comes
along, and the trigger would be nonfunctional for that 30 seconds
I assume that the timer gets reset to 30 seconds on every message
that
comes through, so the job could stay active all day if we get 1
message
every 20 seconds
Dave Adam
Supervalu Home Office
Project Specialist
(952) 828-4736
[EMAIL PROTECTED]
If one of the engines on a two engine plane fails
The other engine will always get you to the site of the crash
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Stefan Sievert
<[EMAIL PROTECTED]> To:
Sent by: MQSeries List [EMAIL PROTECTED]
<[EMAIL PROTECTED]> cc:
Subject: Re:
MQGMO-WAITINTERVAL
07/17/2003 12:16 PM
Please respond to MQSeries List
Dave,
here's what my book says:
[quote]
Wait interval.
This is the approximate time, expressed in milliseconds, that the
MQGET
call waits for a suitable message to arrive. [...]
On OS/390, the period of time that the MQGET call actually waits is
affected by system loading and work-scheduling considerations, and
can vary
between the value specified for WaitInterval and approximately 250
milliseconds greater than WaitInterval.
[/quote]
So, your value of 30000 should lead to a 30 second wait on the MQGET.
Your
elapsed job time sounds like it confirms that.
HTH,
Stefan
>From: Dave Adam <[EMAIL PROTECTED]>
>Reply-To: MQSeries List <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: MQGMO-WAITINTERVAL
>Date: Thu, 17 Jul 2003 11:05:04 -0500
>
>what is the breakdown for MQGMO-WAITINTERVAL
>
>does a value of 30000 equate to 30 seconds
>
>book implies it is 5 minutes, but job runs for 35 seconds, with the
wait
>specified at PIC S9(09) BINARY VALUE 30000
>
>Dave Adam
>Supervalu Home Office
>Project Specialist
>(952) 828-4736
>[EMAIL PROTECTED]
>
>If one of the engines on a two engine plane fails
>The other engine will always get you to the site of the crash
>
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
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
This communication, including attachments, is for the exclusive use
of
addressee and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If
you are not the intended recipient, please notify the sender
immediately by return email and delete this communication and destroy
all
copies.
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
The information contained in this message may be CONFIDENTIAL and is
for the intended addressee only. Any unauthorized use, dissemination
of the information, or copying of this message is prohibited. If you
are not the intended addressee, please notify the sender immediately
and delete this message.
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
The information contained in this message may be CONFIDENTIAL and is for the intended
addressee only. Any unauthorized use, dissemination of the information, or copying of
this message is prohibited. If you are not the intended addressee, please notify the
sender immediately and delete this message.
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
