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

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