This is all really interesting stuff, I have only been an RPG developer for
2 and a half years, and still have a lot to learn.
I wasn't aware that programs could have optional parameters, I thought that
this was only procedures?
Also I always thought (and this may have been tainted by my c# programming
days...) that references to parameters were placed on the stack by the
caller and scooped up off the stack by the callee. If it wasn't on the stack
then the callee would assume it was null?
Based on the below, the above is obviously all rubbish. So it leads me to
ask what does actually happen when one program calls another as far as
parameters are concerned?
Or when one procedure calls another.
Neill
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Simon Coulter
Sent: 02 December 2009 19:54
To: Midrange Systems Technical Discussion
Subject: Re: AW: Overloaded UDF
On 03/12/2009, at 5:51 AM, Scott Klement wrote:
When it called from SQL, I don't know if it's valid. Birgitta says it
is, but I'm HIGHLY skeptical.
I thought the same thing. I've seen no documentation indicating that
SQL determines the maximum number of parameters for a given set of
overloaded procedures and then passes a null pointer for any that are
not valid for the specific invoked procedure. It's possible that
Birgitta learned this behaviour directly from an SQL developer but I'd
expect that to be written up in either formal documentation or in a
Redbook.
I too suspect that the presence of a null pointer is happenstance--
especially since SQL does not pass even a basic descriptor which to me
would be a requirement for any environment that supports overloaded
procedures. If SQL can't be bothered passing a parameter count then
why would it go to the effort of determining maximum parameters?
It's a little different in a language like C++ where the developer has
to code separate procedures for each overloaded procedure so the
compiler can work out what's required. However, with other languages
that have no support for overloading, and especially for external
calls, a developer could choose to use language-specific functions
(i.e., %PARMS) to attempt a mapping of multiple SQL procedures to a
single HLL procedure. My initial thoughts are that the SQL developers
did not consider that possibility and expect each defined SQL
procedure or UDF to have a 1-to-1 mapping to the underlying
implementation code.
Given some of the observations previously noted about normal ILE
calls--specifically that if PGM-A calls PGM-B passing 3 parameters and
then PGM-A calls PGM-B passing 2 parameters it is possible that the
3rd parameter from the previous call is still hanging around and can
be addressed by PGM-B if it simply assumes its presence. A similar
test using SQL CALLs to stored procedures or UDFs may shed some light
but still is only indicative and not absolutely definitive. At least
if the unpassed parameter on the second call can address the data
from the first call it will show that SQL is doing nothing special and
that relying on the presence of a NULL parameter is flawed. The
reverse however doesn't prove much without documentation to state
that's how SQL does things.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
