[Info-vax] Oracle on VMS

[Arne Vajhøj]

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.

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

>>>> 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...

Arne