| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Triggering on AS/400 |
« View previous topic :: View next topic » |
| Author |
Message
|
| gabbar |
 Posted: Thu May 22, 2003 2:01 pm Post subject: MQ Triggering on AS/400 |
 |
|
Acolyte
Joined: 10 Dec 2002
Posts: 50
|
Hello
Our Setup
MQ Server on AS/400.
MQ Client on NT
We have an app, say SENDER_APP which makes a client connection to a queue manager on 400 and constantly puts messages on a queue, lets call it RECEIVERQ. Its an ever running app which never gets rid of the connection to RECEIVERQ even when it is done putting messages on the queue.
Our requirements:
Enable triggering on RECEIVERQ.
Our test implementations:
We initially tried to implement trigger type *FIRST, which would trigger a process when first message arrives on RECEIVERQ. However, since SENDER_APP has a constant hold on RECEIVERQ, triggering didn't work. Thats what the documentation said, "If the application queue is open for input, by any program, and has triggering set for FIRST or DEPTH, no trigger event will occur since the queue is already being served".
So, we implemented trigger type *ALL( i.e EVERY) to trigger a process for every message that arrives on the Q. Obviously, when there are thousands of messages arriving on the Q, we are talking about equal number of processes being invoked. !!!FRUSTRATION!!!
Back to *FIRST.
Question: Keeping in mind that we cannot avoid the presence of SENDER_APP, is there a way for a better implementation. We are more inclined towards implementing trigger type *FIRST than *ALL ( EVERY).
I also wonder how the trigger type *FIRST be implemented in other situations. You cannot "directly put messages on the queue and expect the trigger to fire".
if you are reading this line, thanks for your patience. now please put in some thoughts.
Thanks |
|
| Back to top |
|
 |
| mgrabinski |
| Posted: Thu May 22, 2003 11:07 pm Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
| Quote: |
We initially tried to implement trigger type *FIRST, which would trigger a process when first message arrives on RECEIVERQ. However, since SENDER_APP has a constant hold on RECEIVERQ, triggering didn't work. Thats what the documentation said, "If the application queue is open for input, by any program, and has triggering set for FIRST or DEPTH, no trigger event will occur since the queue is already being served".
|
If I understand you correctly, the SENDER_APP only sends messages to RECEIVERQ, so it doesn't need to open the queue for input and so the triggering of type FIRST should work. I've done this on z/OS (but the platform doesn't matter here)
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| gabbar |
| Posted: Fri May 23, 2003 3:02 pm Post subject: |
|
|
Acolyte
Joined: 10 Dec 2002
Posts: 50
|
Thanks for the reply Marcin,
The application is opening the queue for both input and output. Its the way this third party app is designed and we are in no position to change the way it behaves. |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Sun May 25, 2003 9:44 pm Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
Hi
You can still do a trick to have FIRST triggering. Define the RECEIVERQ as an alias queue pointing to, say, RECEIVER.BASE. Configure the latter as a triggering queue. Then the sending application can have RECEIVRQ queue open for input but messages arriving in it will trigger your application (as they will be physically going to RECEIVER.BASE)
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| gabbar |
| Posted: Mon May 26, 2003 10:54 pm Post subject: |
|
|
Acolyte
Joined: 10 Dec 2002
Posts: 50
|
Hi
It was one of the first things we tried. The app was made to use the handles on an alias queue to RECEIVERQ, and we tried triggering on RECEIVERQ. It didn't work, because, though this third party app was connecting thru the alias queue, the actual handles were on the RECEIVERQ. In iSeries terms, the jobs were listed for RECEIVERQ and not for the ALIAS queue.
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue May 27, 2003 9:16 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, since you're really stuck with the behavior of a third party app, you might consider exactly how much work you're willing to put in to overcome that.
In other words, how much is it worth to you to change the trigger behavior?
If it's worth rather a lot, you should be able to create your own triggering system by registering a process for queue depth events that will launch the third party app when the queue depth changes from 0 to 1.
If it's not worth that much, you're much better off living with the EVERY behavior. |
|
| Back to top |
|
|
| gabbar |
| Posted: Tue May 27, 2003 10:05 am Post subject: |
|
|
Acolyte
Joined: 10 Dec 2002
Posts: 50
|
| I might as well live with EVERY or write a program which polls every few seconds for messages on the queue. May be this is a dumb question to ask, but is there a way to forward messages in one queue to another queue within a queue manager. |
|
| 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
|
|
|
|
