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

[Bill Gunshannon]

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:
>>>
>>>
>>> Unfortunately, when architectures are changed not all packages make it
>>> across to the new architecture.
>>
>> And the result is the loss of even more customers.  How many can VMS
>> afford to loose?
> 
> None. VSI are marketing to existing users, which is a fixed-size market.
> 
> There's no way that a completely new customer who has never seen VMS before
> will move to VMS for the first time in 2022/2023.
> 
>>>
>>> For example, VAXELN was abandoned when the move to Alpha occurred and
>>> it looks like there will be no Ada compiler for x86-64 VMS.
>>
>> That's just silly.  VAXELN was tied to the VAX architecture it would
>> have been abandoned no matter what architecture VMS moved to.
>>
> 
> Exactly. It's a perfect example of something that would be left behind.
> 
> Compilers are another good example. Because of the changes required to
> compilers to move to another architecture, that's another language that
> might not be available on the new architecture and hence a set of users
> with their own applications written in that language which are left
> without any viable path to move to the new architecture.
> 
>>>
>>> The question is, just how major are the packages that are being lost ?
>>
>> How major they are is dependent on the user, none of them are really
>> major to VSI.
>>
> 
> They are if it stops a noticable number of sites from moving to x86-64 VMS.
> 
>>> Oracle Classic is a major example of something that has been lost, but
>>> that's tied to VMS in general, not just x86-64 VMS.
>>>
>>> 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.  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.
But, long term, it's a better idea than the status quo.

> 
> If they have to rewrite their applications using Postgres, then that's
> another chunk of users that may just decide to run the Postgres application
> on Linux instead.

If they have to rely on the whims of someone with no real interest
in VMS to maintain their future, that's not so good either.

> 
>>>
>>> So the question is, of the other packages Marc uses, how many of them
>>> are in general use within the VMS user base as a whole ?
>>
>> Doesn't really matter if the loss of these means they can't or won't
>> move forward on VMS.
>>
> 
> Exactly.
> 
> Simon.
> 

bill