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

[Bill Gunshannon]

On 10/12/22 17:33, Arne Vajhøj wrote:
> 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.

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.

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

Yes, but I would imagine given the two existing pre-compilers coming
up with one for Pascal and Fortran would not be all that difficult.
Of course, I would wonder how many people there are still using Pascal
and Fortran for database applications.  :-)

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

bill