| Author |
Message
|
| GYR |
 Posted: Fri Jan 28, 2005 9:04 am Post subject: MRM |
 |
|
Acolyte
Joined: 23 Jan 2002
Posts: 72
|
Can somebody tell me in the MRM where this possible data substitution may be taking place, i have an incoming legacy ascii bitstream where say the first ten characters are XXXXXXxxxx then 10 blanks and then 10 character zeros. The message is passed sucessfully bu the trace now shows my field values below:
fielda = 'XXXXXXxxxx'
fieldb = ''
fieldc = ''
does the parser trim the fields? are they trimmed for presentation with the trace and I am not actually seeing the true field value and why would the zeros be turned to empty field value too? I had noticed on the properties of the message set that boolean null values is represented as a string of zeros so is it converting for me. Looking thro the manuals was not much on the enlightenment scale. Thanks. |
|
| Back to top |
|
 |
| kimbert |
| Posted: Mon Jan 31, 2005 4:44 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Which version are you on?
Which message format are you using (CWF / TDS )?
What does your message set look like (specifically, how are elements A, B and C defined)?
The parser does trim fields if they are fixed-length fields, but you can ask it not to. I cannot be more specific until you provide the above info. |
|
| Back to top |
|
|
| GYR |
| Posted: Mon Jan 31, 2005 6:03 am Post subject: |
|
|
Acolyte
Joined: 23 Jan 2002
Posts: 72
|
hi,
First the version is v5.0 CSD4. The elements are set as string with fixed length and a value of 10,10,and 10. The padding character has been set to SPACE,'0' and '0' respectively but this should only affect the outgoing message not the incoming. When i put the values XXXXXXXXXX44444444446666666666 then the field values are sorted no worries, BUT if i put in "XXXXXXXXXX 0000000000" i.e ten crosses, ten Blanks and ten character zeros then the trace is showing that this has been interprested as Ten crosses (so no problem) but the next 2 elements are '' (empty) so it must be interpreting in some way as I want to see ten blanks and ten character zeros. Thanks for the response. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 31, 2005 6:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What is the "Logical Null" value of the fields?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| GYR |
| Posted: Mon Jan 31, 2005 6:56 am Post subject: |
|
|
Acolyte
Joined: 23 Jan 2002
Posts: 72
|
| The binary reps set at the message set level are default values so booelan true = 00000001, false= 00000000 and bollean null is 00000000 also. At field level the Encoding Null is set to NullLogicalValue and the Encoding Null value is unset or blanks basically. I know there are bits in there to deal with null handling but these are to me legit characters (blanks and char zeros) and seem to work fine with the same settings on message sets i have that have imported across from V2.1. These elements are global not local although I don't beleive that makes a difference. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 31, 2005 7:07 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You should read the documentation on "Encoding Null" - as it determines how physical values are turned into NULLs in the logical message tree.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| GYR |
| Posted: Mon Jan 31, 2005 7:26 am Post subject: |
|
|
Acolyte
Joined: 23 Jan 2002
Posts: 72
|
| Thats is the bit i have read and although it is not greatly helpful I think that is what is happening that the values are being interpreted, but i don't want it to do that, thats the point I don't want the MRM to interpret the zeros or blanks as nulls I want them to be left exactly as they are, the data originates from an EBCIDIC platform (AS400) where default values are zeros for numerics and blanks for alphanumerics, null does not even exist as such on as400. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 31, 2005 8:16 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
What you want, then, is Encoding Null to be set to NULLLiteralValue.
| http://publib.boulder.ibm.com/infocenter/wbihelp/index.jsp?topic=/com.ibm.etools.mft.doc/ad06830_.htm wrote: |
If you select the NULLLiteralValue option, the value entered for the Encoding Null Value property is directly substituted as if it were a string value. The value is case insensitive. For fixed length objects, the literal value must be no longer than the length of the object.
If the literal value is shorter, the Encoding Null Value is padded (using Padding Character) on output. On input, if the NULLLiteralValue's length does not match the Length field, you should set the message set level Trim Fix Len String property so that padded nulls are correctly parsed. |
At least, if you're using TDS. If you're using CWF, you can use NULLLiteralFill instead.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| GYR |
| Posted: Mon Jan 31, 2005 12:26 pm Post subject: |
|
|
Acolyte
Joined: 23 Jan 2002
Posts: 72
|
| Have systematically now tried all the options of this putting in replacement chars etc as per book defintion, this is CWF not TDS but it makes no difference to the message content post Input Node. On the queue the message still contains the blank and zeros when viewed thro rfhutil, the trace makes them empty fields post get. Frustration is an understatementt here !!!!! |
|
| Back to top |
|
|
| JT |
| Posted: Mon Jan 31, 2005 1:08 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
| Try using the interactive debugger. Set a breakpoint after the MQInput node and see what the data looks like according to the parser. |
|
| Back to top |
|
|
| GYR |
| Posted: Mon Jan 31, 2005 1:21 pm Post subject: |
|
|
Acolyte
Joined: 23 Jan 2002
Posts: 72
|
| Done that and its the same that is in the trace, tried the debugger after the trace just to make sure the trace was printing out correct. |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Feb 01, 2005 2:17 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Go to the element definitions of B and C and set 'String Justification' to 'Not Applicable'. (This setting affects parsing as well as writing). |
|
| Back to top |
|
|
| shanson |
| Posted: Tue Feb 01, 2005 7:18 am Post subject: |
|
|
Partisan
Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley
|
| Someone said earlier that trimming of padding characters in CWF only occurred on output. Not true, it happens on input as well. This certainly explains why the field containing 00000000 got trimmed to the empty string - the padding character was '0'. I don't know why the field containing spaces was trimmed, unless the padding character was SPACE. Follow kimbert's advice above, and turn off justification to stop trimming occurring. |
|
| Back to top |
|
|
| GYR |
| Posted: Tue Feb 01, 2005 7:58 am Post subject: |
|
|
Acolyte
Joined: 23 Jan 2002
Posts: 72
|
Thanks everybody here I am trying some of the suggestions here. I would like to add the quoted excert from the manual shanson where i can see nothing to suggest that the incoming message is padded and the first line of this quote is not definitive, this would also seem unlikely as until parsed the MRM will not know how many bytes to pad out to satisfy the fixed length, the quote here suggests the same if i read it correctly that the padding is done to satisfy the length and this point the tree is being constructed for the outputside. The setting of the Not Applicable will do what to the values in that element though? my problem will come when there may be legit values i.e other values than blanks and zeros in those fields that do need justification of some sort should i need to do any string manipulation further down the line, otherwise it means additional work to determine whether the values are right or left justified.
| Quote: |
The padding character is used to fill out the remaining character positions when the string length is less than the specified string size. If you have set the Physical Type property to Fixed Length String, and the String Justification property is either Left Justify or Right Justify, set this character in one of the following ways:
Select NUL, '0', or SPACE from the drop-down list.
Enter a character between quotes, for example "c" or 'c', where c is any alphanumeric character.
Enter a hexadecimal character code in the form 0xYY where YY is a hexadecimal value.
The choice of which of these padding character forms is used for an MRM element will depend on the padding character required and whether the padding character is to be subject to data conversion. In most cases the specification of a padding character will be sufficient and when this padding character is used, it will be converted to the target codepage of the output MRM message being generated. If a padding character is required that cannot easily be entered in the padding character field, then the Unicode mnemonic format can be used to specify the required character. When used, this Unicode value will also be converted to the target codepage of the MRM message being generated. If a padding character is required that is not subject to data conversion, then the hexadecimal format can be used. This gives the option of specifying a padding character that is inserted directly in the output message. If this format is used then you must ensure that this hexadecimal is valid for the codepage of any output messages that are created using these MRM definitions.
If you are converting a message from one code page to another, then you must ensure that the converted value of the padding character is valid for this codepage. For example, when converting from ASCII to the codepage 500, if you have specified the numeric 8 as your padding character then this is converted from 0x08 to 0x15, the ASCII and EBCDIC representations of 'back space'.
There is a currently a restriction that the value of your padding character should not be greater than U+007F. You should note that if you enter a Unicode mnemonic or numeric value, it is considered to be the character represented by that number in UTF-8.
Enter a Unicode value in the form U+xxxxxx where xxxxxx is a Unicode value specified in hexadecimal. The maximum length of the string you can enter is 10.
Select the default value of an empty string.
|
|
|
| Back to top |
|
|
| shanson |
| Posted: Tue Feb 01, 2005 8:24 am Post subject: |
|
|
Partisan
Joined: 17 Oct 2003
Posts: 344
Location: IBM Hursley
|
The manual words could be clearer, but they do apply to both input and output. I'll get the words improved for the next release.
On input x bytes are consumed from the input message as determined by the length count and length unit properties, then if the justification is left/right the right/left of the data is compared to the padding character and the data is trimmed if matched (repeated until no more matches). The result is added to the message tree.
On output if the message tree contains a value shorter than implied by the length count and length unit properties, then if the justification is left/right the right/left of the data is padded with the padding character until the length is met. The result is added to the output message.
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. |
|
| Back to top |
|
|
|
|
