| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Trigger Interval with Shared Queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Thu Dec 06, 2012 9:28 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
You are over-thinking this.
CICS deployment in a Parallel Sysplex expects there to be multiple CICSs, multiple trigger monitors, and that will each trigger monitor will see the trigger message, and that each will start the application.
Whichever CICS application gets the application message will be the one CICS that processes the application message. All other applications will get a 2033, and (if the program is coded well), will GET+WAIT for the next app message. Thus, the CICSs compete (cooperate) for the next app message that arrives.
You need do nothing to facilitate workload balancing. Competing CICSs will do much of it thru natural pull-workload balancing. Otherwise, let WLM manage workload.
Read the table here http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=%2Fcom.ibm.mq.csqzal.doc%2Ffg15400_.htm
_________________
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 |
|
 |
| CharlieChen |
| Posted: Fri Dec 07, 2012 1:02 am Post subject: |
|
|
Novice
Joined: 24 Jun 2012
Posts: 15
|
Hi Bruce
Actually, we are both referring to the same section in the manual ! ha ha..
Quote the URL, "For trigger type FIRST or DEPTH, one trigger message is generated by each queue manager that has the named initiation queue open for input." I am wondering if I have 2 CICSes reading the same shared initq, when a Trigger First occur, it says 1 trigger message is generated by each queue manager (meaning 2 trigger message generated)... these trigger message will be put in the shared initq, right ? So it's possible that the 2 trigger message is consumed by CICSA trigger monitor ? If that is the case, how does MQ ensure that both CICSA and CICSB are trigger instead of CICSA get trigger twice while CICSB didn't get any ? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 07, 2012 6:13 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9405
Location: US: west coast, almost. Otherwise, enroute.
|
| CharlieChen wrote: |
| ...how does MQ ensure that both CICSA and CICSB are trigger instead of CICSA get trigger twice while CICSB didn't get any ? |
MQ does nothing to ensure workload balancing or workload distribution. Nor does it prevent either. One qmgr has no knowledge of other qmgrs in the sysplex. Each operates independently of the others.
Let's suppose that one consumer CICS is running on a blisteringly-fast processor, and the other is on a very slow processor. The faster CICSs trigger monitor will naturally pull more workload - because it has the horsepower to do so.
Your prior post mentioned that the app will wait 60 seconds. I presume that you mean MQGET with WAIT option, yes? The wait will end immediately when the next message arrives.
_________________
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 |
|
|
| elkinsc |
| Posted: Mon Dec 10, 2012 8:22 am Post subject: So many factors |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
Bruce is right, MQ is just a delivery mechanism. There is no mechanism to prevent favoritism currently. Please keep in mind there are many, many factors that influence the distribution of workload (who gets the message, who gets triggered) in a QSG:
1) Put to waiting getters can really skew the balance in spite of faster processors on other LPARs.
2) The plex configuration including:
a) the physical location of the CF
b) link type (infiniband vs others)
c) number of links to the CF
d) CF processor type
e) Asymmetrical sysplex - faster processors on one or more CECs
3) Applications:
a) Triggering type
b) Duration of the wait periods,
c) and the ugliest of all - other resource contention
I have reviewed SMF116 data until my eyes are crusted over, finding subtle differences in every situation. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
