| Author |
Message
|
| pnimith |
 Posted: Wed Sep 21, 2005 9:28 am Post subject: forwarding messages from xmit q to dead q |
 |
|
Novice
Joined: 10 May 2005
Posts: 23
Location: ny, usa
|
hi all
if a channel is down and messages are waiting on xmit queues, is there any way to forward this messages to DLQ w/o using any exits?
thanx |
|
| Back to top |
|
 |
| Michael Dag |
| Posted: Wed Sep 21, 2005 9:36 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| sebastianhirt |
| Posted: Wed Sep 21, 2005 10:31 am Post subject: |
|
|
Yatiri
Joined: 07 Jun 2004
Posts: 620
Location: Germany
|
You can make them dissapear, if you set NPMSPEED Fast and send them as non persistent. But then they are lost (realy lost).
If your concern is that data could be outdated at the time it gets transmitted, you might consider setting an expiry.
Hope this helps
Sebastian |
|
| Back to top |
|
|
| mq_developer |
| Posted: Wed Sep 21, 2005 10:36 am Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
| Quote: |
| if a channel is down and messages are waiting on xmit queues |
That is precisely the advantage of MQseries -its asynchronous behaviour -
At this point its not clear , you have to qualify the "waiting" part in "waiting on xmit queue" .. How long and what timeframe are you talking about - based on that you can try to use expiry and report options. |
|
| Back to top |
|
|
| pnimith |
| Posted: Wed Sep 21, 2005 11:21 am Post subject: |
|
|
Novice
Joined: 10 May 2005
Posts: 23
Location: ny, usa
|
thanx all
sebastian:
| Quote: |
If your concern is that data could be outdated at the time it gets transmitted, you might consider setting an expiry.
|
-- that accurately describes my concern. but i am not sure if enforcing setting of expiry can be guaranteeed. i expect messages from about 100 external entities(not part of our organization).
if i could be sure that the messages have expiry specified, 'mq_developer's' suggestion of using 'expiry and report options' would be a perfect solution.
any message sent to dead q can be handled by dl handler/program but if it is on xmitq and becomes outdated, how do i deal with it(logging and discarding) ?
thanx a lot |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 21, 2005 11:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The only messages that will ever be on YOUR Xmitqs are messages FROM your applications.
So you should be able to instruct your developers to always set expiry.
Alternately, a process could be kicked off when the channel indicates that it has gone into retry. You could force stop the channel, filter the xmitq, and then attempt to start the channel again.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| pnimith |
| Posted: Wed Sep 21, 2005 11:40 am Post subject: |
|
|
Novice
Joined: 10 May 2005
Posts: 23
Location: ny, usa
|
thanx jeff
| Quote: |
The only messages that will ever be on YOUR Xmitqs are messages FROM your applications.
So you should be able to instruct your developers to always set expiry.
|
i have two QMs, say A and B. all the senders send messages to B. from B all the messages are sent to A and onto an application for processing. my area of concern i was referring to is the xmit q on B (routing to A from B). so u see, i do have a xmit q where messages coming from outside could be waiting.
ur suggestion sounds very good. forgive me for my lack of knowledge/experience, but how should i 'filter the xmitq'?.
thanx again. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 21, 2005 12:34 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In your case, with a gateway qmgr, you don't need to worry about the Xmitq.
Just set up local queues on the gateway, that receive the data from the external customers.
Then set up a program that reads messages from that local queue, sets the xpiry, and then forwards the message to the right internal queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mq_developer |
| Posted: Wed Sep 21, 2005 12:52 pm Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
I am not sure what problem are you trying to address ...
Your requirement seems like you dont want any outdated messages to be consumed by the end program (hope i read it correct) , that being said how removing the messages from XMITQ would help .
What if the messages go & pile up on your application queue that feeds your end application (let say because of some adminstartive issue - for instance queue is get disabled) ...
How will you ensure that outdated information didnt reach the program
By virtue , if the requirement is such that data has limited lifetime and is outdated thereafter, lifetime(expiry) should be set by the application that is sending it - that is the elegant , simple and complete solution.
And again you havent qualified "waiting" on xmitq , what time period are you talking about?. Channel has retryinterval and retry counters ,
Clearing the XMITQ on channel retry and others - you are very deviating from your requirement and making it whole complex. |
|
| Back to top |
|
|
|
|
