| Author |
Message
|
| WBI_user |
 Posted: Wed Jun 01, 2011 8:08 pm Post subject: Trigger every on shared queue |
 |
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
| We have two ZOS lpars running MQ V7. Each LPAR runs a CKTI against a shared INITQ. An application Q (also shared queue) is set up for trigger on every to start a transaction ABCD. We put messages to the shared application queue at a rate of about 200 msg/sec. We have a monitoing program counting the number of transactions started. For trigger on every, we expect the number of transactions ABCD started by the two CKTI to be equal to the number of messages arriving onto the queue (i.e about 200 starts per sec). However our monitoring program is counting a lot less (only about 100 ABCD started in a minute interval). My experience with trigger on every on the V6 distributed platform is the trigger monitor will start the specified process for every message arriving on the queue. It does not care if some application is already open the queue for input. This is also how the manual describes it. Is that also true for Shared Queue on ZOS? Is there anything that changed the behavior in V7 ? If my understanding is correct, any idea what can cause the result that we observed ? One possible reason could be something wrong with our monitoring program. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Jun 02, 2011 5:48 am Post subject: Re: Trigger every on shared queue |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| WBI_user wrote: |
| We have a monitoing program counting the number of transactions started. For trigger on every, we expect the number of transactions ABCD started by the two CKTI to be equal to the number of messages arriving onto the queue (i.e about 200 starts per sec). However our monitoring program is counting a lot less (only about 100 ABCD started in a minute interval). |
Trigtype(every) puts a trigger message to the initiation queue for each message put to the application queue. It does not ensure that the exact same number of triggered apps are launched. Your CICS folks may have set limits on the number of ABCDs that can exist concurrently.
_________________
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 |
|
|
| mqjeff |
| Posted: Thu Jun 02, 2011 5:50 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| also, even if the trigger monitor puts all 200 messages on the shared INITQ and CICS starts all 200 transactions, there's no guarantee about which trigger monitor process will read the init message. So you may see 1 transaction on one LPAR and 199 on the other, depending on a variety of factors. |
|
| Back to top |
|
|
| WBI_user |
| Posted: Thu Jun 02, 2011 7:31 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
| Thanks for the response. Knowing that my understanding of trigger on every is correct for ZOS Shared queue, I can go after the CICS person to get to the bottom of it. By the way , I was told that the monitoring program is getting statistics from TMON (I beleive is now an IBM tool). The total ABCD started was the sum of the two LPARS. I am not familiar with the tool. I assume that the number they reported is correct. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 02, 2011 8:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Read note 1 at the bottom:
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzal.doc/fg13860_.htm
Also, are you using the same monitoring software to see what MQ reports on the # of messages that pass thru this queue? Is that # less than the # of messages you know are going thru?
Are your triggered apps only doing 1 get and done? Or do they go back to the queue to see if there is anything else before ending?
Where do you get the 200 per second number from?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| WBI_user |
| Posted: Thu Jun 02, 2011 11:48 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
Hi PeterPotkay, thanks for the response. This test was done in part of our stress testing exercise for some prototype applications. The driver tool is putting 200 msg.sec into the queue. This is where the 200 comes from. In real life, we probably will not be starting 200 tarnsactions per sec.
The note 1 in the link you refer to (the info center) talks about "where trigger messages are generated as a result of some event other than a message arriving on the application queue". I thnik it is not applicable here (correct me if I am wrong). The triggered transaction ABCD will open the queue for browsing and start another transaction to get the message off the queue (this may be a bad design. but I did not write the application). So the queue may be opened for Input by other applciations. But this should not affect trigger on every. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 02, 2011 12:50 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I'm not (yet) convinced that 200 messages a second are going thru this shared queue.
I would want MQ statistics, directly from the mainframe queue managers hosting this shared queue, on the number of messages actually going thru that shared queue, and I would then compare that number to the number of times the transactions are kicked off. I would also turn on MQ statistics for the Initiation Queue to see exactly how many trigger messages are being generated per second.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 02, 2011 1:44 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| WBI_user wrote: |
| The note 1 in the link you refer to (the info center) talks about "where trigger messages are generated as a result of some event other than a message arriving on the application queue". I thnik it is not applicable here (correct me if I am wrong). |
Wrong about what? There is no way for me/us to know how the transaction is written - to know if you are right or wrong.
"some event other ..." could be
1) messages put to a queue within a unit of work will NOT generate a trigger unitl the UofW is committed;
2) the qmgr recognizes that it missed firing a trigger (see triggerinterval qmgr attribute) when it was last supposed to do so;
3) when the qmgr restarts, and recognizes that there are already messages present in a triggered queue.
_________________
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 |
|
|
| WBI_user |
| Posted: Fri Jun 03, 2011 4:27 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
| I am just rying to understand the exact behaviour of trigger on every on a shared queue. The investigation is just started. I understand that there is a lot more digging and verification that needs to be done. In our case, it is a simple driver application putting messages on the shared queue. Yes, I'll confirm with MQ statistics the actual message arrival rate. The driver application reports 200 msg/sec. That's what we started to use to compare with TMON results. I read through the trigger condition pages in the info center a few times, the is not much details on trigger every (most conditions described are under trigger type first and depth). That what make me think that I should see the number of triggered ABCD equal to the number of messages put to the queue. I undertsand that trigger for shared queue only counts committed emssages. Once the commit takes place, triggering should start. If it commits 200 messages, I should see 200 triggerred ABCD. 'other events' may be affecting the number of triggered message generated but should that only be generating additional trigger message ? During the time of measurement, there is no special events such as restart of qmgr. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 03, 2011 6:45 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| WBI_user wrote: |
| I am just rying to understand the exact behaviour of trigger on every on a shared queue. The investigation is just started. I understand that there is a lot more digging and verification that needs to be done. In our case, it is a simple driver application putting messages on the shared queue. Yes, I'll confirm with MQ statistics the actual message arrival rate. The driver application reports 200 msg/sec. That's what we started to use to compare with TMON results. I read through the trigger condition pages in the info center a few times, the is not much details on trigger every (most conditions described are under trigger type first and depth). That what make me think that I should see the number of triggered ABCD equal to the number of messages put to the queue. I undertsand that trigger for shared queue only counts committed emssages. Once the commit takes place, triggering should start. If it commits 200 messages, I should see 200 triggerred ABCD. 'other events' may be affecting the number of triggered message generated but should that only be generating additional trigger message ? During the time of measurement, there is no special events such as restart of qmgr. |
Please create new paragraphs from time-to-time.
| WBI_user wrote: |
| I undertsand that trigger for shared queue only counts committed emssages. |
This applies to all triggered queues, not just shared.
What you really need to test (validate/verify) is: whether or not the application messages put to the (shared) queue are being consumed by the (triggered) application. If they are, then you have no issue to resolve. If application messages are not being consumed, then you might have a triggering issue.
_________________
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 |
|
|
| WBI_user |
| Posted: Fri Jun 03, 2011 8:36 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
bruce said "This applies to all triggered queues, not just shared"
However info center http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
says under note 1 "Note:
The queue manager counts both committed and uncommitted messages when it assesses whether the conditions for a trigger event exist. ...."
under note 2 it says
"For local shared queues (that is, shared queues in a queue-sharing group) the queue manager counts committed messages only.
" |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 03, 2011 8:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| WBI_user wrote: |
bruce said "This applies to all triggered queues, not just shared"
However info center http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
says under note 1 "Note:
The queue manager counts both committed and uncommitted messages when it assesses whether the conditions for a trigger event exist. ...."
under note 2 it says
"For local shared queues (that is, shared queues in a queue-sharing group) the queue manager counts committed messages only.
" |
What exactly is your point here? Are messages put to the shared queue being consumed? OR NOT? If they are being consumed, why is it important to you how many trigger messages were created?
_________________
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 |
|
|
| WBI_user |
| Posted: Fri Jun 03, 2011 9:24 am Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
| My apology if I offended anyone. I agreed that as long as the message is getting consumed, why should I care how many tirggered message are generated. I am just a technical guy that always want to know exactly how it works. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 03, 2011 9:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| WBI_user wrote: |
bruce said "This applies to all triggered queues, not just shared"
However info center http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
says under note 1 "Note:
The queue manager counts both committed and uncommitted messages when it assesses whether the conditions for a trigger event exist. ...."
under note 2 it says
"For local shared queues (that is, shared queues in a queue-sharing group) the queue manager counts committed messages only.
" |
Not offended; just wondering why you see this as something that need to be resolved.
The InfoCenter quote "The queue manager counts both committed and uncommitted messages when it assesses whether the conditions for a trigger event exist. ...." does not contradict. Triggering software needs to recognize that (account for) messages put in UofWs (uncommitted) do not yet meet triggering requirements - but will soon. Uncommitted messages do not cause triggers to fire.
The InfoCenter quote ""For local shared queues (that is, shared queues in a queue-sharing group) the queue manager counts committed messages only. " also does not contradict. I'm speculating that since there will likely be multiple trigger monitor apps across multiple WMQ instances watching the shared initiation queue, that keeping track (count) of not-yet-committed messages is a waste of horsepower. This seems to make sense.
I'm not entirely sure why IBM doc makes this (type of) distinction without a difference, but it often does.
_________________
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 |
|
|
|
|
