ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum IndexIBM MQ Installation/Configuration SupportQuestion about triggering

Post new topicReply to topic
Question about triggering View previous topic :: View next topic
Author Message
WLeideckDC
PostPosted: Fri Dec 14, 2007 12:56 am Post subject: Question about triggering Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Dec 14, 2007 2:27 am Post subject: Re: Question about triggering Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25917
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
View user's profile Send private message
bruce2359
PostPosted: Tue Dec 18, 2007 9:09 am Post subject: Reply with quote

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
PostPosted: Tue Dec 18, 2007 12:42 pm Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25917
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
View user's profile Send private message
fjb_saper
PostPosted: Tue Dec 18, 2007 2:59 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20213
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
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Tue Dec 18, 2007 3:36 pm Post subject: Reply with quote

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
PostPosted: Tue Dec 18, 2007 8:04 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20213
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
View user's profile Send private message Send e-mail
bob_buxton
PostPosted: Wed Dec 19, 2007 12:49 am Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Wed Dec 19, 2007 3:50 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 25917
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
View user's profile Send private message
zpat
PostPosted: Wed Dec 19, 2007 3:58 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5688
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
View user's profile Send private message
bruce2359
PostPosted: Wed Dec 19, 2007 7:44 am Post subject: Reply with quote

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
PostPosted: Wed Dec 19, 2007 2:55 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20213
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
View user's profile Send private message Send e-mail
bruce2359
PostPosted: Wed Dec 19, 2007 5:48 pm Post subject: Reply with quote

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
PostPosted: Wed Dec 19, 2007 8:32 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20213
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
View user's profile Send private message Send e-mail
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexIBM MQ Installation/Configuration SupportQuestion about triggering
Jump to:



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
Protected by Anti-Spam ACP


Theme by Dustin Baccetti
Powered by phpBB 2001, 2002 phpBB Group

Copyright MQSeries.net. All rights reserved.