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

Mark,

I agree with your assessment. I know IBM has made some improvements to the pre-compiler (thanks Gina!), but this disconnect still bites us all the time. WDSC (RDi) falls over when reviewing compiler errors, debugging is ugly, x-ref and outline features are incomplete, etc..... IBM needs to eliminate this asap. Seems to be in IBM's best interest to make their tools usable, without the work-arounds that we currently are stuck with. IBM should find this situation embarrassing.

Eric DeLong

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Mark S. Waterbury
Sent: Thursday, July 17, 2008 7:49 PM
To: Midrange Systems Technical Discussion
Subject: 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