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

[Richard Maher]

On 14/10/2022 7:21 pm, Jan-Erik Söderholm wrote:
> 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.
> 
> 

No it is NOT. The VMS Procedure Calling standard prescribes that you 
must interrogate the descriptor class to be fully compatible.

It was common sense for the language specifier to provide default 
passing mechanisms et al. Can't remember if your SQLMOD procedure can 
o/ride the default?