| Author |
Message
|
| giuly020277 |
 Posted: Wed Dec 19, 2007 1:31 am Post subject: queue with trigger first and message at cics startup |
 |
|
Centurion
Joined: 07 Aug 2007
Posts: 146
Location: Florence,Italy
|
hello everyone,
i need your help to save my job 
I just ask abiut it some questions ago...but..as u suggest...we didn't find a solution.
I repeat my problem.
Sun solaris send message on my queue (local queue with trigger =first )on z/os when cics is down.when cics start...ckti see that there are some messages on queue and let process cics ( that is transaction TMAT) start.
The problem is :
When i have only 1 message on queue ...at cics startup all go right.
When i have more than 1 messages...tmat start but does nothing....it doesn't update database.
In my opinion it's an application error.... program can't manage more than one message on queue.
What can i do to discover error?programmers tell it is ok....
Thank u all |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Dec 19, 2007 1:53 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
What is the program logic of the TMAT transaction?
If it does not read the queue until empty you would need to use trigger EVERY.
It might be a programming error, relating to syncpoints perhaps? |
|
| Back to top |
|
|
| giuly020277 |
| Posted: Wed Dec 19, 2007 2:02 am Post subject: |
|
|
Centurion
Joined: 07 Aug 2007
Posts: 146
Location: Florence,Italy
|
I don't know zpat..
I'm not a programmer....i only manage mq series on z/os.
I think it's a programmer error too...but i have to find the error...if not i will be the guilty (i like this way to work...isn't it? )
However...i know that program SHOULD manage first message on queue and then the other...until it found no message on queue.
syncpoints?i don't know...i have to search something in that program?
if u like i can show u program...but it's long...:s |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 19, 2007 3:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If you've got an existing thread, it's better to quote it - saves us repeating ourselves. I think you mean this one:
http://www.mqseries.net/phpBB2/viewtopic.php?p=197457&highlight=#197457
What you should do is a) tell us what investigations you performed as a result of this earlier thread & what the results were (you never answered the last question) and b) get the programmers to tell you how their syncpoint handling works. If by your own admission you're not a programmer searching through the code is not going to get you anywhere because you won't understand what you're looking at. Like me with a piece of Java.
Likewise get them to explain the logic in the transaction. If you're that worried about your job, get them (or the sys progs) to produce a small test transaction and demonstrate that works as expected. This will push the onus back onto the failing transaction.
Simple. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 19, 2007 4:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
If the transaction is not "tclassed" to restrict its resource consumption and trigger is every you may be in trouble at the start of CICS.
The other thing you might want to check is that CICS is not started before all of its resources are... so that the DB is truly available at the start of the transaction.
In order to fix this problem you will probably need to cooperation of a senior CICS programer, possibly a SYSTEM programer and the MQ Admin...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 19, 2007 7:10 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| zpat wrote: |
| If it does not read the queue until empty you would need to use trigger EVERY. |
Perhaps counterintuitive, but if an app only reads one message and ends (which we know is bad), then FIRST is much better then EVERY.
With Trigger FIRST, every time the app closes the q and there are more messages on the q the app will be retriggered until the q is emptied one message at a time. If we somehow find ourselves with more than 0 messages on the q and the q never got opened to drive the above logic, then Trigger Interval will save us. Trigger Interval only applies to FIRST.
Conversely if an EVERY queue finds itself with 1 or more messages the next time a trigger condition is met one and only one trigger message will be generated. The badly written app will consume just one message while leaving a rolling backlog of application messages. Only manual intervention can recover at this point.
Triggered apps should ALWAYS loop on the q reading until 2033, while being able to gracefully handle a 2033 even if that's the first result they get. But if for some reason they can only read one and done, better to use Trigger Type First.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Dec 20, 2007 12:11 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
| PeterPotkay wrote: |
| zpat wrote: |
| If it does not read the queue until empty you would need to use trigger EVERY. |
With Trigger FIRST, every time the app closes the q and there are more messages on the q the app will be retriggered until the q is emptied one message at a time. |
Really? I always thought it was only when the queue depth went from 0 to 1.
| Quote: |
| FIRST. A trigger event occurs only when the number of messages on the application queue changes from zero to one. Use this type of trigger if you want a serving program to start when the first message arrives on a queue, continue until there are no more messages to process, then end. |
|
|
| Back to top |
|
|
| bob_buxton |
| Posted: Thu Dec 20, 2007 12:23 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| PeterPotkay wrote: |
Perhaps counterintuitive, but if an app only reads one message and ends (which we know is bad), then FIRST is much better then EVERY.
|
If you are committed to use the one transaction per message model you should use trigger first and close the input queue immediately after getting the message.
MQOPEN input
MQGET
MQCLOSE
process message
MQPUT1 reply
exit
This will allow MQ to trigger another instance of your transaction whilst it is still processing the first message, this is especially beneficial if the message processing is relatively slow.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Dec 20, 2007 12:47 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
The trouble with trigger FIRST is that at some point you will have a situation where a backlog of messages has built up and is not being processed (triggered) since the queue depth is greater than one.
This can happen when messages arrive when the CICS region is down for example. Triggering is a production nightmare, and best avoided (IMHO). It's a hugely over-rated feature of MQ.
Long running tasks are much better and lend themselves to load-balancing both inside one CICS region and over several CICS regions. We ended up with a sort of hybrid using long-running tasks to start other transactions under different RACF ids (but NOT with initiation queue overhead). |
|
| Back to top |
|
|
| giuly020277 |
| Posted: Thu Dec 20, 2007 2:30 am Post subject: |
|
|
Centurion
Joined: 07 Aug 2007
Posts: 146
Location: Florence,Italy
|
Hello everyone,
maybe we found the solution (and error too).
(i nedd a bottle of champagne).
Maybe (i'm almost sure of this...but i need to proove it again)...sun programmers have inserted a too low value of the expiration massege field.
Instaed of make this time unlimited...i have seen they have the value = 600.
I think message expire when cics is down...while when cics is up...this message let start process in a while.ù
What do u think??
I have to wait to close cics and proove it...i will let u know.. |
|
| Back to top |
|
|
| giuly020277 |
| Posted: Thu Dec 20, 2007 5:26 am Post subject: |
|
|
Centurion
Joined: 07 Aug 2007
Posts: 146
Location: Florence,Italy
|
....i have done the proove. The problem was that Sun Solaris programmer in his program had mq.expity field not equal to UNLIMITED...
I want to say thank u to all for your help..
Ciao from Italy... |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 20, 2007 5:43 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| zpat wrote: |
| PeterPotkay wrote: |
| zpat wrote: |
| If it does not read the queue until empty you would need to use trigger EVERY. |
With Trigger FIRST, every time the app closes the q and there are more messages on the q the app will be retriggered until the q is emptied one message at a time. |
Really? I always thought it was only when the queue depth went from 0 to 1.
| Quote: |
| FIRST. A trigger event occurs only when the number of messages on the application queue changes from zero to one. Use this type of trigger if you want a serving program to start when the first message arrives on a queue, continue until there are no more messages to process, then end. |
|
Really. 
| Quote: |
12. The only application serving a queue issues an MQCLOSE call, for a TriggerType of MQTT_FIRST or MQTT_DEPTH, and there is at least:
One (MQTT_FIRST), or TriggerDepth (MQTT_DEPTH)
messages on the queue of sufficient priority (condition 2), and conditions 6 through 10 are also satisfied.
This is to allow for a queue server that issues an MQGET call, finds the queue empty, and so ends; however, in the interval between the MQGET and the MQCLOSE calls, one or more messages arrive.
Note:
If the program serving the application queue does not retrieve all the messages, this can cause a closed loop. Each time that the program closes the queue, the queue manager creates another trigger message that causes the trigger monitor to start the server program again.
If the program serving the application queue backs out its get request (or if the program abends) before it closes the queue, the same happens. However, if the program closes the queue before backing out the get request, and the queue is otherwise empty, no trigger message is created.
To prevent such a loop occurring, use the BackoutCount field of MQMD to detect messages that are repeatedly backed out. For more information, see Messages that are backed out.
|
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzal.doc/fg13830_.htm
This feature and the benefits of Trigger Interval mean you should use Trigger On First almost always. Its a rare case where Depth or Every are the correct solution, although they are available for a reason.
Trigger On Group (trigger only when all the messages of a group are on the q), now THERE is a trigger type that could be more useful than Every in my opinion.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 20, 2007 5:45 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
| zpat wrote: |
The trouble with trigger FIRST is that at some point you will have a situation where a backlog of messages has built up and is not being processed (triggered) since the queue depth is greater than one.
This can happen when messages arrive when the CICS region is down for example. Triggering is a production nightmare, and best avoided (IMHO). It's a hugely over-rated feature of MQ.
|
Trigger Every WILL lead to rolling backlogs of application messages. Coupled with an app that only reads one and done I can see it being a nightmare.
Trigger On First WITH Trigger Interval manages itself and is just about perfect, even if the app is coded wrong (get one and done).
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 21, 2007 5:11 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Peter,
What would you suggest if the messages are sporadic (not a long running task) but in order to meet your SLA you need more than one instance to process ?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 21, 2007 10:30 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Trigger Every and make sure the app reads until 2033. That opinion is purely from an MQ perspective. I am not an expert on CICS or IMS so I'll make the big assumption that running multiple transactions concurrently won't be an issue and something in IMS / CICS will be able to handle / throttle it if 1000 messages land on the Triggered Every Q all at once. In that case your SLA is blown no matter what, but in that case you've exceeded what you designed / planned for anyway.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
