×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
