RE: Converting Case with a Varying Field

Sorry to disagree with you, as I do greatly respect your opinion, but processing efficiency ALWAYS trumps programmer efficiency. Any extra (read unnecessary) code is less efficient. The problem with most programmers (besides laziness) is that they usually don't look at the big picture, which is the code running in many jobs and possibly being called millions of times in a day. That "possibly negligible" amount of extra processing adds up in a hurry. Our production system does a lot of work (we wrap the job number every two to three days), so we need to remove inefficiency wherever we can.

It seems to me that however "very very fast" the bound calls are, calling the API directly is still faster. And that's the bottom line. Teaching programmers to value programmer efficiency over processing efficiency is a huge mistake.


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Barbara Morris
Sent: Tuesday, August 21, 2012 17:25
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Converting Case with a Varying Field

On 2012/8/21 7:03 PM, Robert Houts wrote:

... It
isn't rocket science and eliminates all overhead of the service
program. I guess that efficient processing is not a concern to you.

The Integrated Language Environment is optimized to make bound calls very very fast, with the intention that programmers can have many small functions that call each other rather than flattening out the functions to reduce the number of calls. So the cost of calling the two wrapper functions could be negligible compared to the actual upper-casing work.

And I think programmer-efficiency is a factor here. Even if you set up the copy file so all the other parameters can be used without further setup, coding the call to the API is still more complex and error-prone than calling the wrapper.

upper_value = CvtToUpper(some_value);

vs

QlgConvertCase(QlgConvertCase_To_Upper
: some_value
: QlgConvertCase_Temp_Output
: QlgConvertCase_Errcode_Give_Exception
: QlgConvertCase_Job_CCSID);
upper_value = %subst(QlgConvertCase_Temp_Output
: 1 : %len(value));

If I were maintaining this code, I'd much rather see the expressive call to CvtToUpper than the somewhat obfuscated call to the API. Even though I am completely familiar with this API, it's not immediately obvious which is the "real" parameter, some_value.