On 2022-10-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 10/13/2022 9:00 AM, Simon Clubley wrote:
>> On 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>> What, no Ada?
>>
>> Ada doesn't exist for x86-64 VMS and looks like it will never exist.
>
> Well - we were talking about SQLRelay for VMS Alpha and VMS I64 - or
> that was what started this subthread.
>

That's true, but it's part of VSI's approach to Ada, which clearly sees
it as a language of the past, at least when it comes to VMS.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 10/14/2022 9:00 AM, Simon Clubley wrote:
> On 2022-10-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 10/13/2022 9:00 AM, Simon Clubley wrote:
>>> On 2022-10-12, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>>>> What, no Ada?
>>>
>>> Ada doesn't exist for x86-64 VMS and looks like it will never exist.
>>
>> Well - we were talking about SQLRelay for VMS Alpha and VMS I64 - or
>> that was what started this subthread.
>>
>
> That's true, but it's part of VSI's approach to Ada, which clearly sees
> it as a language of the past, at least when it comes to VMS.
>
> Simon.
>

I don't think that is fair ...

Perhaps they see ADA as something they don't have the resources to provide.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/14/2022 8:59 AM, Simon Clubley wrote:
> On 2022-10-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 10/13/2022 10:05 PM, Richard Maher wrote:
>>>  IIRC Oracle/Rdb is the only RDBMS that executes in the context of the
>>> calling process through DSRI. Sounds pretty efficient. Dynamic qyuery
>>> optimization notwithstanding.
>>
>> There are lots of databases executing in process context:
>> SQLite, Firebird, H2, HSQLDB, good old (or bad old depending on view)
>> Access.
>>
>> Rdb uniqueness is:
>> - it supports both executing in process context (embedded SQL,
>> SQL modules, JDBC native driver) and executing in separate
>> server (JDBC thin driver, SQL Services API, ODBC)
>> - even when executing in process context there are still some
>> central administrative processes running
>> - it is geared towards large usage while traditional embedded
>> databases are really geared towards small usage or test
>>
>
> And IIRC, isn't Rdb _fully_ and closely integrated into the VMS cluster
> model with full VMS-style disaster recovery on node/site failures ?

The above list was in relation to separate server vs embedded.

Rdb support active/active-cluster. Other databases do too.
But Rdb is unique in that it used VMS builtin features to
implement it - unlike other that has all the functionality in
the database software itself.

Arne

In article <tic69d$1vf8$1@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<arne@vajhoej.dk> writes:

> But Rdb is unique in that it used VMS builtin features to
> implement it - unlike other that has all the functionality in
> the database software itself.

It also has very much a VMS look and feel to it.

On 14/10/2022 7:21 pm, Jan-Erik Söderholm wrote:
> Den 2022-10-14 kl. 04:07, skrev Richard Maher:
>> On 14/10/2022 5:40 am, Jan-Erik Söderholm wrote:
>>> Den 2022-10-13 kl. 02:14, skrev Bill Gunshannon:
>>>> On 10/12/22 19:22, Arne Vajhøj wrote:
>>>>> On 10/12/2022 6:58 PM, Bill Gunshannon wrote:
>>>>>> On 10/12/22 17:33, Arne Vajhøj wrote:
>>>>>>> On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
>>>>>>>> Using a compatibility layer and trying to make
>>>>>>>> PostGres look like RDB (or Oracle) would be a major
>>>>>>>> mistake. Better to bite the bullet and move into the
>>>>>>>> current century.
>>>>>>>
>>>>>>> It is a tradeoff.
>>>>>>>
>>>>>>> There are benefits from doing things the standard way
>>>>>>> instead of doing it the compatibility way.
>>>>>>>
>>>>>>> But there are also huge cost of changing the client
>>>>>>> applications.
>>>>>>
>>>>>> Maybe and maybe not as much as you think. Granted, most of
>>>>>> my experience doing it has been with COBOL but I have been
>>>>>> able to take programs using databases from other systems
>>>>>> and moved them quite easily. I would love to have someone
>>>>>> send me a COBOL program that uses RDB just for a look-see.
>>>>>
>>>>> Cobol embedded SQL is probably one of the more portable. But
>>>>> it is not supported by PostgreSQL project itself.
>>>>
>>>> No, but this is the Open Source world. A need arose and
>>>> someone rushed in to fill it. And it works quite well.
>>>>
>>>>>
>>>>> An extremely simple Cobol embedded SQL to Rdb example:
>>>>> https://www.vajhoej.dk/arne/articles/vmsdb.html#rdb_cob_emb
>>>>
>>>> I saw nothing in there that would not compile using ESQL and
>>>> GnuCOBOL with PostGres. Even the module stuff (which I am not
>>>> familiar with)
>>>
>>> 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.
>>>
>>
>> A slight nit. SQLMOD makes you specify the calling language. If you
>> specify COBOL then your module procedures refuse to look for
>> dynamic descriptors which can be RTL'd in COBOL
>>>
>>
>
> That is right. If you have built your SQLMOD object files using the
> "wrong" "language calling standard", you will need a few additional
> things to get the calls working.
>
> But that is the same as calling between different languages
> directly.
>
>

