Code for an API or code for a service program; not much difference to the programmer as you still have to code for one of them. Using /COPY or /INCLUDE for the prototype and data elements makes it simple for the programmer in either case. So that isn't really an argument.
The pointer to the API is resolved only once (upon first call), so again there's not much difference, except for the overhead of the service program. The overhead doesn't occur only once; the code is executed every time and that is definitely overhead compared to calling the API directly. Also, each procedure call gets a new invocation stack entry and this particular procedure calls another procedure in the same service program each time, so there are two invocations created/destroyed; you can't tell me that isn't expensive. Hundreds or thousands (or millions) of calls to the service program, which for each call then calls the API still adds the unnecessary overhead of running the code and creating/destroying invocations in the service program. This is very expensive compared to calling the API directly, where the only overhead is resolving the pointer on the first call.
So the answer is yes, I would expect every programmer who wanted to convert something to code for the API (using /COPY or /INCLUDE). It isn't rocket science and eliminates all overhead of the service program. I guess that efficient processing is not a concern to you.
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Anderson, Kurt
Sent: Tuesday, August 21, 2012 14:40
To: RPG programming on the IBM i / System i
Subject: RE: Converting Case with a Varying Field
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
****************************************
midrange.com
