× 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.



eftimios pantzopoulos wrote:

I’ll draw this to a close, but what are the rules for posting
when a topic takes a different path from the original subject
line?

Although a moderated forum, there is no /rule/ as such. It is IMO just a courtesy to make the discussion match the subject; not just for those who might choose to follow the current thread, but even more importantly for searching the archives. Why frustrate searchers who might find the /subject thread/, but end up reading messages that have unrelated discussion?

I had a vague feeling that an SQL function which is implemented
through another language was just a shell, but thought that there
might still be some C code to implement the interface which could
be stepped through.

No additional code is available to the SQL programmer for the interface. It is the DB2 for i SQL runtime [as part of the OS] which implements the interface to the external program, based on what is defined by the CREATE FUNCTION both to pass as parameters and to receive as a return value from the program named on the EXTERNAL NAME.

I guess the process of registering the function must check that
the parameters and return values are all in alignment in terms of
position, type and size?

Between what is defined by the CREATE FUNCTION and the existing External [service] program at definition\create time? That is actually the responsibility of the programmer of the external program and the creator of the function. The external program need not even exist; i.e. in that case there would be no possibility to validate the parameter\return-value interface. I suppose with PCML such validation could potentially occur, but AFaIK there is nothing but what the programmers have done to ensure the compatibility between the two. That is, the program is created with the parameters to match the PARAMETER STYLE that was specified on the CREATE FUNCTION, and any errors would occur at the runtime.

And that invoking the SQL function simply passes the parameters
through whatever parameter style has been declared.

Correct.

So in essence, it’s either all de-buggable or not at all depending on the language being SQL or not?

Not sure what is meant by that. The programs that implement the FUNCTION are debug capable whenever they are compiled as such.

There is no more capability to debug the interface between the SQL function and the external program, than there to debug that interface for the service program as SQL FUNCTION. The interface is still the SQL run-time, not available to be debugged except by the IBM development. The only difference being, that the SQL function is generated source, parameters and all, such that an interface mismatch would be a defect with the DB2 for i SQL versus a programmer error for having mismatched the PARAMETER STYLE and the external program parameter definitions.

<<SNIP>>

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.