| Author |
Message
|
| fjb_saper |
 Posted: Sun Oct 21, 2012 7:24 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
It would also be of advantage to know how both messages look.
Could it be that one message has MQFMT_NONE and the second message has MQFMT_STRING? Thus more analysis of the sender code would be necessary...
Are there any user exits involved (sender / receiver) ? 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sun Oct 21, 2012 11:04 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| fjb_saper wrote: |
It would also be of advantage to know how both messages look.
Could it be that one message has MQFMT_NONE and the second message has MQFMT_STRING? Thus more analysis of the sender code would be necessary...
Are there any user exits involved (sender / receiver) ? |
Are both messages exactly identical? Not similar, but exactly identical? MQMD and application data payload?
_________________
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 |
|
|
| pchak |
| Posted: Mon Oct 22, 2012 10:31 am Post subject: |
|
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
| zpat wrote: |
| pchak wrote: |
| zpat wrote: |
It is not invalid to have an ASCII (or Unicode) message on a AS/400 queue manager.
It is only "mangled" if it is incorrectly described (in CCSID terms) in the MQMD. Otherwise viewing ASCII (or Unicode) data using a tool expecting to view EBCDIC can lead to the illusion that the message is invalid.
The CCSID needs to be checked in the MQMD to ensure it matches the data put to the queue (MQ does NOT convert on a PUT).
The default code page will be one from the client platform and not the default code page of the queue manager (despite this being a common belief).
All this does not explain two messages from a single MQPUT - this must be some sort of programming error unless you have found a remarkable MQ bug.
What versions of MQ are involved here?
You should always use MQSTR format - especially when crossing platform types. Using this is not a mistake, but it may be exposing an underlying problem. |
The AS400 app reads it as "mangled" as well.
I'll pass the page comments onto our admin.
We are using MQ 6.0.
The app code is diectly from the IBM red book, and >NET programming guide. Very straight-forward. We have been using it for years.
Client format default is NONE. We primarily talk to ASCII. As I said, this code is deplyed in production against ASCII QM's with no issues. When we specified format MQSTR to go to AS400, that's when the double messages show up.
Thanks! |
The application needs to use MQGET with MQGMO_CONVERT. If the message has a valid format (MQSTR), a valid CCSID and the message data is actually of the code page described by the ccsid then it will not be "mangled".
I am trying to get across the difference between an invalid message and one that is simply not being converted properly by the application that is getting it or is browsing it.
My personal approach would be to view it on the queue using MO71, ensure that tool's convert option was off. Check it is totally correct in terms of what I have mentioned. Then set convert on (in MO71) and see if the message converts correctly.
Valid ASCII (or UTF) messages will still appear "mangled" when viewed by an EBCDIC application if they don't use MQGMO_CONVERT, and vice-versa.
You should always use MQSTR for string data - otherwise you are making MQ non-platform independent. The annoying default (from IBM) of a format of NONE has caused me literally months of work over the years to sort out. Similarly the default of no convert on the MQGET.
You should never target messages for a particular platform - that is totally wrong. If the application is coded properly it will work for any target platform and no changes are required to send to a different platform.
Again, this does not explain the double message, but I recommend dealing with one problem at a time. First get to grips with the correct way to use the MQI, format, ccsid etc. |
Thanks for the info. I'll share with our admin, who's scratching his head over this. YOur point about "invalid message" is understood, and not the problem. The problem is, when we specify the MQSTRING format, we get the double message.
To clarify, if we define the message using format MQSTR, there is no format issue on the AS400 QM, but then we get the double messages. If we leave format default (none), there is only one message. the message can not be read (expecting EBCIDC rather than ASCII).
All other QM's in our domain (and some other domains) all are expecting ASCII. They all have no format, and receive only one message. I will pass on the advice that using the IBM defaults is an anti-practice. And, since using |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 22, 2012 10:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You've said that you observe duplicate messages both on the queue and in the receiving application.
Can you route the same message(s) to a queue that is not being read by the receiving application, in fact not being read by anything at all, and observe two messages?
This will further isolate the issue to either the sending application or to the channel config between the two queue managers?
Or you could route the messages to a transmission queue that is not being read by an active channel and see if you get two messages on the xmitq or not. Again, that will isolate the issue to the sending application or it's configuration, rather than anything else.
If you can isolate this to the sending application, and you can guarantee that the sending application is only issuing one MQPUT and that two messages are being produced - and you're positive you're not using either pub/sub or a distribution list - then you should take an MQ trace of the sending application and open a PMR.
If you can't isolate it, or can't guarantee that only one MQPUT is being issued, or you're not able to determine if you're using pub/sub or a distribution list, then you need to clarifying that first.
The use of the MQFMT_STRING is almost certainly a symptom and not a primary cause, despite what it appears like. |
|
| Back to top |
|
|
| pchak |
| Posted: Mon Oct 22, 2012 1:02 pm Post subject: |
|
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
| mqjeff wrote: |
Can you route the same message(s) to a queue that is not being read by the receiving application, in fact not being read by anything at all, and observe two messages?
This will further isolate the issue to either the sending application or to the channel config between the two queue managers?
Or you could route the messages to a transmission queue that is not being read by an active channel and see if you get two messages on the xmitq or not. Again, that will isolate the issue to the sending application or it's configuration, rather than anything else. |
Yes, we've sent to different queus on different QM, turned off channels, and observed the same behavior.
| mqjeff wrote: |
| If you can't isolate it, or can't guarantee that only one MQPUT is being issued, or you're not able to determine if you're using pub/sub or a distribution list, then you need to clarifying that first.. |
I wish that it was (clearly) the code. At least that's fixale. We got logging wide-open, and have stepped so many times through the code in debug.
| mqjeff wrote: |
| The use of the MQFMT_STRING is almost certainly a symptom and not a primary cause, despite what it appears like. |
I agree that it's not the cause, but trying to figure out what that setting in combination with the real problem is a stumper. :-/ |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Oct 22, 2012 11:38 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| What is the version and fixpack level of WMQ on the platform that is producing these messages? |
|
| Back to top |
|
|
| pchak |
| Posted: Tue Oct 23, 2012 3:35 am Post subject: |
|
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
| zpat wrote: |
| What is the version and fixpack level of WMQ on the platform that is producing these messages? |
WebSphere(R) MQ 6.0.1.0
V6.0.2.7 fix pack
(using MQ Client) |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 23, 2012 3:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Oh, so you *can't* open a PMR. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Oct 23, 2012 4:48 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You could upgrade the MQ client to v7.0.1.9 and see what happens.
You could install the API trace support pac (MA0W) and see what info it produces. |
|
| Back to top |
|
|
| pchak |
| Posted: Tue Oct 23, 2012 6:07 am Post subject: |
|
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
Nice. The development teamchecked in the latest code. Uppon downloading it, it was apparent that the test harness code had an additional "put" without logging <grr>  . Sorry to waste everyone's time-I know that I'd like to get 2.5 days of my life back.
However, I did gain a lot of information on configuration, and some best practices in improving code.
Thanks again for everyone's help. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Oct 23, 2012 6:12 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| pchak wrote: |
Nice. The development teamchecked in the latest code. Uppon downloading it, it was apparent that the test harness code had an additional "put" without logging <grr> . Sorry to waste everyone's time-I know that I'd like to get 2.5 days of my life back.
However, I did gain a lot of information on configuration, and some best practices in improving code.
Thanks again for everyone's help. |
Necessity is the mother of invention, and tribulation is the chisel on the pallet of memory.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Oct 23, 2012 7:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| pchak wrote: |
| Nice. The development teamchecked in the latest code. Uppon downloading it, it was apparent that the test harness code had an additional "put" without logging <grr> . |
Apply copious amounts of  to said developers, and remember my golden rule - the developers are the enemy!
| pchak wrote: |
| Sorry to waste everyone's time-I know that I'd like to get 2.5 days of my life back. |
Have those same developers help you lose another 2.5 days of your life by plying you with copious amounts of  (it should be a beer mug, but that's the closest there is in the emoticon list).
_________________
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 |
|
|
| lancelotlinc |
| Posted: Tue Oct 23, 2012 8:11 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| exerk wrote: |
| copious amounts of (it should be a beer mug, but that's the closest there is in the emoticon list). |
: r f e :
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Oct 23, 2012 8:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Imagine that?! WMQ delivers messages with no loss or duplication. Go figure.
_________________
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 |
|
|
|
|
