| Author |
Message
|
| lyntongrice |
 Posted: Tue Sep 10, 2013 6:48 pm Post subject: MQPUT with MQMD format of MQHSAP returns 2142 on Linux |
 |
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
I have an application written in C that has been putting messages onto MQ using MQMD format of MQHSAP for a few years now on SUN Solaris. So as an example of the message descriptor:
Message Descriptor (MQMD)
StrucId :'MD '
Version :2
Report :00000000
Message Type :8 (Datagram)
Expiry :-1
Feedback :0 (None)
MQEncoding :0x'111'
CCSID :819
Format :'MQHSAP '
Priority :5
Persistence :1 (Persistent)
I am now running Websphere MQ 7.0.1 on Red Hat 64bit.
The code is the same and I still have the following default declarations:
| Code: |
MQMD md = {MQMD_DEFAULT};
MQPMO pmo = {MQPMO_DEFAULT}; |
Just before the MQPUT I do the following:
| Code: |
| memcpy(md.Format, "MQHSAP ", sizeof(md.Format)); |
And below is the MQPUT
| Code: |
| MQPUT(Hconn, Hobj, &md, &pmo, size, msgbuf, &CompCode, &Reason); |
And this always returns:
| Code: |
| MQPUT ended with reason code 2142 completion code 2 |
So I know there is something wrong with the MQMD .....if I change it to MQSTR it works 100%.
What could cause this change going from Solaris to Linux?
Any ideas?
Thanks for the help
Lynton |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Tue Sep 10, 2013 11:57 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I am not familiar with the MQHSAP format but the reason code MQRC_HEADER_ERROR suggests to me that it is the message content more than the message descriptor that is in error. This is just a guess you understand.
Is it possible that, being on a 64bit machine, your message data is incorrectly aligned because you have used datatypes which are not of the correct length or whatever.
Can you include the code you use to define the message and message length?
Cheers,
P.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| Andyh |
| Posted: Wed Sep 11, 2013 2:42 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
There's an inconsistency in your initial post that might relate to this issue.
You indicate that your MQMD is a version 2 MQMD, but you also indicate that you initialized the MQMD with MQMD_DEFAULT. The Version in MQMD_DEFAULT is MQMD_VERSION_1.
When a version 2 MQMD is used the header checking is a little more stringent. It was done this way so that when the header validation was tightened up (MQ V5) no existing applications would fail due to having previously misused an MQ header.
An MQHSAP header is a chained header, and the queue manager will cycle through the chained headers at various points in the code, for example if MQCCSI_INHERIT is used then at some point the correct CCSID will need to be reflected into the structures. If the chain of headers is inconsistent in some manner then an MQRC_HEADER_ERROR would be expected. |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Wed Sep 11, 2013 10:17 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
Thanks for the comments, much appreciated.
I guess I confused the matter earlier, the following was how it used to look on SOLARIS
| Code: |
Message Descriptor (MQMD)
StrucId :'MD '
Version :2
Report :00000000
Message Type :8 (Datagram)
Expiry :-1
Feedback :0 (None)
MQEncoding :0x'111'
CCSID :819
Format :'MQHSAP '
Priority :5
Persistence :1 (Persistent) |
My code definetly uses the following on my Linux box:
| Code: |
MQMD md = {MQMD_DEFAULT};
MQPMO pmo = {MQPMO_DEFAULT}; |
The thing that is really making me scratch my head is that lets just say as a small test on VERSION I just make the mqmd format MQSTR,when I generate a report using MQ Visual Edit is says the mqmd version is 2? See attached report.....Yet I default it and never change the version?
As I said I am running MQ 7.0.1
Report from MQ Visual Edit of message showing that MQMD is version 2 even through if I print out the version just before the MQPUT it is version 1
Message Descriptor
Version 2
Message Type: MQMT_DATAGRAM
Message Priority: 0
Message Persistence: MQPER_PERSISTENT
Put Date: 2013-09-11
Put Time: 20:09:34.520
Expiry Interval: MQEI_UNLIMITED
Reply-To Queue
Reply-To Queue Manager QM01
Backout Count: 0
Report: 0
Original Length: -1
Feedback Code: MQFB_NONE
User ID: root
Put-Application Type: MQAT_UNIX
Put-Application Name: idoclink_outbou
Application Identity Data:
Application Origin Data:
Accounting Token: X'0130000000000000000000000000000000000000000000000000000000000006'
Message ID: X'414D5120514D30312020202020202020FF933052031E0020'
Correlation ID: X'000000000000000000000000000000000000000000000000'
Group ID: X'000000000000000000000000000000000000000000000000'
Logical Sequence Number: 1
Offset: 0
Message Flags: 0
Format MQSTR
Message Data Length: 5839
Coded Character Set ID: 819
Encoding: 273
Could it be that the put message options are somehow wrong? But I do not change it....mmmm.....
This has really got me stumped ;-(
Any help greatly appreciated 
Lynton |
|
| Back to top |
|
|
| Andyh |
| Posted: Wed Sep 11, 2013 10:41 am Post subject: |
|
|
Master
Joined: 29 Jul 2010
Posts: 239
|
If you're printing the MQMD following an MQGET then the MQMD will reflect the version of MQMD passed to the MQGET, not the version of the MQMD used on the corresponding MQPUT.
The underlying problem here is VERY likely to be with the message payload (in particular the MQ headers pre-pending any user data, e.g. MQHSAP), not the MQ headers passed explicitly on the MQI call (e.g MQPMO,MQMD).
Have you traced the issue ? if so does an lrcE_HEADER_ERROR appear, and if so from what MQ function ? |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Wed Sep 11, 2013 10:45 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Thanks for the info on the MQ header before the data.....let me look at the data again, I have 108 bytes of SAP header data I think.....and the HEX of those bytes is exactly the same as if I use a tool like MQ Visual Edit to PUT a message on with mqmd format = MQHSAP...
But let me dig some more....thanks |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Wed Sep 11, 2013 10:47 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
Stupid question but how can I trace the issue further? Must I turn on tracing on MQ? How is that done?
Sorry to be a pain...
Lynton |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Wed Sep 11, 2013 11:15 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
I turned on the trace .....sent a message with MQHSAP and then turned off the trace....
I can kinda view the data in the TRC file but would be better to use some trace viewer for Linux if thier is one....
I would copy the trace in here but it has too many funny chars ;-( |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Wed Sep 11, 2013 12:19 pm Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
Ok, lesson learnt....on Linux I needed to specify the following before the MQPUT in order for it to work....
md.Encoding = 273;
md.CodedCharSetId = 819;
Seems fine now.....
Lynton |
|
| Back to top |
|
|
|
|
