Re: Moving a field and removing blanks

I don't run into this situation a lot. But I know I've been asked about how
to perform this MOVE feature in free form several time before and my answer
is always: use DS overlay or %dec+division and make sure to handle blank
string, otherwise the program is going to blow up. I've not run into the
situation where the string has a N at the tail end that indicates the value
is a negative (Now, that would be a bit harder to handle).

well, remember this thread
news:mailman.13071.1289394647.2702.rpg400-l@xxxxxxxxxxxx?

Obviously, we all can code around the lack of this feature in free form.
I'm just saying that I miss that feature sometime :)



"Scott Klement" <rpg400-l@xxxxxxxxxxxxxxxx> wrote in message
news:mailman.17611.1291328387.2702.rpg400-l@xxxxxxxxxxxxxxx

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.