No it is NOT. The VMS Procedure Calling standard prescribes that you
must interrogate the descriptor class to be fully compatible.

It was common sense for the language specifier to provide default
passing mechanisms et al. Can't remember if your SQLMOD procedure can
o/ride the default?

On 15/10/2022 10:52 am, Richard Maher wrote:
> On 14/10/2022 7:21 pm, Jan-Erik Söderholm wrote:

>> That is right. If you have built your SQLMOD object files using the
>> "wrong" "language calling standard", you will need a few additional
>> things to get the calls working.
>>
>> But that is the same as calling between different languages
>> directly.
>>
>>
>
> No it is NOT. The VMS Procedure Calling standard prescribes that you
> must interrogate the descriptor class to be fully compatible.
>
> It was common sense for the language specifier to provide default
> passing mechanisms et al. Can't remember if your SQLMOD procedure can
> o/ride the default?

Just looked it up 4.2.8 says you can use BY DESCRIPTOR to override the
default passing mechanism. (Which for COBOL would be BY REFERENCE)

What it doesn't say is that, for COBOL, it doesn't allow for dynamic
string descriptors whereas for BASIC it does.

Le 11/10/2022 à 21:49, Arne Vajhøj a écrit :
> VSI is doing a lot with open source.
>
> Including supporting support OpenSSL, Apache and Python 3.
>

where can I find the kit for python3 on AXP ?

No support from VSI ?

On 2022-10-17 16:24:44 +0000, rejoc said:

> Le 11/10/2022 à 21:49, Arne Vajhøj a écrit :
>> VSI is doing a lot with open source.
>>
>> Including supporting support OpenSSL, Apache and Python 3.
>>
>
> where can I find the kit for python3 on AXP ?
>
> No support from VSI ?

DDG for /Python 3 OpenVMS/ finds
https://vmssoftware.com/about/news/2020-11-20-python-for-openvms-is-released/

Following the link there finds kits for Python 3.10.

VSI might answer questions specifically about the port itself, but
likely not more general issues with or about Python.

VSI is not supporting Python, though might be willing to negotiate
support given acceptable terms and a sufficiently enormous support
payment.

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/17/22 1:50 PM, Stephen Hoffman wrote:
> On 2022-10-17 16:24:44 +0000, rejoc said:
>
>> Le 11/10/2022 à 21:49, Arne Vajhøj a écrit :
>>> VSI is doing a lot with open source.
>>>
>>> Including supporting support OpenSSL, Apache and Python 3.
>>>
>>
>> where can I find the kit for python3 on AXP ?
>>
>> No support from VSI ?
>
> DDG for /Python 3 OpenVMS/ finds
> https://vmssoftware.com/about/news/2020-11-20-python-for-openvms-is-released/
>
> Following the link there finds kits for Python 3.10.
>
> VSI might answer questions specifically about the port itself, but
> likely not more general issues with or about Python.
>
> VSI is not supporting Python, though might be willing to negotiate
> support given acceptable terms and a sufficiently enormous support payment.

I believe the point was that there are no Python kits for Alpha
available from VSI, i.e., "support" in the sense of providing a
capability, not in the sense of end-user help. I don't know why there
aren't Alpha kits, but yes, asking VSI seems like a reasonable path
forward. At one point there were problems with getting the foreign
function interface (FFI) working on Alpha due to lack of AXP assembly
skills on the part of the volunteers doing the work; I don't know what
happened with that.

On 10/17/2022 12:24 PM, rejoc wrote:
> Le 11/10/2022 à 21:49, Arne Vajhøj a écrit :
>> VSI is doing a lot with open source.
>>
>> Including supporting support OpenSSL, Apache and Python 3.
>
> where can I find the kit for python3 on AXP ?

VSI Python is Itanium only.

https://vmssoftware.com/products/python/

Arne

