| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQPut1 XML with Delphi, receives null char at end of msg? |
« View previous topic :: View next topic » |
| Author |
Message
|
| edwardkoo |
 Posted: Mon Jan 25, 2010 2:03 am Post subject: MQPut1 XML with Delphi, receives null char at end of msg? |
 |
|
Newbie
Joined: 19 Jan 2010
Posts: 6
|
Hi,
I use MQPUT1 in my Delphi app to send XML messages to an MQ receiver managed by my customer. They received my message but encountered XML parser error and after some checking they found my message contains null character #0 at the end of the message.
Below is the function declaration at MQIC.pas
procedure MQPUT1 (Hconn:MQHCONN;ObjDesc:PMQOD;MsgDesc:PMQMD;PutMsgOptions:PMQPMO;BufferLength:MQLONG;Buffer:PChar;CompCode, Reason:PMQLONG);cdecl;external 'mqic32.dll';
Since the Buffer param is of type PChar which is pointer to null terminated string and this means my string should contain #0 at the end.
At first, the XML message i constructed indeed has #0 being manually added to it, then i remove #0 from my message yet my customer still encounter same error. The message still has #0 at the end, this makes me suspect if MQPUT1 itself automatically add #0 to the message?
Below is my delphi MQPUT1 code,
Buffer := PChar(edPut.Text);
BufferLength := Length(edPut.Text);
ObjDesc := MQOD_DEFAULT;
ObjDesc.ObjectName := 'SENDQ' + #0;
MsgDesc := MQMD_DEFAULT;
MsgDesc.MsgId := MQCI_NONE;
MsgDesc.PutApplType := MQAT_WINDOWS_NT;
MsgDesc.Report := MQRO_NONE;
MsgDesc.MsgType := MQMT_REQUEST;
MsgDesc.ReplyToQMgr := '';
MsgDesc.ReplyToQ := 'RESPQ' + #0;
MsgDesc.Format := MQFMT_STRING;
MsgDesc.CodedCharSetId := MQCCSI_Q_MGR;
PutMsgOptions := MQPMO_DEFAULT;
PutMsgOptions.Options := MQPMO_FAIL_IF_QUIESCING or MQPMO_NEW_MSG_ID; //or MQPMO_NEW_CORREL_ID;
MQPUT1 ( FHconn, @ObjDesc, @MsgDesc, @PutMsgOptions, BufferLength, Buffer, @Compcode, @Reason );
if CompCode <> MQCC_OK then
ShowMessage('PUT1 Failed')
else
begin
mmGet.Text := 'MQPut1 - ' + IntToStr(BufferLength);
end; |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Jan 25, 2010 3:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Try switching the PChar to a normal Delphi string, see if that changes.
MQPUT1 should not be affecting the buffer at all. |
|
| Back to top |
|
|
| edwardkoo |
| Posted: Mon Jan 25, 2010 6:16 am Post subject: |
|
|
Newbie
Joined: 19 Jan 2010
Posts: 6
|
| mqjeff wrote: |
Try switching the PChar to a normal Delphi string, see if that changes.
MQPUT1 should not be affecting the buffer at all. |
Hi jeff,
The parameter for Delphi MQPUT1 is of type Buffer:PChar and therefore it won't allow me to put normal string. Though, there's a way to put it as below
MQPUT1 ( FHconn, @ObjDesc, @MsgDesc, @PutMsgOptions, BufferLength, @edPut.Text[1], @Compcode, @Reason );
where Buffer is substitute with the actual string pointer but the result is still same. I have even tried to change the parameter Buffer:PChar to Buffer: array of char type and pass in array of characters and i have make sure no #0 in the char array and still the same result.
I have got more info from my customer, their message browser shows that the message i sent is of type MQSTR and the usual message they receive from other vendor is of type RFH. I am guessing RFH message is sent by Java MQ client which does not have null character whereby the mqic32.dll use by my delphi app is written with C/C++ and employ null terminated string.
Hope there's a way to overcome this without my customer needed to change their code to handle null character from my side... |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 25, 2010 7:01 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| edwardkoo wrote: |
| I have got more info from my customer, their message browser shows that the message i sent is of type MQSTR and the usual message they receive from other vendor is of type RFH. I am guessing RFH message is sent by Java MQ client which does not have null character whereby the mqic32.dll use by my delphi app is written with C/C++ and employ null terminated string. |
DISCLAIMER: My Delphi is slightly worse than my Java so all advice should be viewed with caution.
A type of RFH just means that the message has an RFH header on it, typically because the message has been put using the JMS methods. It's unlikely that this would cause any issues, but more likely it's the difference between the way Java & Delphi handle strings.
As a side note, if the client application is expecting a message with an RFH and your application is not supplying one, won't they still have to change their code to cope with this? Or are you planning to put an RFH on your message in later development?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| edwardkoo |
| Posted: Wed Jan 27, 2010 7:33 pm Post subject: |
|
|
Newbie
Joined: 19 Jan 2010
Posts: 6
|
Hi Vitor,
Right now they can receive full msg except the end of msg contains #0 which their XML parser raise exception. Seems overkill to construct a RFH msg
to get rid of that #0...
I think i'll try to build a C version of mq client to test MQPUT1 with it and see if same thing will happen. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 27, 2010 8:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| edwardkoo wrote: |
Right now they can receive full msg except the end of msg contains #0 which their XML parser raise exception. Seems overkill to construct a RFH msg
to get rid of that #0... |
That wasn't the point I was trying to make. My point was that an RFH message is often added by a JMS app (which doesn't null terminiate it's strings so far as I know) so this is probably why existing messages don't have a null at the end of the buffer. My 2nd point is that if their exisiting messages have an RFH on the front of their XML, and your Delpi isn't adding an RFH, then logically they'd have to amend their code to deal with the lack of header.
| edwardkoo wrote: |
| I think i'll try to build a C version of mq client to test MQPUT1 with it and see if same thing will happen. |
I'd certainly expect a string generated by C to be null terminated. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Jan 28, 2010 3:42 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Vitor wrote: |
| edwardkoo wrote: |
| I think i'll try to build a C version of mq client to test MQPUT1 with it and see if same thing will happen. |
I'd certainly expect a string generated by C to be null terminated. |
MQPUT/MQPUT1 of a C string should use strlen(MsgBuffer) as the message length. This is so that the message data put to the queue does not include a null terminator character.
Its not a good idea to have null terminators on MQ message data in queues, it could upset consumer apps that don't expect them.
After doing MQGET in C its normal to convert the returned buffer to a string by adding a null terminator, ie. GetBuffer[GetMsgLength] = '\0'; Just make sure the buffer is allocated with a size at least one greater than the 5th argument passed to MQGET !
_________________
Glenn |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
