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

[Simon Clubley]

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 ?

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.

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.

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

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.