| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Triggering methods on Z/OS |
« View previous topic :: View next topic » |
| Author |
Message
|
| vsridhara |
 Posted: Thu Feb 12, 2009 12:08 am Post subject: Triggering methods on Z/OS |
 |
|
Novice
Joined: 12 Feb 2009
Posts: 10
|
Hi,
we are implementing MQ on our Z/OS system and would want to have triggering methodology implemented. Can any of the gurus enlighten me about the triggering methodologies available and how we can implement them? To note here is we are only using DB2, JCL, PL/1 and no IMS/CICS interaction with MQ.
also please address if asynchronous reads happen from the queue due to triggering, the jobs still will be held in the queue due to identical job names. How to handle this?
Thank you in advance
Vijay S |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Thu Feb 12, 2009 12:32 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
for triggering you need a trigger monitor. as you require triggering for batch jobs (thats what i read from your question) you should download the proper sample from the MQSeries supportpac site and modify it to fit your needs. There are different ways to start the application job... some submit jobs directly from the trigger monitor, either by using the supplied data from process definition, or by using jcl templates from pdf libraries, some call the proper scheduler e.g. ca7 to submit the job, some do this, some do that... 
of course you should not use trigger every when triggering batch jobs, i suggest to use trigger first, have the application program process all messages on the queue and then wait for some time if more messages arrive. then you will have no jobs piling up ......
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 12, 2009 6:22 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
SupportPac MA12 is a good place to start.
_________________
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 |
|
|
| zpat |
| Posted: Thu Feb 12, 2009 6:49 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You don't have to use triggering.
You could have a long running batch job (scheduled via your OPCS or similar) which processes messages as they arrive (MQGET with WAIT).
If your messages arrive frequently (eg more than one per minute) then I would suggest this method is more efficient. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 12, 2009 7:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| of course you should not use trigger every when triggering batch jobs |
Trigtype(every) is a choice on all MQ platforms, but is appropriate only when SLAs demand multiple, concurrent application instances; and when message affinity is not involved, and sufficient resources exist to handle the potential application storm. What better place to have such an application than z/OS.
Given the mainframes abundant resources, and its long history of meeting enormous workload demands, I would not summarily rule out trigtype(every). Again, every is a choice.
_________________
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 |
|
|
| Mr Butcher |
| Posted: Thu Feb 12, 2009 8:00 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| Again, every is a choice. |
not for batch triggering. if you use cics or ims, yes.
do you really want 10.000 batch jobs being triggered when 10.000 messages arrive within 5 seconds?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Feb 12, 2009 8:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Given the mainframes abundant resources, and its long history of meeting enormous workload demands, I would not summarily rule out trigtype(every). Again, every is a choice. |
In this specific instance, we're talking about batch triggering. So the appliction storm, while it won't cause machine wide resource shortages or instability, will fill the JES queues quite effectively and make you fairly unpopular with a diverse group of people.
Where trigger(every) is commonly used in mainframe online triggering, where you've access to the failicities CICS offers to control application storms. Which of course is just moving the control from WMQ to CICS, but CICS is more configurable and tends to be preferred.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 12, 2009 8:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| will fill the JES queues quite effectively |
I'm thinking of transactions that, for whatever reason, can't/don't run in traditional transaction processores like CICS or IMS. Yes, they might be initiated from CICS or IMS, or from a triggered batch application. But short of rewriting batch jobs to run in transaction-friendly CICS/IMS environments, batch storms work, and with planning will not be fatal.
An aside: when 10,000 tso users log on at the same time, like 8:00am, MVS barely notices.
I'm certainly not recommending long-running batch jobs or those that produce lots of sysout. A transaction by definition is short-running, low output.
Some planning to accomodate more jes jobnumbers, more intiators, jes spool, more whatever, will be required. These are not show-stoppers usually.
_________________
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 |
|
|
| Vitor |
| Posted: Thu Feb 12, 2009 8:35 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Some planning to accomodate more jes jobnumbers, more intiators, jes spool, more whatever, will be required. These are not show-stoppers usually. |
You've met some nicer sys progs than I have. Getting another job class running typically takes weeks of reports, impact analysis, scheduling evaluation and meetings. And a new initiator? Starting another one of those could cause earthquakes, plague, drought and a rain of fire!
I mean, it's not like either thing is a one line command on the console..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 12, 2009 8:45 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Some additional comments...
There are two schools of thought, two philosophies at work here.
1) use all the resources necessary to meet SLAs
2) conserve resources (for emergency and future use)
As a consultant, I'm not burdened with the second one. If your SLA calls for more hardware, software, whatever, then you need to acquire it or renegotiate your SLAs. I'm thinking that you own this Boeing 777; why are you only filling 2/3s of the seats? Are you expecting additional passengers after you depart?
As a manager, operations and tech-support person, I must pay attention to the second for continuous operation and in anticipation of unplanned demand.
My post replies here are in the spirit of 1) above. There's a requirement; z/OS can meet it easily. I certainly can't say the same for Windows and UNIX.
I've worked for many organizations that were so focused on 2) that they spent far too much effort and $ deploying applications to meet the existing environment - an environment that history has proved changes every few years.
_________________
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: Thu Feb 12, 2009 8:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| You've met some nicer sys progs than I have. |
Perhaps one or two.
Most sysprogs, like other employees, are in the conservation of resources mode, not the use all resources mode. I understand and expect this view of the computer room. And, ultimately, I support it - there need to be some restrictions.
However, new business requirements require new stuff - change. Who would have thought sysprogs don't like change!
_________________
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 |
|
|
| zpat |
| Posted: Thu Feb 12, 2009 10:49 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Speaking as a former SysProg - I think you will find they love change. It's their management that like to restrict it.
Triggerevery does not sound like a good idea. As I have said already, triggering is not even needed.
If you are going to start more than about 100 jobs a day, I would recommend a long-running job, or a started task that waits for messages to arrive.
z/OS will swap out an inactive job and very few resources will be used by a job waiting for messages to arrive. Much better than starting and stopping the job each time.
In any case you have to run the trigger monitor waiting for trigger messages, so why not just run the actual application to wait for application messages and cut out the middle-man!
Triggering is a terminally old-fashioned concept, except where you have a variety of different applications which are occasionally started.
If you are frequently needing to run the same application - just leave the thing running all the time!
Make sure the MQGET uses MQGMO_WAIT, CONVERT, FAIL-IF-QUIESCING (and syncpoint if you want to ). |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Feb 12, 2009 11:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| why not just run the actual application to wait for application messages and cut out the middle-man! |
No argument from me on this subject, other than ruling it out sumarily.
If more concurrency is required, then why not start 5 or 10 instances of the same actual application, and let them get as many messages as they can?
_________________
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 |
|
|
| zpat |
| Posted: Thu Feb 12, 2009 1:19 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Because he's not asked for that and one batch program will process a considerable number of messages per second anyway.
After all what is a CICS region other than a type of batch job?
Starting a load of batch jobs fighting for the same messages is unlikely to be necessary.
If one long running batch job (or started task) is not enough (seems unlikely) then run two or more, still no need for triggering.
I have programmed for z/OS extensively in supervisor state, key zero, Assembler code and I really do know what I am on about here.
There is a considerable overhead in JES2 job initation and termination.
My advice - do not use batch triggering. Never use trigger every. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Feb 13, 2009 4:33 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
i fully agree to the second one...... for the first one ... we do trigger batch, but we never use every, and only for low message traffic and for "special" applications (more system related rather than application related, like DLQ handling or similiar)
hovever if somebody really wants to go for trigger every in batch .... everybody is free to learn by his own mistakes 
_________________
Regards, Butcher |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
