| Author |
Message
|
| exerk |
 Posted: Wed Dec 10, 2008 1:17 am Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| vinay_s_s wrote: |
| If the user is a null character string, why is application 'B' processing the messages when put from MQexplorer on Server 'A'. |
And MQExplorer is using which channel? You still have not stated whether channel TO.NTEHUBA is a SDR, or not. You have still not stated whether you have checked to see whether user 'XXXX' exists on Server A, or not.
So, I'll ask the obvious question: Have you tried setting the MCAUSER to blank, restarting the channel, and seeing whether traffic flows between the queue managers?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
 |
| zhanghz |
| Posted: Wed Dec 10, 2008 1:18 am Post subject: |
|
|
Disciple
Joined: 17 Jun 2008
Posts: 186
|
| i think the application is using an non-existing MCA user ID. Advise them to use a correct one that has been properly defined. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Dec 10, 2008 6:43 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| MQPUT from application 'A' reaches the local queue. |
I'm confused.
When your client application A puts a message, which local queue does it arrive at? The transmission queue on the local (where the client application MQCONNects) qmgr? You stated that curdepth goes up. On which queue does curdepth go up?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| vinay_s_s |
| Posted: Thu Dec 11, 2008 1:26 am Post subject: |
|
|
Apprentice
Joined: 17 Nov 2008
Posts: 39
|
Hi all,
I'll make it clear.
So what you're saying is that if you put a message onto a remote queue definition on server A using MQExplorer, the message travels to the local queue on server B where it's processed. If you put it using a client app it doesn't travel to B and you get an error saying the non-existant MCA User can't be verified?
In both the cases, the message travels to the local queue on server 'B'.
If the message is sent from MQexplorer, the application 'B' processes that message even though the MCAuser is 'XXXX'.
If the message is sent from a MQ client, the message reaches the local queue on server 'B', but application 'B' will not process it.
Regards,
Vinay |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Dec 11, 2008 6:06 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Please post the definitions for :
The sender channel on server A
and
The client channel definition on server B
This may help clear up any confusion. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 11, 2008 6:23 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If the message arrives on the queue regardless of what sent the message, then it's got nothing to do with channel definitions.
If the application processes SOME messages, and fails to process OTHER messages, all from the same queue, then it's either the *message*, or the *application*.
You can use amqsbcg/amqsbcgc to troubleshoot the message.
And you can use a programmer to troubleshoot the application, but you may have to apply trout first to get his or her attention. |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Dec 11, 2008 7:58 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| mqjeff wrote: |
If the message arrives on the queue regardless of what sent the message, then it's got nothing to do with channel definitions.
|
Possibly.....unless the MCA is different and one is 'xxx' and the other is 'XXX' or something like that.
I am not suggesting the message doesn't arrive, but that it may arrive with something a little screwed up with the MCA in the channel definitions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 11, 2008 8:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kevinf2349 wrote: |
| I am not suggesting the message doesn't arrive, but that it may arrive with something a little screwed up with the MCA in the channel definitions. |
But what could be screwed up with the message that would a) allow the message to be delivered yet b) prevent the application from processing it?
Now here's a thought - if the MCA is screwed up, the message is still delivered. Do we mean "delivered and available for the getting application" or do we mean "delivered because the queue depth has gone up by 1"? I'm wondering if these delivered messages are remaining uncommitted for some reason and hence the application is not processing them because they can't actually be read off the queue?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| vinay_s_s |
| Posted: Thu Dec 11, 2008 9:18 pm Post subject: |
|
|
Apprentice
Joined: 17 Nov 2008
Posts: 39
|
Posting the resolution of this issue. I had a real hard time resolving this issue yesterday. Finally got out of the issue.
It was not a channel problem. It was just a small message option that was preventing the application to consume the message.
When a message was placed on the queue from application 'A', there is one property - message format as 'MQSTR'. This was not set by the sending application.
But when we put the same message from MQexplorer, the property was set to 'MQSTR' and the application 'B' consumed the message.
A temporary work around has been done. Requested the application teams for long term fix.
Any way, thanks a lot all of you for your valuable time and suggestions.
Thanks again,
Vinay |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 12, 2008 7:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...format as 'MQSTR'. This was not set by the sending application. |
The initial value of the format field is MQFMT_NONE. This would not have caused your symptom. So, had the programmer not set the format field to something else, the consuming application and the MCA should not have had any issue with the message.
What was in the format field that you believe caused your application to be unable to MQGET the message?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| sark92 |
| Posted: Mon Dec 15, 2008 10:17 am Post subject: Conversion trouble ? |
|
|
Newbie
Joined: 08 Jan 2007
Posts: 3
|
Hi,
as it seems that the "getting application" can't read the message without the "MQSTR", it's make me thinking of a conversion issue, as the field has to be set to "mqstr"... ??? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 15, 2008 11:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| "getting application" can't read the message without the "MQSTR" |
If this were the case, the application would receive a ReasonCode that says so - which means that the MQGET failed.
The original post title was vague. Subsequent requests for more information resulted in more vague answers and speculation about what might or might not be the cause.
If the MQGET by the consuming application failed, ReasonCode would tell all. If the receiving MCA didn't have authority to MQPUT the message into the application queue, it would have posted a ReasonCode (error log); AND there wouldn't be a message to consume.
We can imagine and speculate all day; but problem-determine requires specific details - all lacking throughout this post. This is/was just a variation of MQ is losing my messages!
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| sark92 |
| Posted: Sat Jan 10, 2009 3:42 am Post subject: reason code... |
|
|
Newbie
Joined: 08 Jan 2007
Posts: 3
|
Yes,
the application would get a reason code, but does the application take care of reason codes ? i've often seen applications wich don't test return codes, and in which the different reason codes are "lost" (are not handled)...
and i do agree with you when you say that the description is very vague |
|
| Back to top |
|
|
|
|
