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

[Arne Vajhøj]

On 10/12/2022 4:20 PM, Bill Gunshannon wrote:
> On 10/12/22 13:30, Simon Clubley wrote:
>> On 2022-10-12, Bill Gunshannon <bill.gunshannon at gmail.com> wrote:
>>> On 10/12/22 09:05, Simon Clubley wrote:
>>>> There's been no negative comments about Rdb recently, so I assume that
>>>> is still on course for release on x86-64 VMS. Of course, if Rdb wasn't
>>>> released for x86-64 VMS then that would be a very serious blow to VSI's
>>>> plans.
>>>
>>> A database is the least serious of these problems.  VSI could easily
>>> (well, maybe  not easily) decide that Postgres was going to be the VMS
>>> database just like RDB was, at one time, a DEC product.  It is easily
>>> a suitable replacement for either Oracle or RDB.  Just suffers from NIH
>>> syndrome.
>>
>> So you think you can replace RDB with Postgres just like that in an
>> application ?
> No, not "just like that".  But at least an alternative could exist
> and not with someone with no interest in VMS controlling the strings.
> 
>> VSI have done some work here IIRC, but that's still going to be one hell
>> of a compatibility layer to avoid having to rewrite existing programs and
>> alter existing database operational procedures.
> 
> 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.

>                                  I have never used RDB (I have
> used Oracle) but I assume it supports EXEC SQL and the usual SQL
> syntax.  If so, moving could be fairly easy.  If not, could be a
> problem.  Of course, probably also depends on the language being used.

It will indeed depend on the language and the API used.

embedded SQL/C => relative easy (PgSQL has precompiler)

embedded SQL/Cobol => maybe easy (an open source precompiler supposedly 
exist and work)

embedded SQL/Pascal, Fortran ... => major rewrite (precompilers are not 
available)

modules/any language => major rewrite (concept not available)

SQL Services/C => major rewrite (API not available)

JDBC/Java, ... => easy

JPA/Java, ... => easy

DB API 2.0/Python => easy

On top of that problem there is always the risk of non-standard
SQL (stored procedures are notoriously problematic to port).

Arne