RPG and SQL Compilers

 Jon.Paris@hal.it wrote

>It is a good question, but the proposed solution " ... have the RPG
>compiler Understand SQL" would in the long run be not much better than >the
current situation.  You simply move the emphasis from SQL >understanding RPG
to RPG understanding SQL - 
>admittedly a simpler task most of the time but

I was thinking to use the IRP (does this still exist) and transfer 
all the HLL code that the SQL precompiler does down  to the IRP.  
I don't care if the IRP does calls to QSQ??? programs
behind the scenes and creates as many structures (in the IRP) as necessary.
Fields such as SQLSTS can still be available (eg ZZ01BIN) 
they simply do not neet to clutter up the RPG source.

>A much better solution would be to have RPG simply understand the
>"Start of SQL stuff" and "End of SQL stuff" and to pass all the code 
>between these two to the SQL compiler.  
>The SQL processor  then compiles its code"asking" the RPG compiler 
>(via an API) for information on the size and type of the host 
>variables etc.  This way neither compiler has to know anything 
>about the other and each is free to implement whatever changes 
>they like with zero impact to the other. 

Sounds good.
I assume that any compilation requires multiple passes over the source.
The SQL compilation would then be simply another pass.
I like the way that IBM can change CLP commands but still not affect
previously compiled programs, or am I imagining things. If this is true
then a similar technique can be used with SQL.

>One question that recently came up during some discussions I had 
>with the developers on this topic is "what about compatibility?"  
>How long would the old and new methods have to co-exist?  
>Would it be satisfactory to freeze the current pre-compiler?  
>How many years before it could be phased out
>completely (remember that keeping it available with new releases
>is _not_ a zero cost item).

This is a tricky thing.  There are entire ERP systems that depend on the
present SQL precompilers eg BPCS AS/SET. (AS/SET is an attempt
at a 4GL by SSA now taken over). I believe that AS/SET is in a frozen state so
it will not recognise the 'new' SQL interface, unless the
present SQL interface is completely recognised by the proposed RPG compiler.
In this case the 'new' method completely takes over the 
'current pre-compiler' and hence the SQL pre compiler is instantly
obsolete. I suppose that this means that we are stuck with the
present SQL interface forever. (forever is relative, if a company
recongises an exposure steps are taken to cover, it just does not
happen quickly but in my experience systems evolve every 5 years or so.)
The general question of :- How do you evolve a programming
language and somehow drop out 'obsolete' commands and/or
interfaces, without impacting someones programs. I suppose
one method is to have source converters. The conversion of S36
to AS400 is an example.  Third party developers could provide such
a service. All IBM needs to do is 'Sunset Clause' a particular
interface, provide the means to translate to the new method and
give sufficient time to translate to the new.  This can be a dangerous
game, if not played well, as your customers can translate to 
someone else.

>If you have any comments, please post them to the list and I'll forward
>them to the appropriate people.

Sorry for the delay in my response.  I was a bit busy.

Frank Kolmann

____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at 
http://home.netscape.com/webmail
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---