Re: SQL pre-processor (was RPG IV release levels and complexity) -- RPG400-L

Hi Hans,

thanks for clearing that issue up a bit!

> But, and this is a big *BUT*, in this design, there are cases where
> the compiler writer has to understand certain aspects of SQL syntax
> /and/ semantics.

Good idea for a thing called "SQL (pre)processor". Otherwise it would
be a generic preprocessor, which could also have it's merits (thinking
of e.g. imbedding REXX or Ruby or whatever :-).

Hans, is it true that sooner or later we will only be able to open
certain files (with e.g. LOB's) with SQL only?

If that is true, and F-"cards" are going to leave us, a stronger
relationship with RPG and SQL, it's then one and only means of DB
access, would be a goal that one would want to achieve, or am i
completely off-track in the wilderness?

>  And so the onus is put on the compiler development team to
> keep up with SQL, rather than the other way around. As elegant the 
> architecture may be, the logistical consequences are unacceptable for
> both the compiler development team and for the SQL team.

Impossible to compare, somehow; but what is expected from the
5250-guys coding RPG in SEU, namely getting and installing WDSc, is
also not always considered acceptable... :-)

> But to divert into the realm of "wild and crazy ideas", apart from SQL,
> the thought occurred to me that it might be possible to add some 
> framework into the RPG compiler to implement a sort of generalized 
> processing of 3rd party embedded statements. That is, if you coded 
> something like "exec xyz ...;", exits for component "XYZ" would be 
> invoked which would return RPG statements to include in place of the
> exec statement. Anyways, I seriously doubt if anything will come out of
> such flights of fancy since it would need a lot of work in the compiler,
> but it's fun to imagine the possibilities.

Yes, but there were people that were doing exactly that (me included)
and wrote a precompiler that handled such things.

Nowadays it's getting less and less interesting as the modern RPG
language with it's functions is much better than everything i saw
and/or did; with exception of e.g. subfile handling and so on. There
might be still a field of advantages.

What we still could use are "pre-compile" statements, like an OVRDBF,
for those rare cases where we need to open the very same file twice.
We actually have such a little pre-compile-parser that checks for
certain comments in the first lines of code and, if they fit, executes
the commands standing there. A standard-IBM-solution would be
preferred, of course. I think i put it on my x-mas wish list! :-)

-- 
Mit freundlichen Grüssen / best regards

Anton Gombkötö
Organisation und Projektleitung

Avenum Technologie GmbH
Wien - Salzburg - Stuttgart
http://www.avenum.com