On 10/13/2022 9:18 PM, Bill Gunshannon wrote:
> On 10/13/22 19:14, Arne Vajhøj wrote:
>> MySQL/MariaDB - no pre-compilers
>
> No one has expressed a need or desire for it yet.  (I have done
> some playing with making ESQL work but nothing production level.)
> More a MySQL shortcoming than embedded SQL.
>
>> PostgreSQL - only C (from project itself - an open source Cobol exist)
>
> And that's the way Open Source works.  If there was a need other
> languages would be supported.

It is not really open source specific.

If there is a demand for something then it will be created.
Maybe commercial. Maybe open source.

Given that MySQL/MariaDB is #2 in database market share
and PostgreSQL is #4 and they are used by by a huge number
of developers (magnitude 1 million), then the fact that there
are no pre-compilers for MySQL/MariaDB and only two for PostgreSQL
is a pretty good indication for very low interest for embedded
SQL among developers.

> All of this shows a lack of interest in languages that most people
> think are dying.  Also in database systems not being used for the
> kind of work that Oracle, RDP, DB2 and Postgres are.  I see nothing
> here that even hints at embedded SQL going away.

The fact that half the widely used databases has no pre-compilers
available and the remaining half only has support for typical
2-3 out of maybe 20 languages used for database access shows that
for the vast majority (95% magnitude) of projects then embedded
SQL is not possible because no pre-compiler exist.

And in the remaining few cases then it may be discarded due
to uncertainty about the future of the pre-compiler or because
the developers do not like it or don't know about it (most developers
under age 50 does not know that embedded SQL exist).

Cobol is probably the only language where embedded SQL will be
the most common choice for database access. The C/C++ crowd
has moved to various standards based or database specific API's.

Arne

On 10/23/22 19:05, Arne Vajhøj wrote:
> On 10/13/2022 9:18 PM, Bill Gunshannon wrote:
>> On 10/13/22 19:14, Arne Vajhøj wrote:
>>> MySQL/MariaDB - no pre-compilers
>>
>> No one has expressed a need or desire for it yet.  (I have done
>> some playing with making ESQL work but nothing production level.)
>> More a MySQL shortcoming than embedded SQL.
>>
>>> PostgreSQL - only C (from project itself - an open source Cobol exist)
>>
>> And that's the way Open Source works.  If there was a need other
>> languages would be supported.
>
> It is not really open source specific.
>
> If there is a demand for something then it will be created.
> Maybe commercial. Maybe open source.
>
> Given that MySQL/MariaDB is #2 in database market share
> and PostgreSQL is #4 and they are used by by a huge number
> of developers (magnitude 1 million), then the fact that there
> are no pre-compilers for MySQL/MariaDB and only two for PostgreSQL
> is a pretty good indication for very low interest for embedded
> SQL among developers.

I think that has more to do with who is using each of these database
systems than the popularity of Embedded SQL. Embedded SQL is used
mostly by COBOL, followed by some Fortran, probably a little PL/I.
And, mostly mainframes or other large systems (like VMS). It is
MySQL/MariaDB that lack popularity in this community, not Embedded SQL.

>
>> All of this shows a lack of interest in languages that most people
>> think are dying.  Also in database systems not being used for the
>> kind of work that Oracle, RDP, DB2 and Postgres are.  I see nothing
>> here that even hints at embedded SQL going away.
>
> The fact that half the widely used databases has no pre-compilers
> available and the remaining half only has support for typical
> 2-3 out of maybe 20 languages used for database access shows that
> for the vast majority (95% magnitude) of projects then embedded
> SQL is not possible because no pre-compiler exist.

I think there are other reasons for the lack of pre-compilers. The API
for all these Open Source DB's is basically C oriented. Why would there
be a pre-compiler for languages for which that is the native API?
Python, PHP, Perl, none of these are compiled so what would you
pre-compile to?

>
> And in the remaining few cases then it may be discarded due
> to uncertainty about the future of the pre-compiler or because
> the developers do not like it or don't know about it (most developers
> under age 50 does not know that embedded SQL exist).

That I agree with but the question really is, why? It is not that
Embedded SQL is unpopular but that academia stopped teaching the
languages most likely to use it even though those languages are
still extremely common in the industry.

>
> Cobol is probably the only language where embedded SQL will be
> the most common choice for database access. The C/C++ crowd
> has moved to various standards based or database specific API's.

As stated above, the databases API's are already targeted at C and
C++. What would an Embedded SQL Pre-Compiler convert it to?

bill

