MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » July 2008

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



fixed


On 20-Jul-08, at 1:00 PM, Steve Richter wrote:

Maybe those who did not
like the pre compiler idea in the first place spread enough doubt to
convince IBM mgmt that there was no use funding the effort.

Wrong wrong wrong. Nobody "did not like it" - it was enthusiastically welcomed as I recall. But at that time I don't think there were any notions of an alternative technology. And that is what we are talking about here. I suspect that the pre-compiler approach was used because that was how the RPG RPT processor had worked in the past and a few other similar things worked that way too. But in retrospect, if you think about it, a pre-compiler is a pretty silly way of implementing embedded SQL. Note that I _love_ imbedded SQL. It is the implementation methodology that in my opinion was a poor choice.

If you use a pre-compiler, then the pre-compiler has to be able to completely parse the host language. So it has to understand RPG, and COBOL, and C, and ... Not only that, but _every_ time there is a change in the host compiler you have to make a corresponding change in its pre-compiler. That inevitably results in the pre-compiler falling behind the host compiler as we saw for many many releases. It still hasn't caught up and may never quite do so.

Now contrast that with a possible alternative implementation where the compiler is modified to recognize the Exec SQL - and parse the following text only to the extent of determining where the end of the SQL command string is. It then passes that string to the SQL compiler. At this point the SQL compiler could potentially perform a basic parse to identify all host variables required and store the command for subsequent processing. Once the compiler completes processing of the source, it then calls the SQL compiler to go do its thing. As part of that process, SQL can make requests of the host compiler's dictionary services to establish the data type etc. of any host variables used. In this way it can fully validate the SQL. This isn't a complete solution as is because the Exec SQL has to be replaced by a host language "something" to invoke the SQL code but you get the idea.

The primary advantages are that:
- The SQL compiler never needs to know anything about the host language. As a result you can enhance the host language without SQL having to know or care. The only time there really needs to be change is if new data types are introduced.
- You can imbed SQL in new languages and the SQL components don't care. Embed SQL "properly" in Java, or CL or ...
- You can embed other "service languages" in host languages and the only change needed in the host compiler is to recognize a new Exec XXX.

_That_ in my opinion is the opportunity that was missed. When they decided to spend the money to bring the pre-compiler up-to-date they should have spent the additional $ up front to switch to a technology that would have minimized the impact of future changes. They opted instead to spend a little less at the time and to keep spending, and spending and ... That plus the inevitability of one day falling further out of sync again.

Things are better than they were - just not as good as they could have been.


Jon Paris

www.Partner400.com
www.SystemiDeveloper.com







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot 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 here. If you have questions about this, please contact