| Author |
Message
|
| giuly020277 |
 Posted: Thu Mar 07, 2013 8:19 am Post subject: how to delay getting messagges from queue |
 |
|
Centurion
Joined: 07 Aug 2007
Posts: 146
Location: Florence,Italy
|
Hello everyone again  ..
I need to know if it's possible to delay a program that get messages from queue ( websphere Mq on zos).
I have a queue on zos triggered type "every". a program get message and process it in a few time. Programmer don't wan't to have some process that run togheter..so he would delay that...
It's possible only changing program that get messages from queue ( maybe introducing a delay of X seconds from one get to another) or exist some parameters on Webpshere Mq on zos that do it?
what about service interval? I have read about it...it seems it could be useful.
What do u think?
Thank u all |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Mar 07, 2013 8:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It depends on what you mean by "is it possible".
Yes, it's possible. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Mar 07, 2013 9:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Trigger every is a bad idea. Your design sounds like a poor one.
Use trigger first and design the program to read the queue until it is empty, then terminate. Using MQGET with a modest wait interval (MQGMO_WAIT) will also help to reduce the number of times (even this better design) has to be invoked.
That way only one process servicing this queue will run at one time.
Incidentally set the QM trigger interval to some value like 60000 to make sure any trigger queues get re-triggered if something goes wrong and the queue is not drained. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 07, 2013 9:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| Trigger every is a bad idea. |
You missed the part, zPat, where giuly020277 said "on zos".
trigger every is still the recommended option for CICS, afaik. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Mar 07, 2013 12:07 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
CICS is not mentioned. However my design also works in CICS.
Of course CICS has transaction management which can control the number of concurrent tasks and so on, but that's like making a virtue out of a necessity with the trigger every. It sounds like he does not want or need parallel processing.
It also depends if the CICS transaction is MQ aware, or one of the olde-worlde pass the message in the commarea dinosaurs. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Mar 07, 2013 1:36 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| zpat wrote: |
| CICS is not mentioned. However my design also works in CICS. |
Both of these statements are true. However the vast bulk of MQ work on z/OS is done via CICS, and the use of trigger "every" implies it. While your design does indeed work and is usually the recommended option, trigger "every" remains the exception that proves the rule if you're using CICS.
| zpat wrote: |
| Of course CICS has transaction management which can control the number of concurrent tasks and so on, but that's like making a virtue out of a necessity with the trigger every. It sounds like he does not want or need parallel processing. |
It sounds like he wants parallel processing, just a bit less parallel.
| zpat wrote: |
| It also depends if the CICS transaction is MQ aware, or one of the olde-worlde pass the message in the commarea dinosaurs. |
The use of a trigger mostly answers that.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Mar 07, 2013 2:31 pm Post subject: Re: how to delay getting messagges from queue |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| giuly020277 wrote: |
| Programmer don't wan't to have some process that run togheter.. |
Why not? TRIGGER EVERY implies that multiple copies of the program may be running together to process messages.
If there is more than say one message per second it might be better to use TRIGGER FIRST, and the program loops after processing each message to get the next one. Use a Wait Interval of say 10 - 60 seconds. If there are no messages to get after that time, exit the program.
In fact, a TRIGGER EVERY program should also be written as a loop, with a short Wait Interval. This handles the situation where not enough triggers got fired or not enough copies of the program were able to start, and there are still messages sitting on the queue.
_________________
Glenn |
|
| Back to top |
|
|
| giuly020277 |
| Posted: Fri Mar 08, 2013 12:18 am Post subject: |
|
|
Centurion
Joined: 07 Aug 2007
Posts: 146
Location: Florence,Italy
|
sorry...
yes..my queue is triggerd by cics...and i want to process one message at time...and i don't want to have so many process togheter.
I'd like to process a messages...wait for some times to permit it to end...then process another one...and so on...
Programmer don't want to have some process togheter...who cause traffic on websphere application serve |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 08, 2013 2:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Yours is an unusual requirement. It is rare for someone to complain that messages are being processed too quickly.
It is unusual to require (limit) one consumer app only, but not unheard of. Message-affinity demands a single consumer get messages when two or more messages comprise a transaction.
If the requirement is for only onre consuming application, then use the queue attribute trigtype (depth) with depth (1). This will turn off triggering after the first msg arrives on the queue, and the first consumer app is launched. The app must set triggering on before the app ends.
Some languages support a timer-wait function. Such a function could be writtrn is assembly language on z, and called from cobol or c.
The app could get the current time-of-day, then loop until n-seconds elapse. Both techniques are possible, but make little sense to me
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| giuly020277 |
| Posted: Fri Mar 08, 2013 3:09 am Post subject: |
|
|
Centurion
Joined: 07 Aug 2007
Posts: 146
Location: Florence,Italy
|
I agree with u bruce...but programmer ask me that.
Thay have an application that spent x time to process one messagge.
So...they don't want to have traffic caused from multiple messages that arrive on queue sequentially...
I will tell them to add a wait on their application.
I have seen the parameter "service interval" on Queue Manager on zos.
What does it do??Do u know it? |
|
| Back to top |
|
|
| Toronto_MQ |
| Posted: Fri Mar 08, 2013 6:47 am Post subject: |
|
|
Master
Joined: 10 Jul 2002
Posts: 263
Location: read my name
|
| Vitor wrote: |
| However the vast bulk of MQ work on z/OS is done via CICS |
Is this really the norm in most shops? Not here. We have CICS but it's not our biggest MQ user on z. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 08, 2013 7:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Toronto_MQ wrote: |
Is this really the norm in most shops? Not here. We have CICS but it's not our biggest MQ user on z. |
Looking at it from the other direction, most z/OS shops have CICS as their transaction work-horse. CICS predates WMQ by a few decades. WMQ, in its role as middleware, extends access to CICS and batch apps, and z/OS data, to other platforms.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 08, 2013 7:54 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Toronto_MQ wrote: |
| Vitor wrote: |
| However the vast bulk of MQ work on z/OS is done via CICS |
Is this really the norm in most shops? Not here. We have CICS but it's not our biggest MQ user on z. |
Slightly bold statement I suppose. In my experience this is the case; WMQ is leveraged principally for real time transactions which,of course, run under CICS & I echo the point about CICS being entrenched as a work horse.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
