| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Packed Data with Big Endian possible on Windows XP? |
« View previous topic :: View next topic » |
| Author |
Message
|
| jamesyu |
 Posted: Fri Apr 24, 2009 6:13 am Post subject: Packed Data with Big Endian possible on Windows XP? |
 |
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
Hi All,
I need to generate a message mixed with char/packed decimal (CWF) and send it to Mainframe from my message flow.
In ESQL, I set it up with Ebcdic CCSID and Encoding as below:
SET OutputRoot.MQMD.CodedCharSetId = 37;
SET OutputRoot.MQMD.Encoding = 785;
When I deploy this flow to my dev broker on AIX, the packed decimal is Big Endian which is exactly whaht I want, no problem at all.
The problem is since I am a developrer, and I need to test / change the this flow from time to time on my local broker installed on my local machine with Windows XP. With the same CCSID and Encoding setting as above (Ebcdic 37 & 785), the packed decimal is always Little Endian on Windos that bothers me all the time.
Why Little Endian on Windows with setting CCSID = 37 already in ESQL? Anyway to force Big Endian on Windows in broker?
Thanks,
James |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Fri Apr 24, 2009 7:24 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
It is never (in my humble opinion) a good idea to have packed data in the message payload. Even if you do get it working on one platform it restricts the portability of the application for the future.
As for the answer to your question....I think I would be more surprised if the Endianness didn't change between AIX and Windows. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Apr 24, 2009 10:33 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
On this one, we can't blame Bill Gates. Rather, it's an Intel issue.
Mr. Intel opted to store numerics the opposite of most of the modern world. It was a technical decision. Much has been documented on big- vs. little-endian. Do a Google search.
What you will observe is 123 sent from an Intel box arrives as 321 elsewhere.
_________________
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 |
|
|
| gbaddeley |
| Posted: Sun Apr 26, 2009 1:01 am Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| ...Mr. Intel opted to store numerics the opposite of most of the modern world... |
At a guess, I would say there are more Intel x86 architecture CPU chips on earth than any other type.
| Quote: |
| What you will observe is 123 sent from an Intel box arrives as 321 elsewhere. |
Yes, in terms of byte order. Usually there will be 2, 4, 8 bytes. I've never seen 3!
Even though the MQMD provides "encoding" flags so that numeric binary information in the message data can be interpreted across architectures, I have never seen it used it earnest. Its much easier and safer to store everthing in character format, eg. store decimal integer 123 as the string 123. The CPU cycles to convert it to and from integer and string is virtually nothing compared to the overhead CPU time in handling the message.
Glenn.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Apr 26, 2009 5:44 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
A more practical example is the Reason code in the dead-letter header.
I open a QR and MQPUT a message that ends up on the qmgr down the network. Unfortunately, the rname specified in the QR (and therefore the XQH) doesn't exist there, and the message ends up in the DLQ.
On examination of the DLH Reason code, on Windows (Intel) it's x'2508; but on z/OS, AIX, ..., it's x'0825'.
On Intel, understanding the -endian thing, I must first swap the two Reason bytes around (x'2508' becomes x'0825'). Then I transform hex to decimal (hex calculator), and voila! it's d'2085' - 2085 MQRC UNKNOWN OBJECT NAME.
If I didn't know about -endian, I'd transform x'2508' to d'9480', then Google mqrc 9480, and be completely lost.
_________________
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 |
|
|
| gbaddeley |
| Posted: Sun Apr 26, 2009 5:21 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bruce2359 wrote: |
A more practical example is the Reason code in the dead-letter header.
I open a QR and MQPUT a message that ends up on the qmgr down the network. Unfortunately, the rname specified in the QR (and therefore the XQH) doesn't exist there, and the message ends up in the DLQ.
On examination of the DLH Reason code, on Windows (Intel) it's x'2508; but on z/OS, AIX, ..., it's x'0825'.
On Intel, understanding the -endian thing, I must first swap the two Reason bytes around (x'2508' becomes x'0825'). Then I transform hex to decimal (hex calculator), and voila! it's d'2085' - 2085 MQRC UNKNOWN OBJECT NAME.
If I didn't know about -endian, I'd transform x'2508' to d'9480', then Google mqrc 9480, and be completely lost. |
Wouldn't it be easier to run a tool that understands the MQDLH and converts it into a MQRC_xxxx_xxx for you, rather than go digging through hex dumps of message data?
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Apr 26, 2009 5:26 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
Wouldn't it be easier...
Of course it would. It's called data conversion; and it's pretty well documented in the APG and APR, and ther's a SupportPac white-paper.
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
