On Wednesday, September 27, 2023 at 8:53:13 PM UTC-4, David Turner wrote:
> How many people are running X86 variant of OpenVMS in Production?
> That is on the virtual machine....
> Just want to see when I should retire....
> ;0(
>
> David

they need to get it running native first before you can determine your retire date

On Wednesday, September 27, 2023 at 8:53:13 PM UTC-4, David Turner wrote:
> How many people are running X86 variant of OpenVMS in Production?

Probably not many today. But it will increase!

If we divide current VMS customers in 4 categories:
A) has moved to VMS x86-64
B) want to move to VMS x86-64 and has started test/development
C) want to move to VMS x86-64 but has not started test/development yet
(waiting for VMS Basic, waiting for Rdb, waiting for funding,
waiting for resources to free up from other projects etc.)
D) will never move to VMS x86-64

Right now category A is tiny as in zero or almost zero.

But over the coming years customers will move B -> A and C -> B -> A.

My expectation regarding category D would be:
* VMS VAX customers - almost everybody are frozen aka in D
* VMS Alpha customers - some are frozen aka in D, some just didn't like
Itanium and will migrate to VMS x86-64
* VMS Itanium - most will migrate to VMS x86-64

Arne

On 9/28/2023 4:04 PM, Arne Vajhøj wrote:
> On Wednesday, September 27, 2023 at 8:53:13 PM UTC-4, David Turner wrote:
>> How many people are running X86 variant of OpenVMS in Production?
>
> Probably not many today. But it will increase!
>
> If we divide current VMS customers in 4 categories:
> A) has moved to VMS x86-64
> B) want to move to VMS x86-64 and has started test/development
> C) want to move to VMS x86-64 but has not started test/development yet
>    (waiting for VMS Basic, waiting for Rdb, waiting for funding,
>    waiting for resources to free up from other projects etc.)
> D) will never move to VMS x86-64
>
> Right now category A is tiny as in zero or almost zero.
>
> But over the coming years customers will move B -> A and C -> B -> A.

One could use a random number generator to produce some
guesses:

2023 2024 2025 2026 2027 2028
A 0% 20% 45% 70% 75% 80%
B 30% 35% 15% 10% 5% 0%
C 50% 25% 10% 0% 0% 0%
D 20% 20% 20% 20% 20% 20%

But nobody knows.

Arne

