|
Jon Paris wrote: >>> I understand what the precompiler does. What I dont understand >>> is why it is necessary to have an SQL precompiler at all. >>> >>> Why not have the RPG compiler Understand SQL. >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 would 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. This is closer to the method used in other >DB2 "flavors". -snip- >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). In the short term, the best solution is to have the Big iSeries Boss tell Rochester and Toronto to work together to make a uniform product. Wasn't tight integration one of the selling points of the platform? In the long term, I am missing how an internal compiler change affects me, the application programmer. Let's assume that Toronto and Rochester decide to go the API route. No more pre-compiler. PDM changes to use CRTRPGPGM instead of CRTRPGSQL for SQLRPG et al. My source type can remain SQLRPG or I can make it RPG and the compiler will work either way, transparently to me. CRTSQLRPG now calls the regular RPG compiler instead of the SQL pre-compiler. So... "what about compatibility?" The current situation is horrible. Buck Calabro Aptis; Albany, NY "Nothing is so firmly believed as that which we least know" -- Michel Montaigne Visit the Midrange archives at http://www.midrange.com +--- | 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.