| Author |
Message
|
| Yuvaraj |
 Posted: Tue Jan 13, 2004 6:54 pm Post subject: Calling a mainframe program upon message arrival in a queue |
 |
|
Apprentice
Joined: 28 Oct 2003
Posts: 30
|
Hi,
I need to trigger a program on a mainframe when a message arrives in a queue (on the mainframe). This has to be a real time transaction as the program running on the mainframe is expected to put a reply message in another queue. I would like to know how this can be achieved without using a CICS bridge.
thanks,
Yuvaraj |
|
| Back to top |
|
 |
| kman |
| Posted: Wed Jan 14, 2004 12:27 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
If you don't want to use CKTI, then you need to write a program - a trigger monitor, to monitor the initiation queue. Check the App Programming Guide for this.
You must have some reasons why you can't use the supplied trigger monitor. |
|
| Back to top |
|
|
| offshore |
| Posted: Wed Jan 14, 2004 5:25 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
Yuvaraj,
yes, why can't you use CKTI?? Assuming you are wanting to use CICS, CKBR AND CKTI are you 2 choices. There is also trigger monitor for IMS and you can download a batch trigger monitor (WMQ Support Pac) if you need to trigger a batch job. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jan 14, 2004 7:10 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Why trigger? Triggering is only really good for very intermittent invocation. It has extra overhead of a PUT and GET to the initiation queue and has to load the application program into the system each time a message arrives.
Just code a long-running CICS transaction with MQGET WAIT on the queue. Process the message, reply to it and repeat the MQGET WAIT in a loop. For a server program that is invoked fairly frequently this is the most efficient way to code it. |
|
| Back to top |
|
|
| offshore |
| Posted: Wed Jan 14, 2004 10:16 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
ZPat,
Yuvarja mentioned processing in real time. Doing a get with wait wouldn't be necessarily be "real time" depending on the coding, plus you would still have to have something to start up the program in CICS.
CKTI or CKBR will start the program. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jan 14, 2004 11:52 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| We start such a program when the CICS region is first brought up. I don't how that's done at our site. |
|
| Back to top |
|
|
| kman |
| Posted: Thu Jan 15, 2004 11:34 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
Correct me if I am wrong. Running a trigger monitor is more robust than a long running GET WAIT program. The GET WAIT program can get terminated for some reasons, and the messages will not be serviced.
Trigger monitor is more robust and does not get terminated easily. The process that was started by the trigger monitor may get terminated, just like the GET WAIT program. But the program will get triggered again, with a good setting of the trigger parameters.
But if you know the frequency and processing window for your transactions, then probably a long running GET WAIT program is better. You shut it off outside of its processing windows, so that you can get back the resources held by thta program. Where as triggered program is good when the frequency is low and you don't know the processing window.
Just a thought. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jan 16, 2004 12:48 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
A trigger monitor is just an IBM program that issues GET with WAIT on the initiation queue. But you are correct, it is good for use with intermittent messages.
What you can do to protect your long-running GET WAIT task is to trigger it on queue depth so that if it does fail and messages build up, then it is restarted automatically.
Or maybe trigger it on FIRST, since I believe MQ only generates trigger messages when the queue is not open for input, so this would give you an immediate restart on failure.
You can design a compromise, for example trigger the running task on FIRST but then keep the queue open with a GET WAIT for perhaps 30 mins - then if no message is available after all that time terminate and get triggerred next time it's needed.
For a really high volume OLTP system though you may actually want several tasks waiting on the input queue with GET WAIT, ready to process several messages in parallel. This is better than trigger EVERY which could start too many tasks at once. |
|
| Back to top |
|
|
| pgorak |
| Posted: Fri Jan 16, 2004 1:14 am Post subject: |
|
|
Disciple
Joined: 15 Jul 2002
Posts: 158
Location: Cracow, Poland
|
To add something to what zpat said:
Another very nice way of dealing with high volume of transactions is to trigger only a controlling CICS transaction which in turn invokes a number of transactions that actually process messages. The number of processing transactions invoked may depend on the depth of the queue (which reflects the volume) and should have a maximum defined.
Piotr
_________________
***
IBM Certified Solution Developer WebSphere MQ 5.3 |
|
| Back to top |
|
|
| offshore |
| Posted: Fri Jan 16, 2004 3:53 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
You can start the CICS program in the PLT.
I guess I never considered a long running program because currently we have approx. 70 different queues that call 70 different trans/programs. All the programs perform different functions.
So for me its better to let the monitor handle and let the program terminate when finished. Also, the programs are generated at random for lack of a better term, depending on what the end user is doing.
I suppose we could talk about this for days..haha |
|
| Back to top |
|
|
|
|
