| Author |
Message
|
| Nigelg |
 Posted: Thu Aug 11, 2005 7:07 am Post subject: |
 |
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Frank has already explained this above, as documented behaviour.
| Quote: |
A second message descriptor is stored within the MQXQH structure as part of the message data; this is called the embedded message descriptor, and is a copy of the message descriptor that was provided by the application on the MQPUT or MQPUT1 call (with minor variations – see below for details).
The embedded message descriptor is always a version-1 MQMD. If the message put by the application has nondefault values for one or more of the version-2 fields in the MQMD, an MQMDE structure follows the MQXQH, and is in turn followed by the application message data (if any). The MQMDE is either:
– Generated by the queue manager (if the application uses a version-2 MQMD to put the message), or
– Already present at the start of the application message data (if the application uses a version-1 MQMD to put the message).
The embedded message descriptor is the one that is returned to the application in the MsgDesc parameter of the MQGET call when the message is removed from the final destination queue. |
The MQMD put by the app cannot contain any non-default values for any of the version 2 fields in the MQMD, otherwise the msg would contain an MQMDE structure at the start, followed by the msg data. If it did do so, the msg would be returned with a version 2 MQMD when the MQGET was performed from the destination queue, subject to the conditions in the MQMDE section of the APR.
Since none of the v2 fields are being used, there is no reason not to return a v1 MQMD, as documented above.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Thu Aug 11, 2005 7:09 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| before this showed the msg to be version 2 |
Isn't that what you wanted? Or is this a mistype?
Confused of Texas |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 7:11 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
| Sorry mate, maybe I am being stupid here (too many hours looking at the same stuff). Is there anyway I can find the original msg version from the browses on the Xmit Q? |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 7:17 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
Sorry Kevin,
I'll try to be clearer. The application team say they are writing the msgs as version 2. on the Xmit queue we are seeing the msgs as version 2. The issue is after the msgs go through a channel to the qlocal on the remote side they show us as version 1.
My test a few mails ago involved the app writing a msg to both the remote queue def as per normal running of the app (and browsing it on the Xmit q) and also to a qlocal, both of which show the msg type as 2.
So as a result we are no further along (or rather I am none the wiser.... which may just be I am dumb) |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Aug 11, 2005 7:17 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| Is there anyway I can find the original msg version from the browses on the Xmit Q |
If there is an MQMDE present, then almost certainly it was put as a V2. Otherwise it could have been either.
Remember, the version of the returned MQMD to an application is always the same version as the MQMD provided by that application to do the read.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Aug 11, 2005 7:19 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| on the Xmit queue we are seeing the msgs as version 2 |
Where. Are you looking at the "actual" MQMD, which will have the version of the reading application, or the "embedded" MQMD, which should always be V1.
Post a copy of the message from the XMITQ which shows the embedded MQMD. (Your first one didn't).
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 7:30 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
Here is as much of a msg as I can post, I hope this is enough, after this the msgs contain confidential information:
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 437
Format : 'MQXMIT '
Priority : 0 Persistence : 1
MsgId : X'414D51204E5045504430312020202020340EEE42200A5302'
CorrelId : X'414D51204E5045504430312020202020340EEE42200A5301'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'NPEPD01 '
** Identity Context
UserIdentifier : 'MQAdmin '
AccountingToken :
X'1601051500000044335420580FDC47AD4ABF3DF503000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '7'
PutApplName : 'NPEPD01 '
PutDate : '20050811' PutTime : '14492731'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 8574 bytes
00000000: 5851 4820 0100 0000 584D 4C5F 494E 5F50 'XQH ....XML_IN_P'
00000010: 524F 4420 2020 2020 2020 2020 2020 2020 'ROD '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 2020 2020 2020 414E 592E 5120 2020 ' ANY.Q '
00000040: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 4D44 2020 0100 0000 ' MD ....'
00000070: 0000 0000 0800 0000 FFFF FFFF 0000 0000 '........ÿÿÿÿ....'
00000080: 2202 0000 B501 0000 4D51 434F 4D32 3230 '"...µ...MQCOM220'
00000090: 0000 0000 0100 0000 414D 5120 4E50 4550 '........AMQ NPEP'
000000A0: 4430 3120 2020 2020 340E EE42 200A 5301 'D01 4.îB .S.'
000000B0: 0000 0000 0000 0000 0000 0000 0000 0000 '................'
000000C0: 0000 0000 0000 0000 0000 0000 2020 2020 '............ '
000000D0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000E0: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000F0: 2020 2020 2020 2020 2020 2020 4E50 4550 ' NPEP'
00000100: 4430 3120 2020 2020 2020 2020 2020 2020 'D01 '
00000110: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000120: 2020 2020 2020 2020 2020 2020 4D51 4164 ' MQAd'
00000130: 6D69 6E20 2020 2020 1601 0515 0000 0044 'min .......D'
00000140: 3354 2058 0FDC 47AD 4ABF 3DF5 0300 0000 '3T X.ÃœGÂJ¿=õ....'
00000150: 0000 0000 0000 000B 2020 2020 2020 2020 '........ '
00000160: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000170: 2020 2020 2020 2020 0B00 0000 4F6D 6567 ' ....Omeg'
00000180: 6120 5265 7365 6E64 5C4F 6D65 6761 5265 'a Resend\OmegaRe'
00000190: 7365 6E64 2E65 7865 3230 3035 3038 3131 'send.exe20050811'
000001A0: 3134 3439 3237 3331 2020 2020 3C4D 4552 '14492731
Fingers crossed....... |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Aug 11, 2005 7:35 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
The embedded MQMD is a V1. So, the original message could have been written using either a V1 MQMD, or a V2. If it was a V2, then none of the "additional" fields were used.
This message, once it reaches the destination can be read using a V1 or a V2 MQMD and will provide the same data in both cases. Remember, the version in the MQMD passed to the GET will dicatate which version is returned to the application.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| fschofer |
| Posted: Thu Aug 11, 2005 7:46 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
Hi,
what kind of errror does the receiving application get ?
| Quote: |
| This is causing the data in the msg to change enough that the end application is failing. |
Maybe the application support team has some bugs in their code.
Greetings
Frank |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 7:55 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
Thanks a million for the update and help. I am currently working with the team from application support, I firmly believe that this is an issue with the data, but alas I have to prove this before anyone will listen.
Could this issue possibly be related to CCSID's built into a server running w2k3 in the US? |
|
| Back to top |
|
|
| obriencm |
| Posted: Fri Aug 12, 2005 6:28 am Post subject: Thanks for the help |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
All,
Thanks for your help and advice yesterday. Funnily enough, it seems to have been an issue with the data being sent 
Thanks again,
C |
|
| Back to top |
|
|
| guest_2008 |
| Posted: Sun May 28, 2006 3:19 pm Post subject: |
|
|
Novice
Joined: 25 May 2006
Posts: 14
|
Hi All,
This topic is more useful and i have same MQMDE issue in our application,
As per our design ,we are talking the copy of message from channel using channel exit program and it is changing the MQMD values & payload information and the same message is passed to the input node and MQXQH values are verified using MRM
Input Root = MQXQH and payload in MRM Format.
Generally,
MQXQH header length is (MQMD1= XMitQ header + MQMD 1 and total is =104+ 320 = 424
Q1.The MQMD 2 header can be verified using the same MRM or required different MRM to validate MQXQH header?
Q2.What is the MQXQH header length for MQMD2 header?
I am assuming that
MQXQH header length is(MQMD2) : XMitQ header + MQMD 1+ MQMDE and total is= 104+ 320+72 =496.
Q3. what is the MQMD2 header structure sequence ?
MQXQH
MsgDesc (MQMD1)
MsgDesc (MQMDE)
RFH2
Applidata
Thanks,
[/b] |
|
| Back to top |
|
|
| EddieA |
| Posted: Sun May 28, 2006 5:10 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
How many threads are you going to "hijack" with this issue. This is the 2nd, in addition to your own thread.
Keep the discussion in one place. 
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| silent_hill |
| Posted: Mon May 29, 2006 8:44 am Post subject: |
|
|
Guest
|
|
| Back to top |
|
|
|
|
