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

[Jan-Erik Söderholm]

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.