One of our MQ client application is doing a MQGET based on the the correlation identifier (CorrelId) field of their reply messages so they can associate the reply with its original request. However, this has not been implemented in production yet.
Both client and server apps are going to run on NT.
My concern is if the queue index is available on OS/390 platform, applications on the NT side can only get messages from queue by what is the next available message in the queue?
"Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote:
Yes, it is a queue parameter available on z/OS (OS/390) only.-----Original Message-----
From: Teresa Cheung [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2003 3:00 PM
To: [EMAIL PROTECTED]
Subject: Re: MQGMO-WAITINTERVALHi Peter,When you say "index your queue by CorrelId or Message ID", is it done by queue configuration or something else?Thanks,TC
"Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: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 <[EMAIL PROTECTED]>07/18/2003 07:28 AM
Please respond to MQSeries List
To: [EMAIL PROTECTED]
cc:
Subject: Re: MQGMO-WAITINTERVAL
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
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
