Re: More SQL precompiler

Rob wrote:

> Frankly I agree.  And that was my original thought when I entered my
> concerns into the IBM arena.  Perhaps I was seduced once I went into
there.
> I think I couldn't see the forest because the trees were in the way.
>
> How do you suggest you get them to actually accept that the dang
> precompiler should just accept everything that the language supports?

FWIW, my view of the forest looks like this:

The purpose of the SQL Precompiler is to read a source member written in a
host language, find all the SQL statements within that source member, and
convert those statements to run-time API calls in a syntax valid for that
host language. If the precompiler is choking on syntax, data types,
subprocedures, or other elements within the source member that are valid
host language statements, then the product simply isn't functional.

At the present time, there are SQL Precompilers available for the following
languages:

- C/C++
- Cobol
- PL/1
- Rexx
- RPG
- ILE RPG

Particularily noteworthy, is the fact that IBM distinguishes between RPG &
ILE RPG in all of the documentation related to embedded SQL programming.
This is evidence of the fact that they recognize those host languages as
having distinctly different capabilities and, therefore, requirements.

Presently, the precompiler does not allow us to utilize the full
capabilities of the ILE RPG compiler. Indeed, the functional disparity grows
with each new release! Therefore, I suggest that there is no need to talk
about DCE's or customer enhancement surveys until the product has reached
the point where it fulfills the fundamental requirements of a precompiler.
Fortunately, they don't need a DCE to determine what those requirements are.
All they have to do is consult the ILE RPG Reference Manual.


John Taylor