| Author |
Message
|
| shlomoe |
 Posted: Tue Mar 11, 2008 2:16 am Post subject: Trigger first issue in sysplex environment |
 |
|
Newbie
Joined: 11 Mar 2003
Posts: 7
|
Hello all,
Environment details:
Z/OS 1.7
WMQ V6
CICS/TS 2.3
Background:
In a mf qmgr (single lpar no sysplex) we have a local queue with trigger first defined.
When the first message arrives a cics transaction is started.
The transaction destructively gets a single message and after handling it,
the transaction ends.
If there are messages in the queue when the mqclose is issued by the transaction,
another trigger event is created automatically and another transaction reads a single message and so forth (as documented in APG under conditions for a trigger event condition no. 12).
In any given moment there is not more then one active task processing the queue.
This is critical because we have to process the messages in there arrival order.
This works fine in a single lpar env.
Our issue :
We are moving to a sysplex environment (with two lpars) and we should maintain this behaviour cross lpars.
We defined a shared queue with trigger first (the initq is also defined shared).
We expected that no more then one task will be active in parallel, cross lpars.
From tests we made that’s not the case.
We get tasks running in parallel both in the same lpar and cross lpars.
I would appreciate your opinion, is there any way to maintain
the desired behaviour cross lpars ?
TIA,
SHLOMO. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Mar 11, 2008 3:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What's the point of running the same task in parallel LPARs if you want to only run the task in a single fashion?
I mean, I'm confused as to why you implemented the same trigger and same task in the other qmgr or even shared the queue in the sysplex in the first place, if you wanted to make sure that there was only ever one transaction processing messages.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 11, 2008 3:51 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
From tests we made that’s not the case.
We get tasks running in parallel both in the same lpar and cross lpars. |
If you are using trigger first you should not be getting multiple invocations of the same transaction FROM MQ.
Of course if you transaction is not tclassed 1 you can get other CICS invocations for this transaction... possibly from other triggered queues??
As for the across lpar problems have you tried opening the queue in exclusive mode?
What I don't get personally is why you would design the whole thing to be dependent on message affinity and not be scalable!!
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Tue Mar 11, 2008 5:27 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| fjb_saper wrote: |
If you are using trigger first you should not be getting multiple invocations of the same transaction FROM MQ.
As for the across lpar problems have you tried opening the queue in exclusive mode?
What I don't get personally is why you would design the whole thing to be dependent on message affinity and not be scalable!!
Enjoy |
In a shared queue environment each queue manager with an active trigger monitor will generate a trigger message. This allows you to get workload balancing across the sysplex.
Opening the queue exclusive is the simplest way to ensure single active task.
It is not clear why the OP requires single message processing in task, this results in extra triggering overhead.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| shlomoe |
| Posted: Tue Mar 11, 2008 5:28 am Post subject: |
|
|
Newbie
Joined: 11 Mar 2003
Posts: 7
|
| Quote: |
| What's the point of running the same task in parallel LPARs if you want to only run the task in a single fashion? |
We want the application to function in either lpar available.
| Quote: |
What I don't get personally is why you would design the whole thing to be dependent on message affinity and not be scalable!!
|
It’s a legacy application which is not under our control.
Again we need to keep the application working in the same manner,
meaning one task for the whole plex.
We get multiple invocations though we shouldn’t. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 11, 2008 5:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| shlomoe wrote: |
| Quote: |
| What's the point of running the same task in parallel LPARs if you want to only run the task in a single fashion? |
We want the application to function in either lpar available. |
That's what you've got. It's not what you want. What you want is for the application to function in one LPAR, whichever one is available.
| Quote: |
| We get multiple invocations though we shouldn’t. |
It's a confusion of how things work that has caused you to believe that you shouldn't be seeing the behavior you are seeing.
Don't run the trigger monitor on both LPARS at the same time. Or control which LPAR the trigger monitor can start the task from.
I don't think that there is any means in CICS of having one CICS region control whether or not a given task in another CICS region is allowed to start or not. I'll defer to experts on that point.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 11, 2008 5:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I don't know the answer (haven't had the chance to play with shared triggered queues yet), but if the triggered q is shared, and the init q is shared, doesn't the QM stil only produce 1 trigger message and so only 1 CICS app in 1 LPAR will get triggered?
I can see why he wants this. If only 1 gets triggered who cares which LPAR actually gets it, but if 1 LPAR dies, the remaining one can do all the work with no changes required.
Maybe you are only getting 1 trigger message and only 1 CICS app is getting triggered at time. But its happening so fast between both sides that to the human eye it looks like both are going at the same time?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| shlomoe |
| Posted: Tue Mar 11, 2008 6:08 am Post subject: |
|
|
Newbie
Joined: 11 Mar 2003
Posts: 7
|
Peter, that's just what we need !
Only for our tests we added a delay
and where able to monitor tasks running in parallel.
Regards,
SHLOMO. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 11, 2008 6:09 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| I don't know the answer (haven't had the chance to play with shared triggered queues yet), but if the triggered q is shared, and the init q is shared, doesn't the QM stil only produce 1 trigger message and so only 1 CICS app in 1 LPAR will get triggered? |
| bob_buxton wrote: |
| In a shared queue environment each queue manager with an active trigger monitor will generate a trigger message. |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 11, 2008 8:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
aha. As Bob was replying I was digging in the manuals.
Deciding whether to share non-application queues
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzal.doc/fg15390_.htm
| Quote: |
Initiation queues
If you define a shared initiation queue, you do not need to have a trigger monitor running on every queue manager in the queue-sharing group, as long as there is at least one trigger monitor running. (You can also use a shared initiation queue even if there is a trigger monitor running on each queue manager in the queue-sharing group.)
If you have a shared application queue and use the trigger type of EVERY (or a trigger type of FIRST with a small trigger interval, which behaves like a trigger type of EVERY) your initiation queue must always be a shared queue. For more information about when to use a shared initiation queue, see Table 1.
|
Table 1 is found here:
Migrating your existing applications to use shared queues
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzal.doc/fg15400_.htm
If the INITQ is shared:
| Quote: |
For trigger type FIRST or DEPTH, one trigger message is generated by each queue manager that has the named initiation queue open for input.
|
If the INITQ is not shared:
| Quote: |
If you use a trigger type of FIRST or DEPTH, you can use a non-shared initiation queue with a shared application queue. Extra trigger messages might be generated, but this setup is good for triggering long-running applications (like the CICS® bridge) and provides high availability.
For trigger type FIRST or DEPTH, a trigger message triggers an instance of the application on every queue manager that is running a trigger monitor and that does not already have the application queue open for input. One trigger message is generated for every queue manager; if there is more than one trigger monitor running against the non-shared local initiation queue, on a given queue manager, they will compete to process the message.
|
I don't get the difference between sharing and not sharing the INITQ for Trigger On First apps. In both cases you get 1 trigger message for each QM that has the INITQ open. 
They also say you can run with only 1 trigger monitor on only one QM in the QSG. But does that then limit the app to only be triggered on that one QM?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Mar 11, 2008 9:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| I don't get the difference between sharing and not sharing the INITQ for Trigger On First apps. In both cases you get 1 trigger message for each QM that has the INITQ open. |
No, it says that you get 1 trigger message for each QM that has the INITQ open AND *does not have* the app queue open. This is a subset of "each QM that has the INITQ open".
It still doesn't solve schlomoe's problem - as this would still trigger "the wrong" QM. I think schlomoe has to either code the transaction to use OPEN_EXCLUSIVE and fail *silently* if it can't, or ensure that the trigger monitor is only running in one region at a time.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 11, 2008 9:19 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Actually, technically, that sentence says nothing about the generation of the trigger messages.
| Quote: |
| For trigger type FIRST or DEPTH, a trigger message triggers an instance of the application on every queue manager that is running a trigger monitor and that does not already have the application queue open for input. |
It says a trigger message will trigger the app only if the QM has a triger monitor and the q is not open. But apperently the trigger message is generated regardless of whether the app q is open or not????
Look again and you will see that for both shared and non shared INITQs there is a trigger message generated for each QM that has the INITQ open. Then apparently based on the disposition of the INITQ it determines how that trigger message is treated by the triger monitor? If not shared it only starts up the app if the app q is not open, but if the INITQ is shared, the behaviour is <not defined here, so I assume it will start the app regardless>
I thought I knew triggering cold, but this links in the info center got me confused how it works in a QSG.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 11, 2008 4:03 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Do we really care?
I thought that shared queue or not the message is only gettable by one side and will only be processed by one side.
No more message on queue one side processes the other goes empty.
Multiple messages on queue. Each message gets processed by one side only... You just cannot tell which until it happens...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 11, 2008 4:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| Do we really care? |
Reminds me of a guy that used to sit a few aisles over from me. Every few days we would hear him yell "I don't care what's wrong just fix it, man!!!" 
When things are working smoothly, yeah, who cares what's happening. But I would like to know exactly what the deal is here so when things go wrong I have the info needed to be able to conclusively blame the apps. 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Mar 11, 2008 8:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well, let's think about this for a second. He states that he sees both sides processing the message. He did not give any indication as to redelivery count or poison message handling.
I'd lean towards working as designed.
The first app that tried to process the message could not and rolled it back to the queue. That's when the second app picked up the message and processed it.
Could it be possible that one vital resource is only linked to one side?
Any transaction abends? Any dumps?
Working as designed ??
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