On 10/24/2022 9:15 AM, Bill Gunshannon wrote:
> On 10/23/22 19:05, Arne Vajhøj wrote:
>> On 10/13/2022 9:18 PM, Bill Gunshannon wrote:
>>> On 10/13/22 19:14, Arne Vajhøj wrote:
>>>> MySQL/MariaDB - no pre-compilers
>>>
>>> No one has expressed a need or desire for it yet.  (I have done
>>> some playing with making ESQL work but nothing production level.)
>>> More a MySQL shortcoming than embedded SQL.
>>>
>>>> PostgreSQL - only C (from project itself - an open source Cobol exist)
>>>
>>> And that's the way Open Source works.  If there was a need other
>>> languages would be supported.
>>
>> It is not really open source specific.
>>
>> If there is a demand for something then it will be created.
>> Maybe commercial. Maybe open source.
>>
>> Given that MySQL/MariaDB is #2 in database market share
>> and PostgreSQL is #4 and they are used by by a huge number
>> of developers (magnitude 1 million), then the fact that there
>> are no pre-compilers for MySQL/MariaDB and only two for PostgreSQL
>> is a pretty good indication for very low interest for embedded
>> SQL among developers.
>
> I think that has more to do with who is using each of these database
> systems than the popularity of Embedded SQL.  Embedded SQL is used
> mostly by COBOL, followed by some Fortran, probably a little PL/I.
> And, mostly mainframes or other large systems (like VMS).  It is
> MySQL/MariaDB that lack popularity in this community, not Embedded SQL.

That sounds very plausible.

The change in programming languages used, the changes in
platforms used and the change in databases used has undoubtedly
contributed heavily to the demise of embedded SQL.

>>> All of this shows a lack of interest in languages that most people
>>> think are dying.  Also in database systems not being used for the
>>> kind of work that Oracle, RDP, DB2 and Postgres are.  I see nothing
>>> here that even hints at embedded SQL going away.
>>
>> The fact that half the widely used databases has no pre-compilers
>> available and the remaining half only has support for typical
>> 2-3 out of maybe 20 languages used for database access shows that
>> for the vast majority (95% magnitude) of projects then embedded
>> SQL is not possible because no pre-compiler exist.
>
> I think there are other reasons for the lack of pre-compilers.  The API
> for all these Open Source DB's is basically C oriented.  Why would there
> be a pre-compiler for languages for which that is the native API?

Because embedded SQL is actually often shorter and easier to
read than API calls.

And we can also see that those databases with C pre-compilers
also usually have C centric API's: Oracle OCI (and OCCI), DB2 CLI,
PgSQL libpq.

> Python, PHP, Perl, none of these are compiled so what would you
> pre-compile to?

A Cobol pre-compiler compiles to Cobol, so a Python/PHP
pre-compiler would of course compile to Python/PHP.

Since they are not compiled it would probably not be
called pre-compiler, but transpiler.

So: a Python/PHP transpiler would of course transpile
to Python/PHP.

But really same thing.

AFAIK such a thing has never been made.

And for pretty obvious reasons: for languages like Cobol and C
embedded SQL may mean fewer lines than API calls, but for
languages like Python and PHP embedded SQL would likely be
more lines than API calls.

>> And in the remaining few cases then it may be discarded due
>> to uncertainty about the future of the pre-compiler or because
>> the developers do not like it or don't know about it (most developers
>> under age 50 does not know that embedded SQL exist).
>
> That I agree with but the question really is, why?  It is not that
> Embedded SQL is unpopular but that academia stopped teaching the
> languages most likely to use it even though those languages are
> still extremely common in the industry.

That developers under 50 does not know embedded SQL must have
something to do with educations.

But I think it would be difficult to justify being taught. Too
few would ever use it.

>> Cobol is probably the only language where embedded SQL will be
>> the most common choice for database access. The C/C++ crowd
>> has moved to various standards based or database specific API's.
>
> As stated above, the databases API's are already targeted at C and
> C++.  What would an Embedded SQL Pre-Compiler convert it to?

C (and C++).

That is what Oracle, DB2 and PgSQL pre-compilers for C do.

Arne

