Re: ILE bug or "feature"?

On Wed, 7 Feb 2001 bmorris@ca.ibm.com wrote:

> Scott, when parameters are passed by reference, the procedure receives a
> pointer to the actual parameter.  If the compiler were to initialize
> that pointer to null, no parameters could ever be received.

Yes, I understand that the procedure receives a pointer to each parameter.
I guess I was envisioning some kind of situation where a new area of
memory is allocated with each invocation of the procedure, and that the
procedure copies the addresses of the passed parms into this new area...
this way, anything that did not get passed could be set to NULL, since its
copying things into its own storage...

But now that I'm thinking about it, the caller is probably allocating this
memory, and it doesn't know how many parms the called program is
expecting.

So I guess this brings us to some way for the caller program to tell
the called program how many pointers it actually passed...  i.e. the
operational descriptor that you mention...

> By default, ILE procedures have no idea how many parameters were passed.
> To get that information, an operational descriptor has to be passed (not
> an OPDESC one, just a minimal one giving the number of parms).  RPG and
> CL always pass this minimal operational descriptor (RPG had to, to support
> *PARMS), but C and COBOL only do it if the programmer requests it.  RPG
> only uses it to provide the value of %parms though.  RPG doesn't copy
> the parameters to some other storage.  It gives you direct access to the
> parameters as they were passed.

But, in Mark's example he WAS calling from CL.   Apparently the CALLPRC
command doesn't pass this minimal operational descriptor? 

> Mark, when I tried this with a CALL, I indeed got a "pointer or
> parameter error".  That's what I expected, because with a CALL, the
> number of parameters is always available; for a CALL, RPG has to copy
> the parameter pointers to its own storage anyway (I forget why), and
> it only copies the parameters that were actually passed, and sets the
> other local parameter pointers to null.

See... thats what I was thinking should be happening in Mark's example, as
well...  :)  Though, you explain it much better than I did.

Presumably this isn't done with bound procedures for performance reasons?

> Regarding bug or feature, I don't think it's either.  I think it would
> be great if the ILE environment could provide something that I don't
> think is available anywhere else, namely runtime checking of parameters.
> But the system works the way it works.  The existence of %parms and
> *PARMS implies that the system won't prevent you from accessing
> parameters that are not passed; the fact that failure to check %parms
> sometimes causes a nice pointer-not-set error doesn't mean that problems
> from not checking %parms are limited to that error.
> 
> Barbara Morris
> 

But if that minimal operational descriptor that you mentioned earlier
isn't being passed, you couldn't actually check %parms anyway, could you?

It sounded to me like it didn't actually know how many parms were passed?


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---