[Info-vax] VMS Software: New US Mailing Address

[Arne Vajhøj]

On 10/13/2022 6:25 PM, Bill Gunshannon wrote:
> On 10/13/22 17:40, Jan-Erik Söderholm wrote:
>> Think of it as a compiler for a language called "SQL".
>> The default file type for these files (on VMS) is .SQLMOD
>>
>> It's more or less "just" as a compiler for any other language.
>> And it creates a object files that are no different from any
>> other object file, may it come from C, Pascal or whatever.
>>
>> That object file can then be linked into any other application
>> following the VMS calling standard. That other language does not
>> need to have any native support for Rdb, it just has to follow the
>> VMS calling standard.
>>
>> It is just a function call with some parameters that returns some
>> defined result. The caller does not need to know that it was Rdb
>> that returned the result.
> 
> Well, that's pretty cool.  I have never seen COBOL used that way
> although there really is no reason not to.  Just like the libraries
> linked to from the EXEC SQL parts of the code are actually C or C++
> snippets.  You can directly link to the PostGres Libraries but, for
> obvious reasons, using the Embedded SQL method is easier on the
> programmer.

Embedded SQL is pretty efficient - few lines achieve much - way
more efficient than library calls in compiled languages (probably
less efficient than library calls in scripts languages and ORM).

But the industry is moving away from embedded SQL and precompilers.

Oracle DB - only supports C and Cobol - it has dropped Fortran

MySQL/MariaDB - no pre-compilers

PostgreSQL - only C (from project itself - an open source Cobol exist)

SQLServer - dropped all support

DB2 - still support Cobol, PL/I and C (maybe also Fortran - not sure)

Sybase (or whatever SAP calls it today) - I believe they have dropped 
all support

SQLite - no pre-compilers

NoSQL databases (MongoDB etc.) - obviously no embedded SQL  :-)

Arne