On 9/28/23 10:57, ultr...@gmail.com wrote:
> On Wednesday, September 27, 2023 at 8:53:13 PM UTC-4, David Turner wrote:
>> How many people are running X86 variant of OpenVMS in Production?
>> That is on the virtual machine....
>> Just want to see when I should retire....
>> ;0(
>>
>> David
>
> they need to get it running native first before you can determine your retire date

I went to look up the definition of "retire" in the dictionary (shows
how old I am) and my wife had ripped out the page.

On 2023-09-28, ultr...@gmail.com <ultradwc@gmail.com> wrote:
> On Wednesday, September 27, 2023 at 8:53:13?PM UTC-4, David Turner wrote:
>> How many people are running X86 variant of OpenVMS in Production?
>> That is on the virtual machine....
>> Just want to see when I should retire....
>> ;0(

As of today, that number should be zero as x86-64 VMS is nowhere near
ready for running the mission-critical workloads that VMS is used for.

Due to these workloads, I don't think you can call it ready until at
least 6-12 months after everything is available to production-quality
standard and VMS is being built using native compilers/etc.

However, as of today, there should also be a good number of sites
actively testing it to determine if their applications work ok and
to find and report any problems back to VSI.

Don't forget there needs to be a business case for spending the money
to move to x86-64 VMS and a measured assessment of whether the new
platform at least meets the robustness guarantees that the company's
current architecture provides.

>
> they need to get it running native first before you can determine your retire date

It is running native. Do you actually mean running on bare metal ?

If so, that's a low priority as the market has very much changed
in that area.

Simon.

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

On 9/29/2023 8:38 AM, Simon Clubley wrote:
>> On Wednesday, September 27, 2023 at 8:53:13?PM UTC-4, David Turner wrote:
>>> How many people are running X86 variant of OpenVMS in Production?
>>> That is on the virtual machine....
>>> Just want to see when I should retire....
>
> As of today, that number should be zero as x86-64 VMS is nowhere near
> ready for running the mission-critical workloads that VMS is used for.

VMS x86-64 so far seems very stable.

The vast majority of bug reports relates to the native compilers and
they are technically still in field test I believe.

> Due to these workloads, I don't think you can call it ready until at
> least 6-12 months after everything is available to production-quality
> standard and VMS is being built using native compilers/etc.

VMS itself has been out for that time and is rock solid.

When everything is available in production quality must depend a
lot on for who.

I don't see any reason why customers should wait until VMS is build by
native compilers. Where the build is done does not matter for them.
Optimization in the VMS build should not matter either.

I suspect that a lot of customers are waiting for the native compilers
to become available in non-field-test version for what they need to
build, because the hassle of cross compiling their stuff matter
for them.

> However, as of today, there should also be a good number of sites
> actively testing it to determine if their applications work ok and
> to find and report any problems back to VSI.

Yes.

> Don't forget there needs to be a business case for spending the money
> to move to x86-64 VMS and a measured assessment of whether the new
> platform at least meets the robustness guarantees that the company's
> current architecture provides.

It will likely cost a lot less to migrate from VMS Alpha or VMS Itanium
to VMS x86-64 than to Linux.

Arne

On 2023-09-28, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 9/28/2023 4:04 PM, Arne Vajhøj wrote:
>> On Wednesday, September 27, 2023 at 8:53:13?PM UTC-4, David Turner wrote:
>>> How many people are running X86 variant of OpenVMS in Production?
>>
>> Probably not many today. But it will increase!
>>
>> If we divide current VMS customers in 4 categories:
>> A) has moved to VMS x86-64
>> B) want to move to VMS x86-64 and has started test/development
>> C) want to move to VMS x86-64 but has not started test/development yet
>>    (waiting for VMS Basic, waiting for Rdb, waiting for funding,
>>    waiting for resources to free up from other projects etc.)
>> D) will never move to VMS x86-64
>>
>> Right now category A is tiny as in zero or almost zero.
>>
>> But over the coming years customers will move B -> A and C -> B -> A.
>
> One could use a random number generator to produce some
> guesses:
>
> 2023 2024 2025 2026 2027 2028
> A 0% 20% 45% 70% 75% 80%
> B 30% 35% 15% 10% 5% 0%
> C 50% 25% 10% 0% 0% 0%
> D 20% 20% 20% 20% 20% 20%
>

Bloody hell, you and I actually agree on something because that
pretty much matches my mental model. :-) (But A at 20% in 2024 may be
rather too high.)

Your D) may be too low as well because by now, VMS has become very
much a legacy platform and companies may no longer be able to justify
the move to x86-64 VMS, especially given the move away from permanant
licences to time-limited licences. (Yes, I know VSI have made
concessions in that area, but IIRC, it doesn't involve selling licences
that are good forever, at least to most customers.)

There should also be an E) variant of C), which is "we really, really,
want to move to x86-64 VMS but will never be able to do so because
a product we need will never be available on it."

Simon.

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

On 2023-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 9/29/2023 8:38 AM, Simon Clubley wrote:
>>> On Wednesday, September 27, 2023 at 8:53:13?PM UTC-4, David Turner wrote:
>>>> How many people are running X86 variant of OpenVMS in Production?
>>>> That is on the virtual machine....
>>>> Just want to see when I should retire....
>>
>> As of today, that number should be zero as x86-64 VMS is nowhere near
>> ready for running the mission-critical workloads that VMS is used for.
>
> VMS x86-64 so far seems very stable.
>
> The vast majority of bug reports relates to the native compilers and
> they are technically still in field test I believe.
>

The job/pension question also kicks in, as in manager to minion:

"Why should I risk my job/pension replacing our existing systems with
something that isn't even finished yet ??? What possible reason could
I have for authorising its purchase today instead of in a couple of
years when it is finished and it has had a chance to prove itself ?"

Unless you are in a desperate need for some specific reason, and hence
are willing to take the risk, I can't see an answer to the above that
will satisfy a manager which isn't emotionally involved in the VMS world.

