| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MRM |
« View previous topic :: View next topic » |
| Author |
Message
|
| jefflowrey |
 Posted: Tue Feb 01, 2005 8:47 am Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| shanson wrote: |
| For a given field, you can't have it both ways. Either you have a justified field and trimming/padding applies. Or you have a non-justified field where the value is left alone. |
And having a justified field with trimming and padding, and the correct Encoding Null values makes it easier to write more flexible ESQL - as you can compare against the empty string or NULL, instead of having to compare field 1 against a string of n spaces and field 2 against a string of m zeros and field 3 against a string of p spaces.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| GYR |
| Posted: Tue Feb 01, 2005 2:38 pm Post subject: |
|
|
Acolyte
Joined: 23 Jan 2002
Posts: 72
|
| shanson - thanks for that I now have it clear in my mind and it has worked superbly so many thanks. I do not though understand the logic here and maybe i have read this incorrectly, you are saying that for an element the element is trimmed from right to left if there are characters there that match the padding character and then having got the resulting value, before output it then pads out with the padding char till it reaches the proposed length - why does it do this as it is replacing exactly what it has just removed if my understanding is correct, yes? |
|
| Back to top |
|
|
| shanson |
| Posted: Wed Feb 02, 2005 1:17 am Post subject: |
|
|
Partisan
Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley
|
The logic behind this is all to do with the distinction between the logical meaning of the data and its physical representation on the wire.
The pad char is something that only exists because the data is constrained to be a fixed length by the physical format. The real, logical, meaning of the data is the value without the pad chars. So when we create the logical message tree from such data we trim pad chars and when we send it out again we pad it out.
If you look at this from a CWF in-CWF out scenario, then yes the trimming/padding is unnecessary. But what if I was transforming from CWF to XML? Would I expect the XML data to include the pad chars? Almost certainly not. |
|
| Back to top |
|
|
| GYR |
| Posted: Wed Feb 02, 2005 3:59 am Post subject: |
|
|
Acolyte
Joined: 23 Jan 2002
Posts: 72
|
| Fair point and now I can see why, I assumed wrongly by the sounds of it that the "other" MRM formats would be treated individually witht the MRM product whereas it sounds like there is commonality between the various avail wire format types. Thanks again for the enlightenment. |
|
| Back to top |
|
|
| shanson |
| Posted: Wed Feb 02, 2005 5:42 am Post subject: |
|
|
Partisan
Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley
|
Yes, the commonality occurs at the logical level. The message tree built to represent a message is independent of the physical format of the data. This is one of the fundamental principles of the message broker product.
You can see this clearly reflected in the message model in the toolkit - an object (element, type, etc) has both logical properties and physical properties (the latter being provided when you add a CWF, XML or TDS physical format to the message set). |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
