| Author |
Message
|
| WBI_user |
 Posted: Sun May 30, 2010 10:05 am Post subject: help on Workload distribution using MQ triggering |
 |
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
We have a sysplex of 2 ZOS each with a QMGR running. Each ZOS also 2 CICS regions. There is a shared queue which we like the messages in it to be processed by the 4 CICS regions evenly. The CICS transactions need to be started by MQ triggering. So we will have CKTI running on each CICS region.
Our first plan is to use a shared initq.
Please correct me if I am wrong. I think this is what will happen.
If we set up the Application Q (APPQ) with trigger on first. When a message is put to the APPQ, 2 trigger messages (one from each QMGR) will be generated. The 4 CKTIs will be competing for the trigger message. Two of them will get the message and start the CICS transaction. Then the APPQ will be opened for Input. Then there will not be further trigger message generated until APPQ curdepth goes from 0 to one again and this will repeat. This will mean that only two out of the 4 regions will be processing messages all the time. Am I right.
Then we think of using trigger every in the hope that more trigger messages will be generated and picked up by the other 2 CKTIs . But the documentation ( MQ application programming guide) says that "For shared queues, special conditions apply when multiple queue managers have trigger monitors running against a queue. In this situation, if one or more queue managers have the queue open for input shared, the trigger criteria on the other queue managers are treated as TriggerType MQTT_FIRST and TriggerMsgPriority zero." If this is right (i.e the Trigger type is treated as trigtype first), then no further trigger message will be generated because the APPQ is already opened by the first two transaction triggered.
Do I read the manual correctly ? If so, I need some help on how we can have the messages on APPQ handled evenly by the 4 CICS regions. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Sun May 30, 2010 10:17 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Depending on the volume you get you might think about running the processing of the queue as a started task in CICS 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Sun May 30, 2010 12:15 pm Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
You understanding of trigger first is correct.
Trigger Every is seldom the correct answer for any triggering problem, it has very high overheads (put and get of a trigger message for every data message) and does not work in the way most users need or expect.
To start a transaction in each region you could set your triggered transaction to be a starter transaction whose purpose is to start instances of your processing transaction in each of the CICS regions.
For extra sophistication the starter transaction could periodically monitor the queue depth and if it is increasing start additional instances of the processing transaction.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun May 30, 2010 12:16 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
You have explained what you want to accomplish (messages distributed evenly). But you didn't explain why?
One of the advantages of a sysplex, it its natural pull-workload balancing - the z/OS image with the most resources (horsepower) will get to the appq ahead of the images with lesser resources. Why do you want to upset this normal balance?
_________________
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: Sun May 30, 2010 8:53 pm Post subject: |
|
|
Partisan
Joined: 07 Aug 2001
Posts: 386
|
We are trying to build a model which can handle a very large volume of messages. At this time is mostly understnading what we can do with a lot of assumptions which most likely need to be adjusted at real oerformance testing time. At this time, we can assuming that both ZOS has equal resources and so are all CICS regions. So, we think, the ideal situation will be evenly distributing the message processing across the 4 CICS regions until they max out, Then we can add regions as needed or even add ZOSs to the sysplex as volume increases. We understand that in real situation, ZOS sysplex workload balancing will probably distribute works to the two ZOS according to its logic resulting in message processing not evenly distributed between the 4 regions.
If I understand the answers so far correctly, just MQ triggering (even using trigger on every) cannot get work start on all 4 regions. I need trigger start a transaction which in turn start transactions in other AORs. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon May 31, 2010 5:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Like I said, you might want to forgo MQ triggering entirely and instead use the CICS started task...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 31, 2010 6:34 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If I understand the answers so far correctly, just MQ triggering (even using trigger on every) cannot get work start on all 4 regions. I need trigger start a transaction which in turn start transactions in other AORs. |
While I understand that this is a mental exercise, distributing messages with absolute precision so that each cics gets one and only one message (round-robin) circumvents what WLM tries to accomplish, namely: ensuring that workloads meet your organizations business GOALS.
Let me ask this in a different way. What issues/concerns do you have with WLM managing your workload?
_________________
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 |
|
|
| bob_buxton |
| Posted: Mon May 31, 2010 7:43 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
As I understand it the goal is to get all four CICS regions participating in Pull work load balancing not necessarily to achieve exact equality of workload in each region.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 31, 2010 8:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bob_buxton wrote: |
| As I understand it the goal is to get all four CICS regions participating in Pull work load balancing not necessarily to achieve exact equality of workload in each region. |
And, despite not being a zOS/CICS person, I wonder if merely not using a *shared* initq will solve the problem....
Won't using a non-shared initq cause each qmgr to generate a trigger message on it's own local initq, each time a message gets put on the (shared) trigger queue?
It means that both regions will be competing for each message on the queue, but that's probably not entirely a bad thing. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 31, 2010 11:01 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
From the OP:
| Quote: |
| So, we think, the ideal situation will be evenly distributing the message processing across the 4 CICS regions until they max out, Then we can add regions as needed or even add ZOSs to the sysplex as volume increases. We understand that in real situation, ZOS sysplex workload balancing will probably distribute works to the two ZOS according to its logic resulting in message processing not evenly distributed between the 4 regions. |
Why do you understand this to be the case with WLM?
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Jun 01, 2010 5:30 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Are CICS transactions are MQ-aware or not?
WebSphere MQ in a z/OS Parallel Sysplex Environment, available at http://www.redbooks.ibm.com/redbooks/pdfs/sg246864.pdf , is a good source of information on (what I believe) you are attempting.
A shared initiation queue with TRIGTYPE=EVERY seems to solve the workload issue for you.
_________________
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 |
|
|
|
|