On 25/10/2022 8:11 am, Arne Vajhøj wrote:
> On 10/24/2022 9:15 AM, Bill Gunshannon wrote:
>> On 10/23/22 19:05, Arne Vajhøj wrote:
>>> On 10/13/2022 9:18 PM, Bill Gunshannon wrote:
>>>> On 10/13/22 19:14, Arne Vajhøj wrote:
>>>>> MySQL/MariaDB - no pre-compilers
>>>>
>>>> No one has expressed a need or desire for it yet. (I have
>>>> done some playing with making ESQL work but nothing production
>>>> level.) More a MySQL shortcoming than embedded SQL.
>>>>
>>>>> PostgreSQL - only C (from project itself - an open source
>>>>> Cobol exist)
>>>>
>>>> And that's the way Open Source works. If there was a need
>>>> other languages would be supported.
>>>
>>> It is not really open source specific.
>>>
>>> If there is a demand for something then it will be created. Maybe
>>> commercial. Maybe open source.
>>>
>>> Given that MySQL/MariaDB is #2 in database market share and
>>> PostgreSQL is #4 and they are used by by a huge number of
>>> developers (magnitude 1 million), then the fact that there are no
>>> pre-compilers for MySQL/MariaDB and only two for PostgreSQL is a
>>> pretty good indication for very low interest for embedded SQL
>>> among developers.
>>
>> I think that has more to do with who is using each of these
>> database systems than the popularity of Embedded SQL. Embedded SQL
>> is used mostly by COBOL, followed by some Fortran, probably a
>> little PL/I. And, mostly mainframes or other large systems (like
>> VMS). It is MySQL/MariaDB that lack popularity in this community,
>> not Embedded SQL.
>
> That sounds very plausible.
>
> The change in programming languages used, the changes in platforms
> used and the change in databases used has undoubtedly contributed
> heavily to the demise of embedded SQL.
>
>>>> All of this shows a lack of interest in languages that most
>>>> people think are dying. Also in database systems not being
>>>> used for the kind of work that Oracle, RDP, DB2 and Postgres
>>>> are. I see nothing here that even hints at embedded SQL going
>>>> away.
>>>
>>> The fact that half the widely used databases has no
>>> pre-compilers available and the remaining half only has support
>>> for typical 2-3 out of maybe 20 languages used for database
>>> access shows that for the vast majority (95% magnitude) of
>>> projects then embedded SQL is not possible because no
>>> pre-compiler exist.
>>
>> I think there are other reasons for the lack of pre-compilers. The
>> API for all these Open Source DB's is basically C oriented. Why
>> would there be a pre-compiler for languages for which that is the
>> native API?
>
> Because embedded SQL is actually often shorter and easier to read
> than API calls.

Not with .LIS files. Precompilers make them illegible

>
> And we can also see that those databases with C pre-compilers also
> usually have C centric API's: Oracle OCI (and OCCI), DB2 CLI, PgSQL
> libpq.
>
>> Python, PHP, Perl, none of these are compiled so what would you
>> pre-compile to?
>
> A Cobol pre-compiler compiles to Cobol, so a Python/PHP pre-compiler
> would of course compile to Python/PHP.
>
> Since they are not compiled it would probably not be called
> pre-compiler, but transpiler.
>
> So: a Python/PHP transpiler would of course transpile to Python/PHP.
>
> But really same thing.
>
> AFAIK such a thing has never been made.

I heard of Babel having to dumb down Javascript ES6 to ES5

>
> And for pretty obvious reasons: for languages like Cobol and C
> embedded SQL may mean fewer lines than API calls, but for languages
> like Python and PHP embedded SQL would likely be more lines than API
> calls.
>
>>> And in the remaining few cases then it may be discarded due to
>>> uncertainty about the future of the pre-compiler or because the
>>> developers do not like it or don't know about it (most
>>> developers under age 50 does not know that embedded SQL exist).
>>
>> That I agree with but the question really is, why? It is not that
>> Embedded SQL is unpopular but that academia stopped teaching the
>> languages most likely to use it even though those languages are
>> still extremely common in the industry.
>
> That developers under 50 does not know embedded SQL must have
> something to do with educations.
>
> But I think it would be difficult to justify being taught. Too few
> would ever use it.
>
>>> Cobol is probably the only language where embedded SQL will be
>>> the most common choice for database access. The C/C++ crowd has
>>> moved to various standards based or database specific API's.
>>
>> As stated above, the databases API's are already targeted at C and
>> C++. What would an Embedded SQL Pre-Compiler convert it to?
>
> C (and C++).
>
> That is what Oracle, DB2 and PgSQL pre-compilers for C do.
>
> Arne
>
>