Simon.

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

On 9/29/2023 1:57 PM, Simon Clubley wrote:
> On 2023-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 9/29/2023 8:38 AM, Simon Clubley wrote:
>>>> On Wednesday, September 27, 2023 at 8:53:13?PM UTC-4, David Turner wrote:
>>>>> How many people are running X86 variant of OpenVMS in Production?
>>>>> That is on the virtual machine....
>>>>> Just want to see when I should retire....
>>>
>>> As of today, that number should be zero as x86-64 VMS is nowhere near
>>> ready for running the mission-critical workloads that VMS is used for.
>>
>> VMS x86-64 so far seems very stable.
>>
>> The vast majority of bug reports relates to the native compilers and
>> they are technically still in field test I believe.
>
> The job/pension question also kicks in, as in manager to minion:
>
> "Why should I risk my job/pension replacing our existing systems with
> something that isn't even finished yet ??? What possible reason could
> I have for authorising its purchase today instead of in a couple of
> years when it is finished and it has had a chance to prove itself ?"
>
> Unless you are in a desperate need for some specific reason, and hence
> are willing to take the risk, I can't see an answer to the above that
> will satisfy a manager which isn't emotionally involved in the VMS world.

Everything staying forever as today is usually not an option. Especially
not for someone risk adverse as hardware and software goes EOL and
becomes risks.

So for the risk adverse then a VMS Alpha or VMS Itanium system
will have to be replaced at some point in time.

The questions are:
* replace with a VMS x86-64 system or with a non-VMS system
* when to replace

Cost wise it will be lower migration cost to stay on VMS and lower
migration cost by changing faster (operational cost for x86-64 will
be lower than for Alpha/Itanium).

Risk minimization means to start the testing as soon as
possible and wait going to production until any additional
test (in house or external) is not likely to reduce risk
further in any significant way.

If the system has been tested 3 or 6 or 9 months (depending on
the complexity of the application) and there are no outstanding
issues, then there is no point in continuing waiting.

Arne

On 29/09/2023 18:57, Simon Clubley wrote:
> On 2023-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 9/29/2023 8:38 AM, Simon Clubley wrote:
>>>> On Wednesday, September 27, 2023 at 8:53:13?PM UTC-4, David Turner wrote:
>>>>> How many people are running X86 variant of OpenVMS in Production?
>>>>> That is on the virtual machine....
>>>>> Just want to see when I should retire....
>>>
>>> As of today, that number should be zero as x86-64 VMS is nowhere near
>>> ready for running the mission-critical workloads that VMS is used for.
>>
>> VMS x86-64 so far seems very stable.
>>
>> The vast majority of bug reports relates to the native compilers and
>> they are technically still in field test I believe.
>>
>
> The job/pension question also kicks in, as in manager to minion:
>
> "Why should I risk my job/pension replacing our existing systems with
> something that isn't even finished yet ??? What possible reason could
> I have for authorising its purchase today instead of in a couple of
> years when it is finished and it has had a chance to prove itself ?"
>
> Unless you are in a desperate need for some specific reason, and hence
> are willing to take the risk, I can't see an answer to the above that
> will satisfy a manager which isn't emotionally involved in the VMS world.
>
> Simon.
>

Simon, do you ever have anything positive to say about VMS?

--
Chris

On 2023-09-29, Chris Townley <news@cct-net.co.uk> wrote:
>
> Simon, do you ever have anything positive to say about VMS?
>

Yes. I've mentioned multiple times how I considered VMS clustering to
literally be a generation ahead of anything else available at the
time it was introduced. Normally, when someone says that, it can
usually be dismissed as hype, but in the case of VMS it is absolutely
true.

VMS clustering was so advanced that it literally took 20-25 years
from its introduction for Linux/Windows/etc to even start to approach
its full capabilites. It is the gold standard by which other clustering
products are measured.

However, if you look at the kinds of things I am saying, they tend to
refer to how VMS is remaining stagnant in general in terms of offered
functionality while expectations are changing in the marketplace and
how the other OS alternatives are moving forward to meet those expectations.

