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

Tue Oct 25 03:41:29 EDT 2022

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.