Den 2022-10-25 kl. 02:11, skrev Arne Vajhøj:
> On 10/24/2022 9:15 AM, Bill Gunshannon wrote:
>> On 10/23/22 19:05, Arne Vajhøj wrote:
>>> On 10/13/2022 9:18 PM, Bill Gunshannon wrote:
>>>> On 10/13/22 19:14, Arne Vajhøj wrote:
>>>>> MySQL/MariaDB - no pre-compilers
>>>>
>>>> No one has expressed a need or desire for it yet.  (I have done
>>>> some playing with making ESQL work but nothing production level.)
>>>> More a MySQL shortcoming than embedded SQL.
>>>>
>>>>> PostgreSQL - only C (from project itself - an open source Cobol exist)
>>>>
>>>> And that's the way Open Source works.  If there was a need other
>>>> languages would be supported.
>>>
>>> It is not really open source specific.
>>>
>>> If there is a demand for something then it will be created.
>>> Maybe commercial. Maybe open source.
>>>
>>> Given that MySQL/MariaDB is #2 in database market share
>>> and PostgreSQL is #4 and they are used by by a huge number
>>> of developers (magnitude 1 million), then the fact that there
>>> are no pre-compilers for MySQL/MariaDB and only two for PostgreSQL
>>> is a pretty good indication for very low interest for embedded
>>> SQL among developers.
>>
>> I think that has more to do with who is using each of these database
>> systems than the popularity of Embedded SQL.  Embedded SQL is used
>> mostly by COBOL, followed by some Fortran, probably a little PL/I.
>> And, mostly mainframes or other large systems (like VMS).  It is
>> MySQL/MariaDB that lack popularity in this community, not Embedded SQL.
>
> That sounds very plausible.
>
> The change in programming languages used, the changes in
> platforms used and the change in databases used has undoubtedly
> contributed heavily to the demise of embedded SQL.
>
>>>> All of this shows a lack of interest in languages that most people
>>>> think are dying.  Also in database systems not being used for the
>>>> kind of work that Oracle, RDP, DB2 and Postgres are.  I see nothing
>>>> here that even hints at embedded SQL going away.
>>>
>>> The fact that half the widely used databases has no pre-compilers
>>> available and the remaining half only has support for typical
>>> 2-3 out of maybe 20 languages used for database access shows that
>>> for the vast majority (95% magnitude) of projects then embedded
>>> SQL is not possible because no pre-compiler exist.
>>
>> I think there are other reasons for the lack of pre-compilers.  The API
>> for all these Open Source DB's is basically C oriented.  Why would there
>> be a pre-compiler for languages for which that is the native API?
>
> Because embedded SQL is actually often shorter and easier to
> read than API calls.
>
> And we can also see that those databases with C pre-compilers
> also usually have C centric API's: Oracle OCI (and OCCI), DB2 CLI,
> PgSQL libpq.
>
>> Python, PHP, Perl, none of these are compiled so what would you
>> pre-compile to?
>
> A Cobol pre-compiler compiles to Cobol,...

The pre-compiler read an "embedded-SQL Cobol" file, default filetype
is .SCO, and from that creates a "pure" Cobol (file type COB) file.
The pre-compiler just copies everything that is *not* within an
EXEC SQL/END_EXEC sections (the SQL code) to the output file.

The part within the EXEC SQL/END_EXEC sections is compiled by the
Rdb SQL pre-compiler into object code and replaces each section
with a normal CALL statement that calls that object code.

So, apart from replacing the EXEC SQL/END_EXEC with a CALL, there
is no other Cobol code "created" by the pre-compiler.

Say a very simple SCO file with this code in it:

exec sql
alter sequence SEQ_TEST restart
end_exec

And then run the pre-compiler with these switches:

$ sql$pre /list /machine /cobol jes.sco

The COB file will then have this "pure" Cobol code:

The top two lines are always something like:

*Generated by Oracle Rdb SQL V7.4-110 at 25-OCT-2022 09:01:47.68
*Source file is $1$DGA3310:[JES]JES.SCO;5

And the code part above now looks like:

* exec sql
* alter sequence SEQ_TEST restart
* end_exec
CALL "SQL$PRC1_47V07G3RBUD1G0AD0000" USING
SQLCA

The SQL code has been commented out and replaced with an CALL.

Now, since I run with /LIST and /MACHINE, the .LIS
file also have the generated Alpha code:

07C0 SQL$PRC1_47V07G3RBUD1G0AD0000::
23DEFFA0 07C0 LDA SP, -96(SP)
A65BFF10 07C4 LDQ R18, -240(R27)
223FFFFF 07C8 MOV -1, R17
B75E0030 07CC STQ R26, 48(SP)
[4-5 few pages of code removed...]
B2F60004 0A78 STL R23, 4(R22)
C3FFFF6B 0A7C BR L$109

Routine Size: 704 bytes, Routine Base: SQL$MACRO_CODE + 07C0

And the code from the main Cobol code (the CALL statement) is
there in the main machine code part:

