Re: RE: Passing parameter back to calling CL -- C400-L


On 02/10/2004, at 10:18 AM, James Rich wrote:

No, C doesn't suck.

Yes it does, but you're missing the real point which is getting C to play nicely with other languages.

But it does seem like you guys are going through a lot of gyrations to do something very simple: get a return value from a C program. All you want is a number, so return one:

In this particular case he wants to return a numeric value. But that is simply a specific instance of the generic "returning parameters" problem which C does not do well and for which most C programmers think there is no solution because "Why would you want to do that?". The only reason they think that way is because you can't do that sort of thing in Windoze or Eunuchs. The C-weenie solution to this defect is most likely to populate a stream file with the data (write to file in program B and read the 'return' value in program A).

  int rrn;
  return (rrn);
Done. Easy. Every C function can return a value, including main(). All you need to know is, "What is the value of the last executed command?" The shell can find that out for you very simply.

But main() can only return an integer which severely restricts the usefulness. And how would you 'return' a data structure, a string, a float, or a decimal(7,2)? All of these are perfectly valid things to want to pass back from one program to another.

Further, why would you want to resort to something as kludgy as the shell to accomplish this? All David wants to do is have program A pass a variable to program B and have program B populate it. Simple stuff in any language except C and its derivatives. Your alternative requires:

1) That the shell is installed. 2) That a job is spawned to run program B which is far more expensive than a simple program call. This happens regardless of whether the program is invoked directly or via a script. 3) That a shell script is used to get the $? value or a RCVMSG command (or equivalent) is run to get the exit status. 4) That a tight-coupling between the caller and callee at the language level is acceptable.

Yet you think that is easier than simply returning the desired value to the caller's storage?

If you use the 'return from main' trick without QSH then you force the caller to either call QUSRJOBI with format JOBI0600 to get the User Return Code of the job to find the value, or directly access the Languages and Utilities section of the job to extract the User Return Code.

Another alternative would be to make the C program a procedure and bind to it but that forces the caller to be an ILE program and the consumer to understand ILE. (I think that is not a big deal and that any current OS/400 programmer should understand ILE but there could be a business reason for making the interface a callable one and a technical reason for requiring C.)

Understanding the limitations of C and using the casting technique I demonstrated solves the problem in a far more straight-forward fashion than resorting to shell games. More importantly, it is not restricted to integers and thus is a solution for the general case.

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------