When I talk about policies (such as the time-limited production licences),
that reflects how people who are NOT emotionally involved in VMS, but who
are the people that approve equipment replacement, are likely to see the
situation.

How exactly do you persuade a bill-payer, who is not emotionally involved
with VMS, to pay for replacing permanent licences with time-limited licences
from a company that is not big enough to guarantee they will be around in
5 years ? Some people obviously DO agree to that. What about the others ?

Also, consider this: VMS, in 2023, has a static userbase with very limited
opportunities for expansion. That means the use of VMS, and hence the number
of VSI customers, are going to decline over time.

How exactly would you grow the VMS userbase to continue to make it a viable
userbase well into the future ?

Everyone around here is very emotionally involved in VMS. You can shoot
the messenger if you wish (ie: me), but that doesn't change the things
I am saying.

Simon.

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

In article <uf7i03$6nld$2@dont-email.me>,
Chris Townley <news@cct-net.co.uk> wrote:
>On 29/09/2023 18:57, Simon Clubley wrote:
>> On 2023-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 9/29/2023 8:38 AM, Simon Clubley wrote:
>>>>> On Wednesday, September 27, 2023 at 8:53:13?PM UTC-4, David Turner wrote:
>>>>>> How many people are running X86 variant of OpenVMS in Production?
>>>>>> That is on the virtual machine....
>>>>>> Just want to see when I should retire....
>>>>
>>>> As of today, that number should be zero as x86-64 VMS is nowhere near
>>>> ready for running the mission-critical workloads that VMS is used for.
>>>
>>> VMS x86-64 so far seems very stable.
>>>
>>> The vast majority of bug reports relates to the native compilers and
>>> they are technically still in field test I believe.
>>>
>>
>> The job/pension question also kicks in, as in manager to minion:
>>
>> "Why should I risk my job/pension replacing our existing systems with
>> something that isn't even finished yet ??? What possible reason could
>> I have for authorising its purchase today instead of in a couple of
>> years when it is finished and it has had a chance to prove itself ?"
>>
>> Unless you are in a desperate need for some specific reason, and hence
>> are willing to take the risk, I can't see an answer to the above that
>> will satisfy a manager which isn't emotionally involved in the VMS world.
>
>Simon, do you ever have anything positive to say about VMS?

It seems to me that if you want to see VMS succeed, in the sense
of maintaining a robust presence in the market and seeing
continued or even increased adoption, one would do well to
recognize those areas where it currently falls short, in the
hopes that they may be addressed. Similarly with arguments
about its adoption and market strategy.

In this regard, I think Simon is raising important questions
that are too often poo-pooed. It serves no one to praise VMS's
strong points if they ignore the weaknesses that are preventing
it from succeeding in the market. Unless, of course, one wishes
to see it fail.

- Dan C.

On 10/2/2023 9:02 AM, Dan Cross wrote:
> In article <uf7i03$6nld$2@dont-email.me>,
> Chris Townley <news@cct-net.co.uk> wrote:
>> On 29/09/2023 18:57, Simon Clubley wrote:
>>> On 2023-09-29, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> VMS x86-64 so far seems very stable.
>>>>
>>>> The vast majority of bug reports relates to the native compilers and
>>>> they are technically still in field test I believe.
>>>
>>> The job/pension question also kicks in, as in manager to minion:
>>>
>>> "Why should I risk my job/pension replacing our existing systems with
>>> something that isn't even finished yet ??? What possible reason could
>>> I have for authorising its purchase today instead of in a couple of
>>> years when it is finished and it has had a chance to prove itself ?"
>>>
>>> Unless you are in a desperate need for some specific reason, and hence
>>> are willing to take the risk, I can't see an answer to the above that
>>> will satisfy a manager which isn't emotionally involved in the VMS world.
>>
>> Simon, do you ever have anything positive to say about VMS?
>
> It seems to me that if you want to see VMS succeed, in the sense
> of maintaining a robust presence in the market and seeing
> continued or even increased adoption, one would do well to
> recognize those areas where it currently falls short, in the
> hopes that they may be addressed. Similarly with arguments
> about its adoption and market strategy.
>
> In this regard, I think Simon is raising important questions
> that are too often poo-pooed. It serves no one to praise VMS's
> strong points if they ignore the weaknesses that are preventing
> it from succeeding in the market. Unless, of course, one wishes
> to see it fail.

