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

[Simon Coulter <shc@xxxxxxxxxxxxxxxxx>]

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  / \
--------------------------------------------------------------------