Re: Converting to upper case

[D.BALE@xxxxxxxxxxxxx]

Well, Jim, as long as you're certain that you're not introducing other errors
by replacing a well-written and well-tested opcode with an external procedure
that likely does not face the same QA as Barbara and Hans put their code
through.

Also, I would like my reply to Bruce last night to be considered in the
context of this discussion as well.

I really didn't intend to drag this topic out like this!  Hey, who started
this topic anyway? <vbg>

Dan Bale
IT - AS/400
Handleman Company
248-362-4400  Ext. 4952

-------------------------- Original Message --------------------------
Well, isn't that the point?  Fix the problem before you ever get one.
Then if you do get one, it's easy to fix.

I would do this type of thing for a library call, and then have other
procedures call it with added functionality.  Something like a call:

ConvertToUpper(WhatToConvert)
which would convert a string to all uppercase.

ConvertToLower(WhatToConvert)
which would convert a string to all lowercase.

ConvertProper(WhatToConvert)
which would convert a string to all lower case 'xept first letter, would
convert to upper case.  This would call convertToLower.

ConvertNameFLtoLF(WhatToConvert)
which would convert a name string "<first> <last>" to
"<last>, <first>" which would call ConvertProper.

ConvertNameLFtoLF(WhatToConvert)
which would convert sting "<last>, <first>" to proper case, calling
 ConvertProper.

ConvertNameLFtoFL(WhatToConvert)
which would convert string "<last>, <first>" to "<first> <last>" calling
 Convert Proper.

This would all be in one library (bound directory, whatever the term),
 compiled and
forgotten about except to use it.  In the future when any changes were deemed
 necessary
to be made (make it "<Last>, <first> <MI>" instead) it could be done in one
 spot.

Now the advantage to using the ConvertToUpper and ConvertToLower should show
 itself.
When, in the future, we find a better way to do it we can change it in one
 function
call, recompile the libarary/directory and be done with it.  Instead of having
 to
change it all over and compiling everything.

Maintenance on this type of library/directory structure is greatly improved
 over
not using these types of calls.  When you decide you have found the next best
 thing
to sliced bread a lot of the times you can find one spot to implement it and
 all of
your applications take advantage of it.

Regards,

Jim Langston

D.BALE@handleman.com wrote:
>
> David, thanks for the reply!
>
> It seems to me that you can't get much more centralized than just using the
> XLATE opcode.
>
> What problems with the code page?  Do not the letters A-Z & a-z all
 translate
> the same way regardless of code page?  And if not, XLATE can't handle that
 but
> an API can?  Scary thought.  If you need a procedure to correct problems
> associated with code pages, don't you still have a problem with constants
> defined in the application?
>
> I know you were just using the code page as an example, but I'm hard pressed
> to think of another example where a straight "upper" or "lower" procedure
> would offer more flexibility over XLATE.
>
> It just seems to me that you're trying to fix a problem before one actually
> exists.
>
> Dan Bale
> IT - AS/400
> Handleman Company
> 248-362-4400  Ext. 4952
>
> -------------------------- Original Message --------------------------
> Dan,
>
> Just ease of use (it can be used in an expression) and the code is
>  centralized.
> That way when you do find you have a problem (like code page) you have one
> place to fix it.  Say for example someone like Bruce Vining posts
 information
> about a really neat API that does this better than xlate.  I do wrap that
>  procedure
> into others that do more meaningful things like upper, lower, etc.  What you
> actually get is something like:
>
> C                       eval    field = upper(field1) + ' ' +
 upper(field2)...
>
> David Morris
>
> >>> D.BALE@handleman.com 12/19/00 09:54AM >>>
> David,
>
> Does your procedure provide any additional function over and above the
> standard XLATE opcode?
>      C           $LC:$UC   XLATESTR1      STR2           (RPG-III)
>      C     $LC:$UC       XLATE     STR1          STR2    (RPG-IV)
>
> Dan Bale
> IT - AS/400
> Handleman Company
> 248-362-4400  Ext. 4952
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---