Re: The real problem with the SQL precompilers (was SQL on AS400...)

IMHO:

Many problems we see with "embedded SQL" are precisely because is implemented as a separate pre-compiler (or preprocessor), and not truly integrated into the language(s)/compiler(s).

A preprocessor almost never has the same depth and breadth of knowledge of the host language(s) within which it is embedded that a "real" compiler has (by parsing the full syntax and semantics of the host language).

Recently, some of the IBM mainframe compilers now use an SQL "co-processor" design instead of a completely separate SQL pre-processor. That helps somewhat, and is a step in the right direction.

In the 1980s, I worked for one of the world's largest independent software vendors (at that time), and when we added SQL support to our 4GL language, we implemented it directly within the compiler, and not as a separate pre-processor. This provided excellent results and benefits. Error messages are integrated with the rest of the compiler's error handling; SQL statement parsers have full access to the compiler's symbol tables, so they can interrogate the type, length, and decimal places, etc. of host variables, and so on. And there were no problems with the "scope" of variables, as we frequently see with the current generation of IBM SQL pre-processors.

I can hardly understand why, after all these years, IBM still maintains the "embedded SQL" capability as (a set of) pre-processors (for each language), rather than just integrating support for SQL directly into each language compiler.

After all, IBM just went right ahead and added direct language support for XML to RPG IV ... so, why can't they support "embedded SQL" properly?

I suspect it probably has something to do with "turf" and "who owns the database" versus "who owns the language compilers" -- and some "political" rationale. Meanwhile, we end users suffer with and must continue to tolerate a less-than-optimal solution.

That's my opinion, what's yours?

Mark S. Waterbury