I guess it depends a bit on how one sees the world.

If one believe that VSI is clueless and do not know where VMS
fall short, then having some smart people on the internet tell
them about the problems is good for VMS.

If one believes that VSI got some smart people that perfectly
well understands the problems and are prioritizing the limited
development resources based in business priorities, then
having some internet people that like to push their
pet ideas whine about the problems is just an annoyance
for those following those forums.

Arne

In article <ufflcc$36btu$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 10/2/2023 9:02 AM, Dan Cross wrote:
>> It seems to me that if you want to see VMS succeed, in the sense
>> of maintaining a robust presence in the market and seeing
>> continued or even increased adoption, one would do well to
>> recognize those areas where it currently falls short, in the
>> hopes that they may be addressed. Similarly with arguments
>> about its adoption and market strategy.
>>
>> In this regard, I think Simon is raising important questions
>> that are too often poo-pooed. It serves no one to praise VMS's
>> strong points if they ignore the weaknesses that are preventing
>> it from succeeding in the market. Unless, of course, one wishes
>> to see it fail.
>
>I guess it depends a bit on how one sees the world.
>
>If one believe that VSI is clueless and do not know where VMS
>fall short, then having some smart people on the internet tell
>them about the problems is good for VMS.
>
>If one believes that VSI got some smart people that perfectly
>well understands the problems and are prioritizing the limited
>development resources based in business priorities, then
>having some internet people that like to push their
>pet ideas whine about the problems is just an annoyance
>for those following those forums.

The history of VMS is full of very smart people making poor
decisions. I don't think that anyone thinks that VSI is
"clueless". But I find it amusing that you seem to believe
that the admittedly limited engineering resources aren't
complemented by similarly limited business resources.

- Dan C.

On 2023-10-02, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> I guess it depends a bit on how one sees the world.
>
> If one believe that VSI is clueless and do not know where VMS
> fall short, then having some smart people on the internet tell
> them about the problems is good for VMS.
>
> If one believes that VSI got some smart people that perfectly
> well understands the problems and are prioritizing the limited
> development resources based in business priorities, then
> having some internet people that like to push their
> pet ideas whine about the problems is just an annoyance
> for those following those forums.
>

Arne, you have just made the same mistake that most people have done
in that you have considered VSI as one entity instead of as both an
engineering entity and a management entity.

The engineers clearly know what they are doing, but the same cannot
be said about the management.

This is the same management that one day just decided to tell its
customers, that from now on, they would be renting VMS instances
from VSI instead of owning those instances outright and then just
expected those customers to be OK with that.

This is the same management that went around saying VMS was the most
secure operating system on the planet and placing a great big target
on the backs of their customers as a result if certain people had noticed.
This, BTW, was the kind of language that provoked me into doing my DCL
research.

This is the same management that one day suddenly decided that VMS was
going to be a blockchain player, even though its unsuitable for that, and
spent goodness knows how much time on this until they finally abandoned
that idea.

Simon.

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

On 10/3/23 7:33 AM, Simon Clubley wrote:

> This is the same management that went around saying VMS was the most
> secure operating system on the planet and placing a great big target
> on the backs of their customers as a result if certain people had noticed.
> This, BTW, was the kind of language that provoked me into doing my DCL
> research.
>
> This is the same management that one day suddenly decided that VMS was
> going to be a blockchain player, even though its unsuitable for that, and
> spent goodness knows how much time on this until they finally abandoned
> that idea.

In these particular cases, I don't think it is the same management. I'm
pretty sure the people who said those things are no longer with VSI and
are not the people currently on this list:

https://vmssoftware.com/about/key-managers/

