Re: Converting to upper case

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
+---