| Author |
Message
|
| pchak |
 Posted: Fri Oct 19, 2012 5:52 am Post subject: Double message- .NET MQ CLient to AS400 (EBCDIC) QM |
 |
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
Hi!
We're exhibiting some very strange behavior with a client service broker connecting to a Queue Manager on an AS400 box.
We're using the standard amqmdnet.dll to excecute fairly common code (as found in the IBM samples, on line, etc.) to put messages on the queue. This service broker is used throughout our application architecture and has been successfully deployed in production connecting to ASCII-based Queue Managers on both AIX and Windows Servers.
We have a requirement to write to a queue on the AS400. If we send without formattting the message for EBCDIC, it naturally shows up garbled.
If we insert "msg.Format = MQC.MQFMT_STRING" into our code, the message shows up properly formatted on the AS400 queue, but there are two messages generated. The behavior goes away if we comment out that line. Are we:
1. using the right format
2. do we need to specify some additional option
The message shows up double on the ASCII QM queues as well.
If anyone can shed light on this behavior, it would be greatly appreciated.
Thanks!
Bill
code snippet:
msg.Format = MQC.MQFMT_STRING;
MQPutMessageOptions mputOptions = new MQPutMessageOptions();
mputOptions.Options = MQC.MQPMO_NONE;
q.Put(msg, mputOptions); |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Oct 19, 2012 6:05 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You need to isolate the source of 'two messages are generated'.
It is not apparent from what you have said that you have done that - you may have, actually, but it's not apparent.
Are you writing to a local qmgr, and moving the message to the AS400 over a qmgr-qmgr channel? If so, stop the channel. Determine how many messages are written to the transmission queue.
If there are two, continue troubleshooting.
I'd recommend taking an mq trace of your application and seeing what it's doing.
If there is only one, pass this information to the AS400 team and wash your hands. |
|
| Back to top |
|
|
| pchak |
| Posted: Fri Oct 19, 2012 6:30 am Post subject: |
|
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
| mqjeff wrote: |
You need to isolate the source of 'two messages are generated'.
It is not apparent from what you have said that you have done that - you may have, actually, but it's not apparent.
Are you writing to a local qmgr, and moving the message to the AS400 over a qmgr-qmgr channel? If so, stop the channel. Determine how many messages are written to the transmission queue.
If there are two, continue troubleshooting.
I'd recommend taking an mq trace of your application and seeing what it's doing.
If there is only one, pass this information to the AS400 team and wash your hands. |
As I said, our code is using MQ client. No local QM.
Regardless of writing to a remote QM on the AIX server (stopping channel in t-shooting process) or writing directly to the AS400 QM, we see this behavior.
The transaction logs indicate that there is only one message being written to the queue by the app, with or without "msg.Format = MQC.MQFMT_STRING". The only difference anywhere is that setting, which results in two messages on the queue. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 19, 2012 6:31 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
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.
Last edited by zpat on Fri Oct 19, 2012 6:34 am; edited 1 time in total |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 19, 2012 6:33 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So, to confirm.
If you write to a queue that is not being read by any applications, and then you use amqsbcgc, you then get two messages on the actual queue?
And you see that currdepth has increased by 2.
Or is it merely that the reading application says that there are two messages or processes the same data twice? |
|
| Back to top |
|
|
| pchak |
| Posted: Fri Oct 19, 2012 6:43 am Post subject: |
|
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
| mqjeff wrote: |
So, to confirm.
If you write to a queue that is not being read by any applications, and then you use amqsbcgc, you then get two messages on the actual queue?
And you see that currdepth has increased by 2.
Or is it merely that the reading application says that there are two messages or processes the same data twice? |
Both. The subscribing app also processes two messages... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 19, 2012 7:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
What do you mean "subscribing"?
You did not mention pub/sub.
There are clearly two subscriptions, then. |
|
| Back to top |
|
|
| pchak |
| Posted: Fri Oct 19, 2012 7:17 am Post subject: |
|
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
| 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! |
|
| Back to top |
|
|
| pchak |
| Posted: Fri Oct 19, 2012 8:15 am Post subject: |
|
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
| mqjeff wrote: |
What do you mean "subscribing"?
You did not mention pub/sub.
There are clearly two subscriptions, then. |
We're not running 7+ yet, so no pub/sub. :-/
That's the model that we're wanting to implement eventually, though.
App is just connected and listening... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 19, 2012 8:32 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Pub/Sub for MQ was introduced in the v5.x timeframe.
It was only made robust and firstclass in v7.
A single MQPUT only ever creates two messages if pub/sub is involved. |
|
| Back to top |
|
|
| pchak |
| Posted: Fri Oct 19, 2012 9:35 am Post subject: |
|
|
Novice
Joined: 19 Oct 2012
Posts: 11
|
| mqjeff wrote: |
Pub/Sub for MQ was introduced in the v5.x timeframe.
It was only made robust and firstclass in v7.
A single MQPUT only ever creates two messages if pub/sub is involved. |
That's why we can't go to it, until we migrate to a later version. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri Oct 19, 2012 9:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| mqjeff wrote: |
| A single MQPUT only ever creates two messages if pub/sub is involved. |
... or a Destination List with multiple destinations. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 19, 2012 9:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| rekarm01 wrote: |
| mqjeff wrote: |
| A single MQPUT only ever creates two messages if pub/sub is involved. |
... or a Destination List with multiple destinations. |
Destination lists are application level objects.
I grant the OP enough foresight to know that her (or his) own application is or is not using a destination list. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Oct 19, 2012 10:58 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| 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. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Sat Oct 20, 2012 5:12 pm Post subject: Re: Double message- .NET MQ CLient to AS400 (EBCDIC) QM |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| pchak wrote: |
code snippet:
| Code: |
msg.Format = MQC.MQFMT_STRING;
MQPutMessageOptions mputOptions = new MQPutMessageOptions();
mputOptions.Options = MQC.MQPMO_NONE;
q.Put(msg, mputOptions); |
|
It might also be useful to post the surrounding code snippet that creates and writes the msg object, the contents of the message(s) while on the queue (message headers + hex dump) for both cases (with and without Format=MQFMT_STRING), and the code snippet that gets the message(s) off the queue. |
|
| Back to top |
|
|
|
|
