Why would you get rid of the service program? Whether the converting to uppercase is done with SQL, manually handled in RPG, or calls out to an API, having it in one location is perfect for this logic. Would you really expect every programmer who wanted to convert something to uppercase to code for an API instead of binding in a service program and calling it? The overhead here is minimal and only occurs once (upon start of the program, or delayed until the first time the service program is used).
Kurt Anderson
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Robert Houts
Sent: Tuesday, August 21, 2012 4:13 PM
To: RPG programming on the IBM i / System i
Subject: RE: Converting Case with a Varying Field
Try calling the CvtCase procedure in the service program directly and see if that makes a difference. But, the real question is why don't you just call the QlgConvertCase API directly and eliminate the overhead of the service program?
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Naughton
Sent: Monday, August 20, 2012 10:22
To: RPG programming on the IBM i / System i
Subject: Converting Case with a Varying Field
I've got an application where I want to convert various strings to (in this case) upper case. I'm familiar with the XLATE method, but I thought I'd try to find something more universal (dealing with accented characters, etc.), and I found CvtToUpper and CvtToLower procedures at
http://www.iprodeveloper.com/article/rpg-programming/apis-by-example-a-better-case-converter-60657 that seemed to be just what I want.
CvtToUpper seems to work great, except for one thing -- if I pass it a blank field, after it's done some of the fields in my program have (apparently randomly) been filled with blanks (I discovered this because if one were numeric I'd get a decimal data error).
I'm using this prototype for the procedure:
D CvtToUpper Pr 32765 Varying
D 32765 Const Varying
D 272 Options( *NoPass )
D 10I 0 Const Options( *NoPass )
and this definition for the field that I'm passing:
D XXXDTA S 32765 varying
and I'm calling the procedure like this:
C Eval XXXDTA = %Trim(MYFIELD)
C Eval XXXDTA = CvtToUpper(XXXDTA)
I've determined that if I remove "varying" from the definition of XXXDTA, then then everything is fine, but that seems like the wrong way to do it. Can anyone tell me why "varying" causes this problem? Alternatively, is there a better way to do what I'm trying to do?
Thanks very much,
Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA 01376
413-676-3144
Internal: x 444
mnaughton@xxxxxxxxxxxx
****************************************
NOTICE: This e-mail and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that any use is strictly prohibited. If you have received this e-mail in error, please notify us immediately by replying to it and then delete it from your computer.
--
This is the RPG programming on the IBM i / System i (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.
--
This is the RPG programming on the IBM i / System i (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.
midrange.com
