| Author |
Message
|
| obriencm |
 Posted: Thu Aug 11, 2005 5:23 am Post subject: Problem with message version changing from 2 to version 1 |
 |
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
Hi all,
I am having an issue when I am sending msgs from a MQSeries (v5.3 CSD5) qmgr running on win2k to a MQSeries (v5.3 csd9) qmgr running on w2k3. The message version is changing from version 2 to version 1. This is causing the data in the msg to change enough that the end application is failing. Both qmgrs have a CCSID of 437 so no conversion should be taking place at all. Has anyone come across something like this before?
Help.......
Thanks in advance.
C. |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Thu Aug 11, 2005 5:27 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Is it at all possible that the application code setting the version to 1? |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 5:42 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
| Sorry to say no. The application is sending the msgs as version 2. I have stopped the channels and take a browse of the msgs to prove this. I have then taken a browse on the remote system and they have been changed to version 1. |
|
| Back to top |
|
|
| xxx |
| Posted: Thu Aug 11, 2005 5:46 am Post subject: |
|
|
Centurion
Joined: 13 Oct 2003
Posts: 137
|
| How about the data conversion parameter on the Sender channel ? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 11, 2005 5:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So, at what point do you observe that the message has a different MQMD version?
On the XMITQ on the sending side? On the destination qlocal on the receiving side? Inside the application?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 5:50 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
Thanks for the replys,
The data conversion flag is set to "NO" on the sender channel
i see the change when I browser the qlocal on the destination side. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Aug 11, 2005 5:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Can you post amqsbcg output of the message on the XMITQ and the message on the qlocal?
Can you compare the output when the sending program writes to a qlocal instead of a qremote/qcluster?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 5:54 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
Here is the browse of the msgs you requested:
First the msg header as written by the application:
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'414D51204E5045504430312020202020340EEE42200A2702'
CorrelId : X'414D51204E5045504430312020202020340EEE42200A2701'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'NPEPD01 '
** Identity Context
UserIdentifier : 'MQAdmin '
AccountingToken :
X'1601051500000044335420580FDC47AD4ABF3DF503000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '7'
PutApplName : 'NPEPD01 '
PutDate : '20050811' PutTime : '12404308'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 1105 bytes
Now the msg on the destination side:
MQGET 1 BufferLength = 1024, DataLength = 778
****Message descriptor****
StrucId : 'MD ' Version : 1
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 437
Format : 'MQCOM220'
Priority : 0 Persistence : 1
MsgId : X'414D51204E5045504430312020202020340EEE42200A1503'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'NPEPD01 '
** Identity Context
UserIdentifier : 'mqadmin '
AccountingToken :
X'1601051500000044335420580FDC47AD4ABF3DF503000000000000000000000B'
ApplIdentityData : ' '
** Origin Context
PutApplType : '11'
PutApplName : 'Omega Upload\Omegaupload.exe'
PutDate : '20050811' PutTime : '11245220'
ApplOriginData : ' '
**** Message **** |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Aug 11, 2005 6:21 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Try putting the message on a local queue and looking at the version on there. The MQXMIT header will be being put on there by the queue manager not the application. |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 6:24 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
| Thanks. I am working on that at the moment. I have to get the application support teams to work with me.... and at the moment they are jumping up and down with joy because they are blaming MQ |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Thu Aug 11, 2005 6:28 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| and at the moment they are jumping up and down with joy because they are blaming MQ |
Lets see them jump up and down when it turns out to be their application code....as it invariably will be.  |
|
| Back to top |
|
|
| fschofer |
| Posted: Thu Aug 11, 2005 6:32 am Post subject: |
|
|
Knight
Joined: 02 Jul 2001
Posts: 524
Location: Mainz, Germany
|
Hi,
the MQMD (first one) you see when you get from the XMIT Queue is generated by the MCA.
The original MQMD (second one) which you can later get on the destination side is stored elsewhere.
Greetings
Frank
Application Programming Reference:
| Code: |
Usage: A message that is on a transmission queue has two message descriptors:
One message descriptor is stored separately from the message data; this is called
the separate message descriptor, and is generated by the queue manager when the
message is placed on the transmission queue. Some of the fields in the separate
message descriptor are copied from the message descriptor provided by the
application on the MQPUT or MQPUT1 call (see below for details).
The separate 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 transmission queue.
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. |
|
|
| Back to top |
|
|
| JT |
| Posted: Thu Aug 11, 2005 6:35 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Quote: |
Version (MQLONG)
Structure version number.
The value must be one of the following:
MQMD_VERSION_1
Version-1 message descriptor structure.
This version is supported in all environments.
MQMD_VERSION_2
Version-2 message descriptor structure.
This version is supported in the following environments: AIX, HP-UX, z/OS, OS/2, Compaq OpenVMS Alpha, Compaq NonStop Kernel, OS/400, Solaris, Linux, Windows, plus WebSphere MQ clients connected to these systems.
Note:
When a version-2 MQMD is used, the queue manager performs additional checks on any MQ header structures that may be present at the beginning of the application message data; for further details see the usage notes for the MQPUT call.
Fields that exist only in the more-recent version of the structure are identified as such in the descriptions of the fields. The following constant specifies the version number of the current version:
MQMD_CURRENT_VERSION
Current version of message descriptor structure.
This is always an input field. The initial value of this field is MQMD_VERSION_1. |
The most likely scenario would seem to be that someone dropped the ball and didn't set this field to Version 2. |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 6:36 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
| fingers crossed..... I'm going over to them now, hoping to take the smile off their faces.... I'll let you know how I get on. |
|
| Back to top |
|
|
| obriencm |
| Posted: Thu Aug 11, 2005 6:57 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2002
Posts: 64
Location: Ireland
|
well that didn't help at all, saddly. I got a msg put to the remote queue and browsed it from the Xmit queue, as before this showed the msg to be version 2. However when I got the same msg put to a local queue, it also shows up as version 2. 
Any other ideas? |
|
| Back to top |
|
|
|
|