A4A20060 0130 LDQ R5, 96(R2)
A4E20068 0134 LDQ R7, 104(R2)
A4820078 0138 LDQ R4, 120(R2)
2FFE0000 013C UNOP
6B5A4000 0140 JSR R26, SQL$PRC1_47V07G3RBUD1G0AD0000
A742FFB0 0144 LDQ R26, -80(R2)
47E03419 0148 MOV 1, R25

And in the LINK you include a reference to the Rdb RTL sharable
image so that the Rdb calls in the generated code can be resolved:

07C0 SQL$PRC1_47V07G3RBUD1G0AD0000::
6B5A4000 08B4 JSR R26, SQL$INIT_HANDLER_5
D35FFECF 08D0 BSR R26, SQL$DCL_LCL_HNDLS
6B5A4000 0904 JSR R26, SQL$GET_CLIENT2
6B5A4000 0920 JSR R26, SQL$RESET_ERRHDL_CALLED
D35FFDE2 0954 BSR R26, SQL$DEF_START_TXN_R2_TO_R11
D35FFF23 0980 BSR R26, MAP_SQLCODE_RET
6B5A4000 09F0 JSR R26, SQL$INTERPRET
D35FFEFF 0A10 BSR R26, MAP_SQLCODE_RET

So, no matter what language the pre-compiler supports, it just
needs to know how to call a machine routine from that language.
I guess that the code that the SQL is compiled into will be the
same (or at least very similar) no matter if the EXEC SQL/END_EXEC
is in a Cobol, Fortran or any other source language file.

The precompiler "just" need to know how to comment lines
and how to make a "call" from that language.

> so a Python/PHP
> pre-compiler would of course compile to Python/PHP.
>
> Since they are not compiled it would probably not be
> called pre-compiler, but transpiler.

That is a very different environment. I do not see that
working at all, at least not as the Rdb pre-compilöer works.

On 10/24/2022 10:12 PM, Richard Maher wrote:
> On 25/10/2022 8:11 am, Arne Vajhøj wrote:
>> On 10/24/2022 9:15 AM, Bill Gunshannon wrote:
>>> Python, PHP, Perl, none of these are compiled so what would you
>>> pre-compile to?
>>
>> A Cobol pre-compiler compiles to Cobol, so a Python/PHP pre-compiler
>> would of course compile to Python/PHP.
>>
>> Since they are not compiled it would probably not be called
>> pre-compiler, but transpiler.
>>
>> So: a Python/PHP transpiler would of course transpile to Python/PHP.
>>
>> But really same thing.
>>
>> AFAIK such a thing has never been made.
>
> I heard of Babel having to dumb down Javascript ES6 to ES5

Transpiling ESx->ESy and TS-ESz are common.

When I said "never been made" I meant specifically for
pre-processing embedded SQL.

Arne

On 10/13/2022 7:14 PM, Arne Vajhøj wrote:
> MySQL/MariaDB - no pre-compilers

Turned out not to be correct.

Stumbled over:

https://sourceforge.net/projects/dbpre/

Arne

On 25/10/2022 3:41 pm, Jan-Erik Söderholm wrote:
>                     CALL "SQL$PRC1_47V07G3RBUD1G0AD0000" USING
>                             SQLCA
>

A real-world version of that with all variables needed would be more
illuminating.

As would a more meaty DML statement(s)

Den 2022-10-26 kl. 03:50, skrev Richard Maher:
> On 25/10/2022 3:41 pm, Jan-Erik Söderholm wrote:
>>                      CALL "SQL$PRC1_47V07G3RBUD1G0AD0000" USING
>>                              SQLCA
>>
>
> A real-world version of that with all variables needed would be more
> illuminating.
>
> As would a more meaty DML statement(s)

It still shows the basic way of how it works.

But yes, I can make a "better" one...

