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

[Arne Vajhøj]

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