| Author |
Message
|
| Frnd |
 Posted: Mon Jun 04, 2007 7:40 am Post subject: CKTI TRansactions is getting triggered more in onle LPAR |
 |
|
Apprentice
Joined: 04 Jun 2007
Posts: 33
|
Hi,
Someone please help me out with the below issue.It is really affecting my work...
MF queuemanagers are receiving equal number of messages in a shared input queue. The CKTI transaction is getting triggered more in one LPAR than in the other.ie in 1:4 ratio. INITQ is shared and the queue to which the message is put in mainframe is shared..Please let me know how the load balancing happensin CICS ? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Jun 04, 2007 7:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
AFAIK the shared queue facility in z/OS doesn't provide load balancing - first queue manager to get the message is the winner. Why have you shared the INITQ?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Frnd |
| Posted: Mon Jun 04, 2007 7:55 am Post subject: CKTI TRansactions is getting triggered more in onle LPAR |
|
|
Apprentice
Joined: 04 Jun 2007
Posts: 33
|
| The shared initq was already created by somebody else. Here trigger type in the input queue is provided as Every. Is there anything that can be done to control these transactions so that the transactions get uniformly triggered (in a 50-50 basis) in different LPARs ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 04, 2007 8:04 am Post subject: Re: CKTI TRansactions is getting triggered more in onle LPAR |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sowmya wrote: |
| The shared initq was already created by somebody else. Here trigger type in the input queue is provided as Every. |
I do hope you're got the transactions throttled in CICS, or it could run wild; trigger EVERY is a bit of a dicey decision (for reasons discussed in the forum) 
| sowmya wrote: |
Is there anything that can be done to control these transactions so that the transactions get uniformly triggered (in a 50-50 basis) in different LPARs ? |
I don't believe so in a queue sharing group. If one CICS system has grabbed the queue it will tend to be in pole position for the next read, leading to the uneven distribution you're seeing. You might try throttling the transactions so that the trigger messages can't be picked up by only one CICS, but that's still not going to give you the load balancing you're looking for as I see it.
If you want load balancing, you need a cluster. And if you want CICS & a cluster, I think you need v6.
Other, more knowledgable people may wish to correct all or some of the above. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Frnd |
| Posted: Mon Jun 04, 2007 8:13 am Post subject: CKTI TRansactions is getting triggered more in onle LPAR |
|
|
Apprentice
Joined: 04 Jun 2007
Posts: 33
|
Thanks a lot for ur quick respose....I have some more doubts..
But this is happening daily. That the transactions trigger more in the same LPAR(say A) than in B.
What is the difference between giving trigtype as FIRST n EVERY ?
If i change it to FIRST, can the issue be resolved ? |
|
| Back to top |
|
|
| tleichen |
| Posted: Mon Jun 04, 2007 10:31 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
You should probably be using Trigger on First. To use this effectively, your application needs to be written to process the queue in its entirety after it is triggered, i.e., to empty the queue.
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 04, 2007 10:50 am Post subject: Re: CKTI TRansactions is getting triggered more in onle LPAR |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sowmya wrote: |
What is the difference between giving trigtype as FIRST n EVERY ?
|
As it says in the manual (  ), trigger EVERY produces a single CKTI for each inbound message; FIRST produces one only when the first message turns up.
As tleichen says, to use FIRST your application must empty the queue on each execution. I suspect this is not currently the case & the application will have been written single shot by the same monkey who thought EVERY was a good idea.
Trigger FIRST will make your problem worse. It will make all the transactions run on whichever LPAR picks up the first message.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Jun 04, 2007 3:07 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Please be aware that a trigger every still might need to read until queue empty to prevent old messages in the queue from getting replaced by a new one if you loose a single trigger message for some reason (unavailable CICS region).
I was dealing with that for a client long time ago, and we had to re-design some applications to cope with that situation, and we changed them to continue until the queue was empty, allmost like a trigger first application.
And yes trigger every need that you implement some limitations in your CICS setup. How about receive 1 million messages from some distributed servers and into a coubple of CICS'es, they will get a huge backlog and might die from such a wave, allmost like the tsunami.
Maybe a better approach will be to have a configuable trigger monitor that supports multiple started transactions ? So you live in a controlled environment without loose cannons ? I recall that Vicente Suarez from IBM wrote an article long time ago on the subject: A pattern for implementing the WebSphere MQ CICS Adapter I'm shure that it can be used as inspiration.
Just my late night comments.... 
-- Lock it or Lose it --
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Tue Jun 05, 2007 1:59 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
Trigger First behaves slightly differently on a Shared input queue than with a Private Input queue.
With a shared input queue each Queue manager will independently generate a trigger message when the first message reaches the queue so if you have three LPARs with a queue manager and CICS on each you will get three trigger messages which, with a Private initiation queue, will result in the application being started on each of the CICS regions and they will then effectively balance the workload using Pull work load balancing - The CICS will only get messages from the input queue as fast as it can handle them.
If you use a Shared initiation queue there is no guarantee that each CICS region will receive a trigger message - you could end up with three instances of your application in the same CICS region.
Trigger Every is much more resource intensive than trigger First (more messages, more transactions starts, queue opens etc) and Pushes work -starting work in CICS regions without any knowledge of the regions capacity to handle the work.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| rsantill |
| Posted: Wed Jun 06, 2007 6:38 am Post subject: |
|
|
Novice
Joined: 15 May 2001
Posts: 11
Location: Progressive Insurance
|
We are encountering the same issue with our QSG. We've been working with IBM to figure out how to resolve the issue. IBM states this is how QSG's work. MQ is not considered a WLM as stated by IBM. Clustering could possibly work, however I would still want to keep my data and initq in the QSG. We also use trigger every. Do you also use CPSM to route workload to your CICS target regions?
Last edited by rsantill on Thu Jun 07, 2007 6:53 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jun 06, 2007 7:11 am Post subject: |
|
|
Guest
|
| Quote: |
| Trigger FIRST will make your problem worse. It will make all the transactions run on whichever LPAR picks up the first message. |
Wait. Wait. Is there a problem? Like missing Service Level Agreements? Is the CICS that consumes 4 times the number of messages suffering from this? If not, you have a non-problem issue - the appearance of load-balancing.
We're talking mainframes here, where there is usually an abundance of horsepower, and CICS can handle hundreds or thousands of transactions per second with little grief. Perhaps the LPAR where CICS consumes 4 times more messages has more resources allocated to it; or there's less workload in that LAPR.
So, other than the 4:1 thing, what is the problem you are trying to solve. |
|
| Back to top |
|
|
| rsantill |
| Posted: Thu Jun 07, 2007 7:04 am Post subject: |
|
|
Novice
Joined: 15 May 2001
Posts: 11
Location: Progressive Insurance
|
| Bruce, the issue is the way workload is distributed among your LPARS that participate in the QSG. I don't know if CPSM is involved in this case. If the LPARS in the QSG are not equal the faster machine will pickup the majority of the work. You will then see the unbalance of work being processed. If CPSM is part of the equation you will also see an unbalance within your CICS target regions because CPSM doesn't do a good job of spreading the workload within an LPAR or across the plex. There are numerous factors to look at besides MQ/CICS. IBM does state that the software is working as designed, however the design maybe flawed to take advantage of faster mainframes. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 07, 2007 7:22 am Post subject: |
|
|
Guest
|
All that is true. A faster z-box will do more work - because it can complete more work than a slower box. A faster LPAR will do more work because it has more resources available to complete the work. This is called pull workload balancing. This is goodness. This is not unfairly burdening one CICS and favoring another.
Let me ask this again: other than one instance of CICS doing more of the workload, is there a problem? Are you missing any of your SLAs? If not, there is no real problem.
Is there a requirement that each CICS instance do exactly the same amount of work? |
|
| Back to top |
|
|
| rsantill |
| Posted: Thu Jun 07, 2007 7:32 am Post subject: |
|
|
Novice
Joined: 15 May 2001
Posts: 11
Location: Progressive Insurance
|
| We do miss our SLA's during higher than normal peak volume. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 07, 2007 7:48 am Post subject: |
|
|
Guest
|
And have you discovered where the bottleneck is/are? what is causing missed sla's? Is it a CICS? Several CICSs? In the same LPAR? in different LPARs? On differnet z-boxes?
Has WLM been set up to favor CICS? Is DB2 involved? Same question. What else?
Are you trying to shotgun a solution to see if things get better?
I'm not being sarcastic here. Performance tuning is complex. |
|
| Back to top |
|
|
|
|
