Re: Changing a zoned decimal value with SQL

Michael,
IIRC, from S/34 times on to today, midrange systems always took low_order byte zone value as "F" for positive and "D" for negative, as defaults.
BUT, ... large systems , from S/360 times, way back to 1983, had "C" for positive, as well as "D" for negative.
So, when any customer migrated from S/360/370/4381/390... to smaller systems, or sent any file (via FTP, or whatever...) to S/34/36/38/AS400, ... Rochester was compelled to support it, so for any of the midrange systems "F" stands as the default for positive, BUT "C" was also (had to...) accepted for positive as well... Negative was "D" in both environments, so no problem on that (IIRC, negative were also accepted as "B" zoned for similar compatibility reasons, but this is not your case).
The question might be: was your "problem" file's data created on the i5 itself, or did it come (was originated from...) any S/360/370/4381/390 environment even long time ago???
HTH
-------------------------------------------------------------------------------------------------------------
Michael_Smith@xxxxxxxxxxxxxx escribió:

I have a database that was created via DDS and I'm trying to change a zoned decimal field via a SQL statement. The statement is being executed from interactive (STRSQL) SQL. The field definition is :
PREMDUE ZONED 11 2 11 25 Both PREMDUE
When I look at other posiive values via DSPPFM and toggle to hex I see the sign value, positive or negative.
Such as, if the value was +2683.55 then the hex value is F2F6F8 F3F5C5 or if it was -2683.55 then the hex value would be F2F6F8 F3F5D5.

When I try to issue my SQL command :

UPDATE table name SET PREMDue = +2683.55 WHERE blah blah = whatever

In hex, I see F2F6F8 F3F5F5

or when I try a negative value, I see F2F6F8 F3F5D5

So, my question is, why don't I see the C5 for the positive but rather, I see a F5 instead.





Michael Smith
E : Michael_Smith@xxxxxxxxxxxxxx