On 12/2/2010 1:35 PM, hockchai Lim wrote:
The feature that I'm speaking of is its ability to move a char string into a
numeric field.
You want to put the raw bytes of a zoned decimal field into a character
field. Why would you want to do that? The only reason I can come up
with is "because we've always done that, and we've built an application
around that behavior."
If you must, you can certainly do that with data structures or an API
like memcpy(). Or you can write a procedure that you can use any time
you need to do it in the future, and just call it from everywhere.
But as a general "feature", I'd call it a misfeature. It seems to me
that there are two main reasons to convert a numeric field to character:
1) Data interchange... creating a file to send to someone else (EDI,
XML, WebService, etc.)
2) For a person to read in a message/report/web page, etc.
For data interchange, putting the field in human-readable format is much
better than raw zoned decimal. Why? Because, relatively few
programming environments understand zoned decimal. Some languages (such
as C, for example) might assume leading zeroes to mean that the number
is octal. Many/most programming environments won't understand negative
numbers in zoned format. (Some, such as the } character, might not even
translate reliably between character sets.) Plus, they have to assume a
decimal place based on external documentation instead of plainly seeing
where the decimal place is supposed to be.
Again, the only advantage of "zoned in char" is "because we're required
to by a customer" or "we've always done it that way, and it'd be hard
to change it now."
For human-readable fields, human readable format (with zeros suppressed,
decimal point added, negative numbers represented by the - symbol) is
very clearly, and obviously better.
So why would you want to use zoned-in-char? The only thing I can come
up with is because RPG/400 gave you little choice, and you (or someone
else) built a system around that.
midrange.com