In article <ufha4n$3jrt6$1@dont-email.me>,
Craig A. Berry <craigberry@nospam.mac.com> wrote:
>
>On 10/3/23 7:33 AM, Simon Clubley wrote:
>
>> This is the same management that went around saying VMS was the most
>> secure operating system on the planet and placing a great big target
>> on the backs of their customers as a result if certain people had noticed.
>> This, BTW, was the kind of language that provoked me into doing my DCL
>> research.
>>
>> This is the same management that one day suddenly decided that VMS was
>> going to be a blockchain player, even though its unsuitable for that, and
>> spent goodness knows how much time on this until they finally abandoned
>> that idea.
>
>In these particular cases, I don't think it is the same management. I'm
>pretty sure the people who said those things are no longer with VSI and
>are not the people currently on this list:
>
>https://vmssoftware.com/about/key-managers/

That's good! Maybe they heard from the community and listened
to it. :-)

- Dan C.

On 10/3/2023 8:33 AM, Simon Clubley wrote:
> On 2023-10-02, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> I guess it depends a bit on how one sees the world.
>>
>> If one believe that VSI is clueless and do not know where VMS
>> fall short, then having some smart people on the internet tell
>> them about the problems is good for VMS.
>>
>> If one believes that VSI got some smart people that perfectly
>> well understands the problems and are prioritizing the limited
>> development resources based in business priorities, then
>> having some internet people that like to push their
>> pet ideas whine about the problems is just an annoyance
>> for those following those forums.
>
>
> Arne, you have just made the same mistake that most people have done
> in that you have considered VSI as one entity instead of as both an
> engineering entity and a management entity.
>
> The engineers clearly know what they are doing, but the same cannot
> be said about the management.

Sure about that?

> This is the same management that one day just decided to tell its
> customers, that from now on, they would be renting VMS instances
> from VSI instead of owning those instances outright and then just
> expected those customers to be OK with that.

They switched to a business model that they believed would
make more money for VSI long term.

Customers were not happy, customers complained, they made one
adjustment, customers still complained, they made another
adjustment, customers seemed to have stopped complaining,
maybe customers are not happy about where it ended but
they seem to have accepted it.

There is no evidence that it cost them a dollar in lost sale.
And if their original calculations were correct then it will
mean more revenue for VSI long term.

Seems like good business to me.

The fact that some people on the internet speculate that
they could loose business does not really mean anything.

> This is the same management that went around saying VMS was the most
> secure operating system on the planet and placing a great big target
> on the backs of their customers as a result if certain people had noticed.

You have mentioned that a gazillion times.

But so far we have not seen anything happen.

Again internet speculation doesn't mean anything.

> This is the same management that one day suddenly decided that VMS was
> going to be a blockchain player, even though its unsuitable for that, and
> spent goodness knows how much time on this until they finally abandoned
> that idea.

As I remember the story then it goes like:
- blockchain (for use as ledger - not for crypto currency)
was hot in the finance and supply chain business - banks, IBM
etc. were into it
- VSI started cooperation with a company Swirlds that had a blockchain
like technology called hashgraph so VSI could say they had a
solution for that
- if VSI had ever gotten a customer for the thing then it would
have run on VMS Itanium as it is Java
- as far as I know then VSI never got a customer for it, but it
could have happened - the australian exchange with the failed
blockchain project was an old VMS customer
- blockchain and hashgraph cooled off pretty fast
- Swirld and hashgraph dropped out of the VSI material

I have not seen any reports of significant engineering resources being
spent and I do not know what it should be - porting Java from Linux to
VMS is usually a matter of converting start.sh to start.com and
figure out the dreaded VMS logicals to proper emulate Unix file system
behavior.

So VSI marketing side:
- try to increase prices
- exaggerate the benefits of their products wildly when trying to sell them
- like to say that they are "in" on latest overhyped trends

Is that any different from what MS, IBM, Oracle etc. do?

Arne

On 10/3/2023 11:46 AM, Dan Cross wrote:
> In article <ufha4n$3jrt6$1@dont-email.me>,
> Craig A. Berry <craigberry@nospam.mac.com> wrote:
>>
>> On 10/3/23 7:33 AM, Simon Clubley wrote:
>>
>>> This is the same management that went around saying VMS was the most
>>> secure operating system on the planet and placing a great big target
>>> on the backs of their customers as a result if certain people had noticed.
>>> This, BTW, was the kind of language that provoked me into doing my DCL
>>> research.
>>>
>>> This is the same management that one day suddenly decided that VMS was
>>> going to be a blockchain player, even though its unsuitable for that, and
>>> spent goodness knows how much time on this until they finally abandoned
>>> that idea.
>>
>> In these particular cases, I don't think it is the same management. I'm
>> pretty sure the people who said those things are no longer with VSI and
>> are not the people currently on this list:
>>
>> https://vmssoftware.com/about/key-managers/
>
> That's good! Maybe they heard from the community and listened
> to it. :-)

