| Author |
Message
|
| WLeideckDC |
 Posted: Fri Dec 14, 2007 12:56 am Post subject: Question about triggering |
 |
|
Novice
Joined: 25 Aug 2004
Posts: 21
Location: Ludwigshafen, Germany
|
Hello admins,
I have a question about triggering.
Suppose I have a local queue which triggering is enabled and trigger type is EVERY. The trigger will be activated on every messages. But unfortunately the trigger application could not transport the messages into the receiving application for a while. After resolving the problem it works again. What will happen to the remaining messages in the local queue if the trigger is activated on the next receiving message? Will they remain in the queue or will they transported to the application?
Thanks in advance
Wolfgang |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Dec 14, 2007 2:27 am Post subject: Re: Question about triggering |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WLeideckDC wrote: |
| the trigger application could not transport the messages into the receiving application for a while. |
There's no such things as the trigger application and the receiving application. When the trigger conditions are met the queue manager produces a trigger event message on the specified init queue, where the trigger monitor processes it and fires the specified process. This process typcially starts an application that processes the message but the message is not "transported" to the application; it has to go and read it.
So if there's a problem the message sits there until it's fixed. This is why all applications, even triggered ones, should process the queue until it's empty.
You'll find all this documented in the APG, including the conditions on which the queue manager will (or will not) produce a trigger message. It also documents what is transported to the application (and like I said, it's not the message).
General point - don't use trigger EVERY. You'll get one application running for each message that arrives. In an moderately busy scenario this will quickly use enormous amounts of resource, especially if you're using EVERY because the application is coded to read one message and one message only. All those applications, connecting and disconnecting, will kill your throughput.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 18, 2007 9:09 am Post subject: |
|
|
Guest
|
| Quote: |
| General point - don't use trigger EVERY... All those applications, connecting and disconnecting, will kill your throughput. |
I'd have qualified the last sentence as follows: "With the exception of MQ on z/OS..." as mainframes usually have resources to meet this type of demand. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 18, 2007 12:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Quote: |
| General point - don't use trigger EVERY... All those applications, connecting and disconnecting, will kill your throughput. |
I'd have qualified the last sentence as follows: "With the exception of MQ on z/OS..." as mainframes usually have resources to meet this type of demand. |
Quite so.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 18, 2007 2:59 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
And remember that with trigger every the mainframe transaction is usually "TClassed" to limit the usage of resources... to a predetermined level 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 18, 2007 3:36 pm Post subject: |
|
|
Guest
|
| Quote: |
| And remember that with trigger every the mainframe transaction is usually "TClassed" to limit the usage of resources... to a predetermined level |
More accurately, workloads in z/OS are classified to ensure that more important workloads receive the resources necessary to meet business goals, not to limit the usage of resources. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 18, 2007 8:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
| Quote: |
| And remember that with trigger every the mainframe transaction is usually "TClassed" to limit the usage of resources... to a predetermined level |
More accurately, workloads in z/OS are classified to ensure that more important workloads receive the resources necessary to meet business goals, not to limit the usage of resources. |
I thought that workload classification was mainly for long running processes like if MQ should have a higher or lower priority than CICS...
TClassing a transaction would mean that you can run a maximun of n instances concurrently...
But maybe I'm completely off the rocker. What do I know about the MF? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Wed Dec 19, 2007 12:49 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
| bruce2359 wrote: |
| Quote: |
| General point - don't use trigger EVERY... All those applications, connecting and disconnecting, will kill your throughput. |
I'd have qualified the last sentence as follows: "With the exception of MQ on z/OS..." as mainframes usually have resources to meet this type of demand. |
I don't recommend using Trigger Every even on z/OS.
It is very wasteful to generate all of the trigger messages, it is nearly always better to use trigger first.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 19, 2007 3:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bob_buxton wrote: |
| bruce2359 wrote: |
| Quote: |
| General point - don't use trigger EVERY... All those applications, connecting and disconnecting, will kill your throughput. |
I'd have qualified the last sentence as follows: "With the exception of MQ on z/OS..." as mainframes usually have resources to meet this type of demand. |
I don't recommend using Trigger Every even on z/OS.
It is very wasteful to generate all of the trigger messages, it is nearly always better to use trigger first. |
Again quite so, but by placing the transaction in a limit (as fjb_saper says) it is not as fatal on z/OS as on a distributed platform.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Dec 19, 2007 3:58 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
What happens in effect is that the transaction starts are queued up by CICS.
Transaction management is a wonderful thing. So many non-mainframe platforms don't use it and as a result deliver poor responses for all requests beyond a certain volume, instead of limiting concurrent processing to a sustainable level and queueing the rest.
Not using triggering, but instead executing a controlled number of long-running tasks that read the same queue (with MQGET WAIT) is how we normally overcome this issue. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Dec 19, 2007 7:44 am Post subject: |
|
|
Guest
|
Briefly, very briefly, the big picture of Workload Manager (WLM) on z/Series hardware and z/OS software:
Workloads generally fall into three broad categories: databases, transactions (that use databases), and everything else (including batch).
Someone at a mainframe shop implements WLM (Workload Manager) policy - specifying workloads and their importance to the organization. If the three categories are not granular enough (CICS vs. IMS transactions; or production CICS vs. test CICS; or transactions within CICS), additional categories can be created.
WLM observes the behavior of work being processed (across all instances of z/OS in a parallel sysplex), compares this to WLM policy, and adjusts system resources to ensure that important workload service-levels are met. System resources include processor, I/O, real storage (read: RAM).
Typically, the work of a single CICS (or batch job) involves the work of several (or many) other service-provider address spaces. WLM can cause offending workloads to lose (volunteer) their resources so that more important workloads meet their goals.
Overall, the objective (in mainframes) is to use 100% of all resources (hardware and software) AND meet service goals. Unlike other platforms, mainframes can run at 100% utilization of all resources continuously, and not miss a goal.
WLM does not set upper-limit resource usage thresholds, as suggested in this and other posts regarding Tclass. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 19, 2007 2:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Bruce
My understanding of workload management just got confirmed.
For a smooth working mainframe implementation you need both workload management and resource limitation i.e. "TClassing" transactions. By limiting the number of transactions you allow to run concurrently you avoid at CICS start up or transaction start up (or channel problem resolution) the boomerang effect of a triggered every transaction that ends up sucking up all available resources (Ram, shared space for the tran, etc...) and can potentially bring down CICS... if running unchecked.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Dec 19, 2007 5:48 pm Post subject: |
|
|
Guest
|
| Quote: |
| ...limiting the number of transactions you allow to run concurrently you avoid... |
The ills you cite are possible (like SOS). However, I would not venture into this type of fix (artificially constraining MXT and AMXT) unless I had actually experienced the problem, OR calculated how many concurrent transactions make (business) sense. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 19, 2007 8:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
| Quote: |
| ...limiting the number of transactions you allow to run concurrently you avoid... |
The ills you cite are possible (like SOS). However, I would not venture into this type of fix (artificially constraining MXT and AMXT) unless I had actually experienced the problem, OR calculated how many concurrent transactions make (business) sense. |
Well, for experiencing the problem we did the first week it went live. 
We have a maintenance down time for the mainframe once a week for 6 to 10 hours. Of course the sending system has no such downtime. So when the Mainframe comes back up the channel empties the xmtq and the triggered queues just fill up. With trigger every and working until 2033 the demand on CICS resources is so high at that point that it will bring it back down in less then 10 mins. The MF programers had thought about TClassing the transaction but forgotten to follow through...
TClassing the triggered transactions at a level acceptable for business and IT rapidly resolved the problem still allowing us to run multiple instances of the transaction concurrently.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
