| Author |
Message
|
| bkavanaugh |
 Posted: Thu Sep 17, 2009 8:48 am Post subject: Transmission logging - 3rd party tool needed? |
 |
|
Newbie
Joined: 17 Sep 2009
Posts: 3
|
We're writing an application that uses MQ to send messages to another company. No one here has any experience with MQ, so we've been learning on our own.
Occasionally we have messages that our application shows were sent (no errors occurred when we put the message on the queue, and it's not still sitting in the queue), but the other company says they never received the message. Is there any way to see whether our MQ thinks it was sent, or do we have to purchase a third-party tool to do this? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Sep 17, 2009 8:57 am Post subject: Re: Transmission logging - 3rd party tool needed? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bkavanaugh wrote: |
| Is there any way to see whether our MQ thinks it was sent, or do we have to purchase a third-party tool to do this? |
If there was no error when the message was put by the application (and you'd be amazed the number of items over the years I've been told that the put worked and investigation revealed the app's error handling was faulty) then the message will be sent. End of story.
If it's not turning up where it's supposed to, this is a common problem. Top tips (not an exhaustive list):
- ensure messages are set to be persistent, at least while you're testing
- define dead letter queues on both queue managers (these are not set by default)
- check the transmission queue
- check the dead letter queues on both queue managers
- check the channel status
| bkavanaugh wrote: |
| No one here has any experience with MQ, so we've been learning on our own |
If you're already thinking of paying for a 3rd party tool, use the money instead on training or getting an experienced consultant in for a short period to mentor you. It'll be a better investment in the long run because once you buy a tool to "fix" this problem, you'll hit another one. WMQ is not a straightforward product.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Sep 17, 2009 7:40 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Implement and handle COA & COD messages and you will discover who is at fault.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Sep 17, 2009 10:15 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
a message channel exit may be an option to log what is passing the channel.
depending on the plattform you may be able to verify if a persistent message has been send over the channel from the mqseries linear log (e.g. on z/OS using the information provied by csq1logp log print utility)
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bkavanaugh |
| Posted: Mon Sep 21, 2009 4:41 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2009
Posts: 3
|
Sorry, I was out of town the last few days.
We are running MQ on Windows Server 2003 R2. Our application that puts messages on the queue and monitors the queue is written in c#.
@Vitor:
* We didn't have the messages set to persistent, but I have changed it to that. We haven't had a chance to test since then.
* We do have a dead letter queue on our side (and I assume there's one on their side, but I can't say for certain). There have been items in it before when we were still configuring the connections, but none recently.
* I agree that training would be preferable (and definitely agree that WMQ isn't a straightforward product!); unfortunately there hasn't been any in my area recently that I can find.
@RogerLacroix
I don't think we have that implemented. I'll see if I can figure that out. It looks like I should define a queue to use for reply to message to put these, correct? |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Sep 21, 2009 5:36 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Make sure the application that consumes them is transactionally safe. So it should not commit the MQGET until it has dealt with the message - ideally in 2 phase commit process.
I've seen apps that read a queue into memory with no regard for any limit and without using syncpoint - it's an accident waiting to happen. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 21, 2009 10:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bkavanaugh wrote: |
* I agree that training would be preferable (and definitely agree that WMQ isn't a straightforward product!); unfortunately there hasn't been any in my area recently that I can find.
|
What area are you talking about? Maybe someone in here knows someone/somewhere, or offers the service.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bkavanaugh |
| Posted: Tue Sep 22, 2009 4:57 am Post subject: |
|
|
Newbie
Joined: 17 Sep 2009
Posts: 3
|
| Vitor wrote: |
| bkavanaugh wrote: |
* I agree that training would be preferable (and definitely agree that WMQ isn't a straightforward product!); unfortunately there hasn't been any in my area recently that I can find.
|
What area are you talking about? Maybe someone in here knows someone/somewhere, or offers the service. |
I'm in Omaha, Nebraska. There is a Websphere user group here, but it appears they haven't met since March. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Sep 22, 2009 8:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bkavanaugh wrote: |
| I'm in Omaha, Nebraska. There is a Websphere user group here, but it appears they haven't met since March. |
If you come up short on proper training resources PM me. They tell me Omaha is a lovely vacation spot this time of year.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