I doubt that they listened to the community.

But maybe they did.

It could have been:
1) the enthusiasts on c.o.v talked about the hot new
blockchain and hashgraph technologies and their
potential for VMS
2) the VSI marketing people besides producing marketing BS
also had a deep interest in Macro-32 programming and
silently followed the group
3) on the advice of their informal advisors in c.o.v
they started the cooperation with Swirld about
hashgraph
4) blockchain projects started to fail and besides
the normal implementation failure it became
clear that it was a solution looking for a problem
to solve
5) the observant on c.o.v noted the failures
6) VSI marketing again listened and dropped
Swirld and hashgraph
7) the 20/20 hindsight people on c.o.v now whines about VSI ever
entering into the cooperation

But I find this way more likely:
1) the enthusiasts on c.o.v talked about the hot new
blockchain and hashgraph technologies and their
potential for VMS
2) the VSI marketing people has never hearda bout c.o.v but
they read about blockchain in the glossy marketing
material (in electronic form today) and heard about
it at trade shows
3) so they decide that "so ein ding müssen wir auch haben"
and they started the cooperation with Swirld about
hashgraph
4) blockchain projects started to fail and besides
the normal implementation failure it became
clear that it was a solution looking for a problem
to solve
5) the observant on c.o.v noted the failures
6) VSI marketing heard about the same in industry gossip
and dropped Swirld and hashgraph
7) the 20/20 hindsight people on c.o.v now whines about VSI ever
entering into the cooperation

Arne

On 10/3/2023 7:41 AM, Dan Cross wrote:
> In article <ufflcc$36btu$1@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 10/2/2023 9:02 AM, Dan Cross wrote:
>>> It seems to me that if you want to see VMS succeed, in the sense
>>> of maintaining a robust presence in the market and seeing
>>> continued or even increased adoption, one would do well to
>>> recognize those areas where it currently falls short, in the
>>> hopes that they may be addressed. Similarly with arguments
>>> about its adoption and market strategy.
>>>
>>> In this regard, I think Simon is raising important questions
>>> that are too often poo-pooed. It serves no one to praise VMS's
>>> strong points if they ignore the weaknesses that are preventing
>>> it from succeeding in the market. Unless, of course, one wishes
>>> to see it fail.
>>
>> I guess it depends a bit on how one sees the world.
>>
>> If one believe that VSI is clueless and do not know where VMS
>> fall short, then having some smart people on the internet tell
>> them about the problems is good for VMS.
>>
>> If one believes that VSI got some smart people that perfectly
>> well understands the problems and are prioritizing the limited
>> development resources based in business priorities, then
>> having some internet people that like to push their
>> pet ideas whine about the problems is just an annoyance
>> for those following those forums.
>
> The history of VMS is full of very smart people making poor
> decisions.

VMS history is full of decisions that when looked at 10/20/30/40
years later turn out to be poor decisions.

It is usually a futile exercise to analyze what should have been done
in the past given what we know today.

> I don't think that anyone thinks that VSI is
> "clueless". But I find it amusing that you seem to believe
> that the admittedly limited engineering resources aren't
> complemented by similarly limited business resources.

There is huge difference between implementing big software
projects and prioritizing big software projects.

Fewer people means longer time implementing big software
projects.

Fewer people means shorter time prioritizing big software projects.

Arne

