| Author |
Message
|
| lyntongrice |
 Posted: Thu Oct 27, 2011 4:53 am Post subject: How to read "Message Identifier Bytes" in C code? |
 |
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
I can happily read the MDMQ MSGID from the message just read from a queue, but how can I get the "message identifier bytes"? Do I have to convert the "MSGID" string into a byte array?
Is thier any other structure I have to use to read the MSGID BYTES?
Thanks for the help
Lynton |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Oct 27, 2011 5:00 am Post subject: Re: How to read "Message Identifier Bytes" in C co |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lyntongrice wrote: |
| Do I have to convert the "MSGID" string into a byte array? |
It's already a byte array. It's not a string and shouldn't be treated as such. The id fields are byte arrays for good & sufficient reason. Trying to use them as character strings without understanding this is a cause of much newbie heartache when it bites you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Thu Oct 27, 2011 5:28 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
OK, sorry....I see they are defined as MQBYTE24....but if I debug it in GDB I will see what seems to be "text"....things like "AMQ" etc in it....when I am hoping for a GUID looking type thing....
If I look in the MQ Explorer on my Linux box I can see the MSGID and MSGID bytes....I essentially want to write a file name with the message identifier BYTES, not the "text looking" thingie....
Thanks again |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 27, 2011 5:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
According to the WMQ APR and APG documentation, datatype BYTE24 means that there are 24 bytes of bits - not characters. CHAR24 means 24 bytes of characters.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 27, 2011 5:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lyntongrice wrote: |
| if I debug it in GDB I will see what seems to be "text"....things like "AMQ" etc in it....when I am hoping for a GUID looking type thing.... |
If you take a few moment reading the description of the ids, you'll find your expectation that msgid=guid will be managed.
By default, the id is built using text items so if it's viewed using the same code page as the originating queue manager it will look like text.
It's not.
And if you don't like the format, change it. Your previous posts indicate your willingness to fight the software rather than working with it.
| lyntongrice wrote: |
| If I look in the MQ Explorer on my Linux box I can see the MSGID and MSGID bytes....I essentially want to write a file name with the message identifier BYTES, not the "text looking" thingie.... |
So if you want to use the hexadecimal representation of the id bytes, you'll need to do the same conversion as the MQ Explorer does. It does this to underline that the id is a string of bytes, and conceal that it used to be text once from the unwary.
This is a C coding issue not a WMQ one. I'd also question the wisdom of exposing a message as a file in this way.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 27, 2011 6:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Don't use files for anything other than static properties that are used by exactly one application.
Use a message oriented protocol to exchange data between two applications. This can be HTTP or SMTP or WMQ or anything else. But don't use files. Files are *BAD*. They are non-transactional and non-deterministic and significantly more complex to work with than you are taught in school.
The problem of knowing that a file is available and ready to be read is a classic example of the Halting Problem, in that it is directly the question of "has the program writing the file stopped writing the file". You can't tell.
Files are BAD. DO NOT USE THEM. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Oct 27, 2011 6:19 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
File (and records) can also be processed more than once by accident, something has to clean up the files when finished with them, you can't write to files from multiple threads at same time, and so on.
Think of queues as "magic" files without all these problems.... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 27, 2011 6:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
Some considerations for BYTE datatypes: they are strings of bits, and therefore are platform-neutral.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Fri Oct 28, 2011 3:43 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
Thanks for the comments, much appreciated.
I still need to get the HEX value for the MSGID in C, I wrote some code and it "nearly works" but not 100%.
On the WMQ explorer on my Linux box message 1 in the queue has a message identifier of "AMQ QM01" (at least that it what it looks like), and the bytes are below as displayed in the explorer:
| Code: |
00000 41 4D 51 20 51 4D 30 31--20 20 20 20 20 20 20 20 |AMQ QM01 |
00010 BD F4 A8 4E A2 A3 06 20-- |...N... | |
Now when my code runs I pick up that same message id and try convert it to a hex string.
The exact message id is:
AMQ QM01 \275\364\250N\242\243\006
And after running through my conversion i get:
414D5120514D30312020202020202020FFFFFF4EFFFF6
As you can see it is slightly different to the one that the WMQ Explorer shows, and idea what i am doing wrong here? omething
I assume it is me converting from the MQBYTE24 to char....something is going wrong there...
Below is a small sample program that produces the "wrong result".....i assune i must use a byte array instead of char?
The output for the following is:
Result: 414D5120514D30312020202020202020FFFFFF4EFFFF6
| Code: |
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
int main(){
char name[41]="AMQ QM01 \275\364\250N\242\243\006";
char buffer[82]="";
char *pbuffer = buffer;
int rc = convertStrToHex(buffer, name);
printf( "Result: %s\n", pbuffer );
}
return 0;
}
int convertStrToHex(char *buffer, char str[10]){
int len = strlen(str);
int i;
for( i = 0; i < len ;i++ ){
sprintf(buffer, "%X", str[i]);
buffer +=2;
};
} |
Thanks for the help 
Lynton |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Oct 28, 2011 4:08 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Have you considered reviewing the sample code that comes with MQ?
Perhaps there exists a program that has already 'solved' this problem for you.
Have you considered listening to the rest of the advice in this thread?
You should strongly talk to whoever is insisting that you write data out to a file and get them to clarify why they can't read the messages from the queue in the first place.
You are going down a road that will lead you to several different sorts of production problems and unreliable events. You can choose to listen to the experience of others, or you can choose to repeat history. |
|
| Back to top |
|
|
| lyntongrice |
| Posted: Fri Oct 28, 2011 4:47 am Post subject: |
|
|
Acolyte
Joined: 26 Sep 2010
Posts: 70
|
Hi there,
I have listened to your posts and appreciate them all.
I am using proper transactions in WMQ but in the scenario I posted that has actually happened whereby a message is sent to SAP and MQ goes down before I can commit the message off the queue.....then on startup it gets processed again....
That is why I am looking for a "small transaction folder" whereby I write the message immediatly after it has been committed to SAP but BEFORE commited off MQ.....then after commited off MQ I delete the file.....that will prevent duplicate messages coming out in the scenario I depicted....
How would you handle that scenario? It is most certainly possible to have duplicate messages if MQ goes down after message commit into SAP....
Chat later, thanks again
Lynton |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 28, 2011 4:57 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| lyntongrice wrote: |
I still need to get the HEX value for the MSGID in C, I wrote some code and it "nearly works" but not 100%. |
Perhaps if you think of the MsgId as containing a .jpg or .gif, then you should appreciate that any conversion of the BYTES will corrupt its meaning.
BYTES are platform neutral - eight bits == eight bits.
You might want to contact the folk at SAP to see if they have a solution for you. SAP provides the bridging software to/from WMQ.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 28, 2011 4:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lyntongrice wrote: |
| How would you handle that scenario? It is most certainly possible to have duplicate messages if MQ goes down after message commit into SAP.... |
As indicated on this previous thread of yours. As has been said on that thread and this one, you're not only reinventing the wheel but adapting the spokes to be rods with which you can beat yourself.
Work with the software, not against it. Put the UoW boundaries where they need to be, not where the current design seems to have them.
In your solution what happens if whatever brings WMQ kills your application before it can delete the file? You're no further forward.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mattfarney |
| Posted: Fri Oct 28, 2011 8:34 am Post subject: |
|
|
Disciple
Joined: 17 Jan 2006
Posts: 167
Location: Ohio
|
I have a logging program that turns the msgId and corId into printable text.
I had to add a structure like this to get the conversion to work. Some of the bytes converted to FFFFFF52 instead of 52.
| Code: |
char hexValueHold[8];
string msgIdAsHex;
string bufferFix;
memcpy(hexValueHold," ",8);
sprintf(hexValueHold,"%02X",hold[i]);
bufferFix = hexValueHold;
if (bufferFix.substr(0,6) == "FFFFFF")
bufferFix = bufferFix.substr(6,2);
msgIdAsHex.append(bufferFix);
|
-mf |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 28, 2011 8:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| mattfarney wrote: |
| I have a logging program that turns the msgId and corId into printable text. |
No, you don't.
Not all BYTE (hex) characters are printable.
I repeat what you've been told here more than once: BYTES are NOT characters.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