On 10/25/2022 3:41 AM, Jan-Erik Söderholm wrote:
> Den 2022-10-25 kl. 02:11, skrev Arne Vajhøj:
>> On 10/24/2022 9:15 AM, Bill Gunshannon wrote:
>>> Python, PHP, Perl, none of these are compiled so what would you
>>> pre-compile to?
>>
>> A Cobol pre-compiler compiles to Cobol,...
>
> The pre-compiler read an "embedded-SQL Cobol" file, default filetype
> is .SCO, and from that creates a "pure" Cobol (file type COB) file.
> The pre-compiler just copies everything that is *not* within an
> EXEC SQL/END_EXEC sections (the SQL code) to the output file.
>
> The part within the EXEC SQL/END_EXEC sections is compiled by the
> Rdb SQL pre-compiler into object code and replaces each section
> with a normal CALL statement that calls that object code.
>
> So, apart from replacing the EXEC SQL/END_EXEC with a CALL, there
> is no other Cobol code "created" by the pre-compiler.
>
> Say a very simple SCO file with this code in it:
>
>         exec sql
>           alter sequence SEQ_TEST restart
>         end_exec
>
> And then run the pre-compiler with these switches:
>
> $ sql$pre /list /machine /cobol jes.sco
>
> The COB file will then have this "pure" Cobol code:
>
> The top two lines are always something like:
>
> *Generated by Oracle Rdb SQL V7.4-110 at 25-OCT-2022 09:01:47.68
> *Source file is $1$DGA3310:[JES]JES.SCO;5
>
> And the code part above now looks like:
>
> *        exec sql
> *          alter sequence SEQ_TEST restart
> *        end_exec
>                     CALL "SQL$PRC1_47V07G3RBUD1G0AD0000" USING
>                             SQLCA
>
>
> The SQL code has been commented out and replaced with an CALL.
>
> Now, since I run with /LIST and /MACHINE, the .LIS
> file also have the generated Alpha code:
>
>
>              07C0       SQL$PRC1_47V07G3RBUD1G0AD0000::

> Routine Size: 704 bytes,    Routine Base: SQL$MACRO_CODE + 07C0
>
> And the code from the main Cobol code (the CALL statement) is
> there in the main machine code part:

> 6B5A4000     0140               JSR     R26, SQL$PRC1_47V07G3RBUD1G0AD0000

> And in the LINK you include a reference to the Rdb RTL sharable
> image so that the Rdb calls in the generated code can be resolved:
>
>              07C0       SQL$PRC1_47V07G3RBUD1G0AD0000::
> 6B5A4000     08B4               JSR     R26, SQL$INIT_HANDLER_5
> D35FFECF     08D0               BSR     R26, SQL$DCL_LCL_HNDLS
> 6B5A4000     0904               JSR     R26, SQL$GET_CLIENT2
> 6B5A4000     0920               JSR     R26, SQL$RESET_ERRHDL_CALLED
> D35FFDE2     0954               BSR     R26, SQL$DEF_START_TXN_R2_TO_R11
> D35FFF23     0980               BSR     R26, MAP_SQLCODE_RET
> 6B5A4000     09F0               JSR     R26, SQL$INTERPRET
> D35FFEFF     0A10               BSR     R26, MAP_SQLCODE_RET

Typical a pre-compiler for a given database and language translate
the EXEC SQL section to a general database calls for that database.

Rdb has a slight variation that it generates a call to a generated
function that makes the actual general database calls for that Rdb.

It does not really change the general concept. Just good procedural
programming practice of moving chunks of code to a separate routine.

> So, no matter what language the pre-compiler supports, it just
> needs to know how to call a machine routine from that language.
> I guess that the code that the SQL is compiled into will be the
> same (or at least very similar) no matter if the EXEC SQL/END_EXEC
> is in a Cobol, Fortran or any other source language file.

The called function could be very similar except for maybe
some differences in ref/val passing of arguments and descriptor
types supported.

> The precompiler "just" need to know how to comment lines
> and how to make a "call" from that language.

A little bit more.

It also needs to parse and understand the EXEC SQL BEGIN/END
DECLARE SECTION as well.

>> so a Python/PHP
>> pre-compiler would of course compile to Python/PHP.
>>
>> Since they are not compiled it would probably not be
>> called pre-compiler, but transpiler.
>
> That is a very different environment. I do not see that
> working at all, at least not as the Rdb pre-compilöer works.

It is a very different environment so some things will be different.

But a .sqlphp file with:

$f1 = 123;
$f2 = 'ABC';
EXEC SQL INSERT INTO t1 VALUES(:$f1, :$f2);

could be transpiled into a .php file with:

$f1 = 123;
$f2 = 'ABC';
$stmt = $con->prepare('INSERT INTO T1 VALUES(:F1,:F2)');
$stmt->execute(array(':F1' => $f1, ':F2' => $f2));

Or of it was more like RDB:

$f1 = 123;
$f2 = 'ABC';
temp_func_1234567890($con, $f1, $f2);

where an included PHP file has:

function temp_func_1234567890($con, $f1, $f2) {
$stmt = $con->prepare('INSERT INTO T1 VALUES(:F1,:F2)');
$stmt->execute(array(':F1' => $f1, ':F2' => $f2));
}

Arne