| Author |
Message
|
| Jesh |
 Posted: Wed Apr 09, 2003 9:01 am Post subject: Trigger Problem with TrigType 'FIRST' |
 |
|
Novice
Joined: 09 Apr 2003
Posts: 12
|
Hi,
We have a queue defined with the trigger type 'FIRST' and the trigger process is a CICS transaction. Our requirement is that this CICS transaction should do a dummy read on the queue(read with a non existing message ID).
Now, whenever a message is put into this queue, multiple instances of the CICS transaction get triggered. there are so many instances initiated that the CICS region is completely flooded by this transaction & the CICS region has to be recyled. It seems that we are getting into some kind of triggering loop.
Can somebody tell me the multiple instances of CICS transaction get triggered because it does not actually read any message but does only a dummy read.
Thanks & Regards,
Jesh |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Wed Apr 09, 2003 10:15 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Triggering First means that whenever a message arrives on the queue, a trigger message is generated and the process associated is invoked. In this case a CICS transaction.
Assuming that everything goes well as per above, you would have only 1 transaction started. Until and unless the physical message is still in the triggered queue, and all the conditions for trigerring are not reset, you should not get another trigger message nor should you get another CICS transaction invoked. In the event this is not happenning you have to check if there is any process that is resetting all of this.
Alternatively you could modify your process definition to invoke a script or an executable to see how many times that process gets invoked in the same scenario. If it gets invoked only once in the same situation, then there's something to do with the CICS transaction invocation.
Hope this helps.
Cheers
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Wed Apr 09, 2003 10:51 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
First RYFM 
2nd I know it's painfull, one of the reasons why your CICS gets flooded, this is because of the way my handles trigger-FIRST:
You will have a TRIGGER-MSG if Q-depth goes from 0->1, and the queue is not open for input (BASIC).
You will have another trigger when the queue is closed and noby is reading the queue and q-depth is <> 0.
You are saying that your application do a dummy get ?, this means that the message is staying on the queue, and when your program do MQCLOSE, MQ will start a new instance, and this happens before the old one was really terminated. This might be your senario. 
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| Jesh |
| Posted: Wed Apr 09, 2003 11:33 am Post subject: |
|
|
Novice
Joined: 09 Apr 2003
Posts: 12
|
Thanks guys.
So i could eliminate the duplicate trigger messages if I keep the queue open always. Right?
Regards,
Jesh |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 09, 2003 12:38 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes, if you left your program running, which kept the queue open, you would not get another trigger.
But what are you really trying to do? What does it accomplish to do a 'dummy read' on a queue, and then wait around?
Maybe it is better to figure out what you are waiting around for, and then adjust your process initation (i.e. triggering) to only trigger when you don't need to wait? Perhaps you're waiting for all messages in a group?Perhaps you're waiting for a message with a certain ID? Perhaps you're waiting for something else? |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Wed Apr 09, 2003 12:38 pm Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Right you are.
Why should your application not read the message ??
normally on every queue where we use triggering it's to start processing the messages, and not "just" for fun.
MQ expects that your application acts in this way, when it's triggered it should empty the queue.
You can prevent MQ of issuing extra triggermsgs by holding the queue opened for input as explained before..
Maybee I should explain the triggering also on my home page... If I find the time 
Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| Jesh |
| Posted: Wed Apr 09, 2003 1:00 pm Post subject: |
|
|
Novice
Joined: 09 Apr 2003
Posts: 12
|
Sorry...I should have explained in detail....Let me just do that --
We are trying to achieve expiry of messages and automatic dicarding of messages..that is expired messages should get transferred automatically from one queue to another queue. We attain auto-discardal by a CICS transaction executing a program that does a dummy read..ie. a read with a non-existing correlation ID and we have indexed the queue based on Message ID. This transaction starts itself after every few seconds.
Since the index is based on Message ID and we read with correlation ID set, the indexes are skipped and this works the way we wanted, messages get discarded as we had expected. Till this point, we did not have any trigger settings on this queue.
But this transaction needs to be invoked during the start of the day or during any unplanned shutdown of CICS region. So we thought, we would do this by having trigger 'FIRST' on this queue and we ran into the looping problem.
I realise now that this problem is because I close the queue after every dummy read. One option would be to keep the queue open always.
I need not leave my program running for ever to keep the queue open. I can pass on the HOBJ to every new invocation of this transaction and have a flag set to indicate that the queue is already open and use the HOBJ that is passed.
I hope i have explained enough...
Thanks,
Jesh |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 09, 2003 1:25 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So, there are two cases where you need to start this job:
1) At the start of the day
2) "during an unplanned shutdown of CICS"
I would not use triggering for this. I would schedule the job to run at the start of the day, whatever that is. That takes care of case 1.
I would also have the job run as part of the CICS shutdown procedure. Then that takes care of case 2. You may be able to do this through your scheduling mechanism, or by having your systems programmers change the CICS shutdown task. If you're not shutting CICS down through a process (rather, perhaps, it is simply crashing), you could also have the task run when CICS starts up. That will ensure that it happens at least once for every shutdown, planned or not.
Neither of these involve leaving the queue open or passing a (possibly no longer valid due to a variety of issues) HOBJ around. |
|
| Back to top |
|
|
| Jesh |
| Posted: Wed Apr 09, 2003 1:33 pm Post subject: |
|
|
Novice
Joined: 09 Apr 2003
Posts: 12
|
Thanks Jeff.
We considered both the options you had mentioned.
Scheduling at the start of the day would take care of case 1.
But for case 2, CICS Systems Group guys here are not willing to add transactions to their startup deck citing policy reasons.
That is why, we thought of doing it using trigger. But tell me why my HOBJ would not be valid if I pass it around.
Any other solution to this would also be of great help !
Regards,
Jesh |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Apr 10, 2003 4:40 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| The Hobj....or rather the connection handle is associated with a particular TCB, if you attach a subtask that subtask has to have it's own connection handle and ergo its own set of HOBJS too. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Fri Apr 11, 2003 12:36 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Discarding expired messages... gee!
One of my customers have added this function thru a OPC-scheduled batchjob.
What you also can do is adding the program to ICE list in the CICS, and get it re-run each 5 minutes, and have the automation starting it when CICS wakes up. This eliminates the need for triggering.
Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
|
|
