Re: AW: Overloaded UDF

[Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>]

Hi Neill,

> It does seem to me that this level of complexity is something that a managed
> language shields you from.

That's the theory...   You don't need to understand how this works under 
the covers because it's all taken care of for you.  However, I've found 
this type of knowledge to be beneficial...

You'd be amazed at how often it comes into play.

> However if I have followed this correctly, your example of the 3 parm
> procedure only being passed 2 parms in an SQL UDF call the problem is that
> the descriptor is not set?

Well, if the descriptor (or at least the count) had been set, you'd be 
able to detect the missing parameter properly.  Personally, I wish IBM 
had made it manditory that the parameter count be included in every call 
to every procedure (like they did for programs).

> I am guess there is a valid reason the descriptor is not set? Or has someone
> been a bit lazy :-) 

By default, the parameter count isn't set from Cobol or C programs. 
(Though, you can force it to set the count by telling it to describe the 
parameters)  SQL followed that precedent, but didn't give you the option 
to describe the parameters.

By contrast, RPG always passes at least the parameter count.  CL always 
passes full descriptors, including not just the parameter count, but 
descriptions of every variable.

As to why the SQL developers made that decision?  We can only guess. 
Unless we can rope one into this conversation, it's purely conjecture.

If you find this to be especially limiting, you might file a DCR with 
IBM asking them to provide at least a minimal descriptor when SQL calls 
an external UDF.  Personally, though, I don't find it to be that big of 
a deal.  As long as you understand the problem, you can code it properly.