On 2023-10-03, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <ufha4n$3jrt6$1@dont-email.me>,
> Craig A. Berry <craigberry@nospam.mac.com> wrote:
>>
>>On 10/3/23 7:33 AM, Simon Clubley wrote:
>>
>>> This is the same management that went around saying VMS was the most
>>> secure operating system on the planet and placing a great big target
>>> on the backs of their customers as a result if certain people had noticed.
>>> This, BTW, was the kind of language that provoked me into doing my DCL
>>> research.
>>>
>>> This is the same management that one day suddenly decided that VMS was
>>> going to be a blockchain player, even though its unsuitable for that, and
>>> spent goodness knows how much time on this until they finally abandoned
>>> that idea.
>>
>>In these particular cases, I don't think it is the same management. I'm
>>pretty sure the people who said those things are no longer with VSI and
>>are not the people currently on this list:
>>
>>https://vmssoftware.com/about/key-managers/
>
> That's good! Maybe they heard from the community and listened
> to it. :-)
>

Note that Craig left off the list the item that is currently an active
outstanding issue for many people. :-)

Simon.

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

On 2023-10-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
> But I find this way more likely:
> 1) the enthusiasts on c.o.v talked about the hot new
> blockchain and hashgraph technologies and their
> potential for VMS

I think you will find people were saying at the time this was
a waste of time and effort - hindsight was not involved.

Those people turned out to be right by the way. :-)

Simon.

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

On 2023-10-03, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Customers were not happy, customers complained, they made one
> adjustment, customers still complained, they made another
> adjustment, customers seemed to have stopped complaining,
> maybe customers are not happy about where it ended but
> they seem to have accepted it.
>

Or they silently said "sod this" and moved to another solution.

People have mentioned here in the past that the move to time-limited
production licences have stopped their move to x86-64 VMS.

Simon.

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

On Tuesday, October 3, 2023 at 3:33:07 PM UTC+3, Simon Clubley wrote:
>
> The engineers clearly know what they are doing, but the same cannot
> be said about the management.
>

I'd speculate that it's combination of engineers and management.
Engineers are competent, but aging. They have the common tendency
of the age - preference to remain in comfort zone.
Now, since they *are* competent the *can* be productive outside of
their comfort zone, but unlikely to come here on their own. They have
to be dragged. By management, who else? And not primitively, primitive
dragging would face strong opposition. The have to be dragged in skilful
manner.

My favorite example is programming tools where, in my opinion, cross-tools
hosted on non-VMS x86-64 should have been produced first. After that,
x86-64 port could have been productized, even without all native tools ready.
They could have come later.
Instead of that VMS-Itanium hosted tools were created first, not because it
was technically easier, but because in this way old competent engineers didn't
have to leave their comfort zone.

On 10/4/2023 9:23 AM, Michael S wrote:
> On Tuesday, October 3, 2023 at 3:33:07 PM UTC+3, Simon Clubley wrote:
>>
>> The engineers clearly know what they are doing, but the same cannot
>> be said about the management.
>>
>
> I'd speculate that it's combination of engineers and management.
> Engineers are competent, but aging. They have the common tendency
> of the age - preference to remain in comfort zone.
> Now, since they *are* competent the *can* be productive outside of
> their comfort zone, but unlikely to come here on their own. They have
> to be dragged. By management, who else? And not primitively, primitive
> dragging would face strong opposition. The have to be dragged in skilful
> manner.
>
> My favorite example is programming tools where, in my opinion, cross-tools
> hosted on non-VMS x86-64 should have been produced first. After that,
> x86-64 port could have been productized, even without all native tools ready.
> They could have come later.
> Instead of that VMS-Itanium hosted tools were created first, not because it
> was technically easier, but because in this way old competent engineers didn't
> have to leave their comfort zone.
>

I am a bit confused by the above. Do you mean tools on VMS but
not on x86 or do you mean tools not on VMS.

In any event, what was chosen was tools on Itanium VMS. I,
for one, am not so sure that was a good idea. I am sure the
numbers would never be released but I wonder what the current
breakdown of licensed production VMS architectures are. (even
percentages would be interesting). In any event, I think
requiring one to have an Itanium in order to move to x86 is
not really a good idea.

Of course the other big question would be can one move directly
from VAX to x86. Not likely, I suppose, as I would imagine
most people still on VAX may be there for hardware rather than
software reasons.

But, as I said, I would be very interested in the current
breakdown of architectures still running production VMS.

bill