Re: Decimal Data Error On Packed Number

On Fri, Jul 31, 2015 at 12:46 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

Gonna disagree with you here John.

We don't disagree at all. I'll quote my own message again for your benefit:

Well, it's not completely stupid to do trimming, but only when you're
sure you are trimming text (as opposed to arbitrary binary data).

So, when you say

<blockquote>

The purpose of the OP’s whole routine is extracting field values based on the determined start position and length as provided by the system.

Subsequent logic might determine that trimming leading and/or trailing spaces is appropriate for the resulting value but surely you should never be trimming fields as a matter of course when performing such an extraction. The spaces are a valid part of the data.

</blockquote>

all you are doing is reiterating what I said, but more verbosely, and
narrowing its scope. Which isn't always a bad thing.

My point was not to say "make sure your routine is only used on text,
so that you can use trimming". Nor was I trying to say "add logic to
your routine such that you only conditionally perform trimming if the
field you've just extracted is text". My point was intended to be a
more general one. Namely, don't even think about trimming data unless
you are sure that it's text. Clearly, the code snippet in question
does not operate on text but on arbitrary binary data.

Maybe it's a terminology thing? I purposely and carefully chose the
word "text" rather than "character", because "text" is not an RPG or
DB2 data type. And then, in case that wasn't clear enough, I also
added the "as opposed to arbitrary binary data" verbiage, which I had
hoped would address the case of data structures, as well as standalone
character-data-type variables used as "holding areas" for data which
may or may not ultimately be text.

John Y.