[Info-vax] Oracle on VMS

[Bill Gunshannon]

On 11/21/16 11:17 PM, Arne Vajhøj wrote:
> On 11/20/2016 10:35 PM, Bill Gunshannon wrote:
>> On 11/20/16 8:59 PM, Arne Vajhøj wrote:
>>> On 11/20/2016 3:45 PM, Bill Gunshannon wrote:
>>>> On 11/19/16 10:26 PM, Arne Vajhøj wrote:
>>>>> On 11/19/2016 4:40 PM, Bill Gunshannon wrote:
>>>>>> Might be worth a look.  Just so people understand where I am coming
>>>>>> from, I am not really interested in either of the databases but I am
>>>>>> interested in how embedded SQL is implemented on the commercial DBs
>>>>>> because I am trying to look into implementing it for open source DBs
>>>>>> and GnuCOBOL.
>>>>>
>>>>> That sounds like a very interesting project.
>>>>
>>>> Gotta do something to keep me busy.
>>>>
>>>>> May I ask what databases you are targeting?
>>>>
>>>> Probably Postgres first but once I do the first one adding
>>>> others will be much easier.
>>>
>>> PostgreSQL already have support for embedded SQL in C.
>>>
>>> ECPG
>>>
>>> Source code is available so that may be a good starting point.
>>
>> I have looked at it but then, C and COBOL have much less in common
>> than one would think considering that C is the intermediate language
>> used by GnuCOBOL.  :-)
>
> At a high abstraction level they should be somewhat similar.

COBOL is the higher abstraction level but the libraries are written in
C which makes some of it problematic.  I have given some thought to just
writing new libraries specifically for COBOL, though.

>
> You encounter am EXEC SQL, that results in some statements going into
> that location and some declaration going in somewhere else.
>
> You could also consider generating both C code and Cobol
> calling that C code.
>
> It may sound a bit silly, but given that most of the native
> database API's will be C centric, then it may actually make
> it easier to do:
>
> Cobol code--->(Cobol friendly API)C code--->(C friendly API)DB library

Thus my comment above.  :-)

>
>>>>> And whether you want to implement the pre-compiler in Cobol?
>>>>
>>>> I have thought of that, too.  It has pluses and minuses but it is
>>>> definitely doable.  I also have an example partial pre-compiler for
>>>> C that is done in awk and yacc and the permission of the author to
>>>> extend it or develop further along those lines.
>>>
>>> I don't think Cobol or Fortran would be the best languages
>>> for the task.
>>
>> Actually, with the job being primarily reading simple records
>> and writing simple records COBOL is probably ideal for the
>> job.
>
> Hmm. I did not see the task as being primary reading and writing
> records. But hey I have never written an embedded SQL precompiler,
> so...

Sure, you read the COBOL source file.  For most lines you merely
write it back out again.  When you encounter an EXEC Block you
have to parse it, figure out the correct COBOL to accomplish it,
write that new COBOL out (usually leaving the EXEC Block there in
the form of comments).

Generating the new source file is easy in COBOL, figuring out what the
new COBOL should be is where the devil hides.

bill