| Author |
Message
|
| offshore |
 Posted: Wed Jan 14, 2004 11:21 am Post subject: trigger above 10K |
 |
|
Master
Joined: 20 Jun 2002
Posts: 222
|
All,
I have a queue that is triggered by depth. Recently, it was set to trigger a program @ 10,000 messages.
In the past it was set to trigger @ 4000 and 8000, but the program never went past those numbers on the number of messages the were taken off the queue.
Recently, I set the trig depth to 10,000 before the the trigger was initiated. Now, the program decides it will read all the messages off the queue.
I changed it back today to 8000 and the program read only 8000 messages off the queue each time it has ran.
I'm stumped as to what to look for...is there a magical number or????
I've been scanning thru the Sys Admin, Sys Setup Guide and App Program Reference.
MQ Version is 5.3 running on z/OS. |
|
| Back to top |
|
 |
| oz1ccg |
| Posted: Wed Jan 14, 2004 2:09 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
What trigger monitor are you using ?? CICS or BATCH.
second, your application is that designed to take only of messages that are on the queue when it's started ??
MQ don't care about how many messages an application is reading. All MQ can take care of is generate an trigger message (if requirements are met).
third, why using depth ?? Personally I think depth and every only causes trouble, on understanding how it's working, and on how to develop stable applications. It's even difficult to understand when a trigger event is generated, and how to be shure that no messages stays too long sitting in the queue.
I'll look forward to hear your comment.
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| offshore |
| Posted: Thu Jan 15, 2004 3:55 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
OZ,
Using CKTI trigger monitor. So far there hasn't been any problem using the depth trigger attribute.
Well, the problem was in the application itself, which is where I figured.
As I was looking through the program (Cobol). The applications people told me they were doing a compare against the trigger count and against a counter in the program. The counter in the program was only set to 4 fields...so after 9999 it went to 0001. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jan 15, 2004 5:52 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| offshore wrote: |
| As I was looking through the program (Cobol). The applications people told me they were doing a compare against the trigger count and against a counter in the program. The counter in the program was only set to 4 fields...so after 9999 it went to 0001. |
Changing the field width for this counter won't change the fact that the logic in the program is still "incorrect" (at least in my opinion).
The "best practices" way of doing this is to loop until you get an 2033 return code (no more messages).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jan 15, 2004 8:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
To further on Jeff's point:
Any triggered app, whether it is triggered on firts, on every or by depth, should be coded to read messages until it gets a 2033 error. Not doing it this way is a 100% sure way of running into problems. Guaranteed.
Any triggered app should be able to handle getting a 2033 even on the very first read of the queue without bombing.
Can you explain why you are waiting until there are 10,000 messages in the queue? What would happen to your application if only 9999 arrived for some reason and you never got triggered?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| offshore |
| Posted: Fri Jan 16, 2004 4:11 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
I haven't a clue why they don't get all the messages off the queue at trigger time. I can understand your point and to be honest I thought the applications people did get all the messages off the queue.
I don't think I have the authority, since I'm in systems programming, to tell them to take the trigger count to message count compare out of the program.
I could possibly recommend it and see if there is any reasoning not too.
The only issue I could see that queue is constantaly getting populated. I suppose there is the chance the program could run forever if it couldn't keep up????
I know the program can handle the 2033 message.
What has me puzzled is this program runs throughout the day when triggered, but also is scheduled at night to run by a scheduler. At night the program does get all the messages off the queue? I don't know how that is possible. Its the same program except its executed by a scheduler instead of a trigger. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Fri Jan 16, 2004 4:52 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
If the program is designed to be started from native CICS also (if the EXEC CICS RETRIEVE fails), it can be started thru a modify command send to the CICS (newer CICS versions). I have customers starting transactions "direcly" from OPC.....
Yes allmost anything is possible.
I'll backup on Peter about design MQ apps. When started they have to continue until rc=2033. Anything else will require a service to handle "forgotten" messages.....
I'll recoment that your developers study the APG, 2,5 inch of tuff reading, but anyway the authors have put some thoughts in there with regard to Triggered applications design.
(50-75% of my time is spend supporting developers telling whats in APG... )
Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| offshore |
| Posted: Fri Jan 16, 2004 7:59 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
oz,
yes...i spend alot of my time with applications programmers. i've spent my share of time looking through the APG, not as much as you evidently do but....
oh well...that could turn into a whole other thread.
thanks everyone for the replies!!!!!!! |
|
| Back to top |
|
|
|
|
