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
midrange.com
