× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hey you added to the verbosity level!

All I meant was that I didn’t think that a routine designed to extract the raw data from a file should be trimming. Period. It should just extract the raw data. Trimming, if required, should be a function of the logic using the data. Just semantics.


On Jul 31, 2015, at 1:29 PM, John Yeung <gallium.arsenide@xxxxxxxxx> wrote:

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.
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.