Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

VSI strategy for OpenVMS

1,562 views
Skip to first unread message

John Dallman

unread,
Sep 12, 2021, 7:19:13 AM9/12/21
to
The current "open source on OpenVMS" caused me to wonder how VSI's
strategic plan for OpenVMS and its applications works. Some bits are
fairly easy to deduce, but others are far less clear.

The OpenVMS customer base has been slowly shrinking for quite a while.
Since VSI lives on support contract income, this is a serious problem.
Reasons for organisations to carry on using the OS include:

* High reliability.
* OS-level clustering, rather than application-level clustering.
* Other specific features of OpenVMS.
* Lack of ability to migrate to another OS at reasonable cost.
* Customer staff who prefer it, and have the ability to block changes.

None of those reasons can overcome a prolonged lack of hardware that can
run OpenVMS, so VSI are doing the right thing by making it possible to
run the OS on commodity hardware, and providing the programming languages
and other tools needed to port a lot of customers' software to x86.
Exactly which languages and tools should get priority depends on what
will get VSI the most income, and they know far more than us about what
their customers are using.

But the reasons for carrying on using OpenVMS don't obviously indicate a
particular field or market segment of computing where OpenVMS usage is
concentrated. It seems likely that the existing customers are a somewhat
random selection of the organisations that took up VMS in the 1970s
through 1990s. That creates a problem.

DEC was a large organisation, capable of having expert teams in most
fields of computing. VSI probably can't manage that. Their efforts to
grow the customer base will presumably have to be focused on one or two
areas. There seems to be a potential problem after customers start
transitioning to x86: demand for software for many different fields, from
a wide variety of customers.

Porting open source is one answer, but there's an awful lot of it out
there, making for a huge task, and doing it is at least as complicated as
porting Linux software to Windows. That suggests that a Linux
compatibility layer/library might be a good idea, but there have been
several past attempts at that, and none seem to have got established.

It's not obvious to me what VSI should concentrate on once OpenVMS is
working on x86 and customer transitions have become routine. It is clear
that should be some kind(s) of server work, but not which ones.

Opinions?

John

Arne Vajhøj

unread,
Sep 12, 2021, 1:39:09 PM9/12/21
to
On 9/12/2021 7:18 AM, John Dallman wrote:
> The current "open source on OpenVMS" caused me to wonder how VSI's
> strategic plan for OpenVMS and its applications works. Some bits are
> fairly easy to deduce, but others are far less clear.
>
> The OpenVMS customer base has been slowly shrinking for quite a while.
> Since VSI lives on support contract income, this is a serious problem.
> Reasons for organisations to carry on using the OS include:

> But the reasons for carrying on using OpenVMS don't obviously indicate a
> particular field or market segment of computing where OpenVMS usage is
> concentrated. It seems likely that the existing customers are a somewhat
> random selection of the organisations that took up VMS in the 1970s
> through 1990s. That creates a problem.
>
> DEC was a large organisation, capable of having expert teams in most
> fields of computing. VSI probably can't manage that. Their efforts to
> grow the customer base will presumably have to be focused on one or two
> areas. There seems to be a potential problem after customers start
> transitioning to x86: demand for software for many different fields, from
> a wide variety of customers.
>
> Porting open source is one answer, but there's an awful lot of it out
> there, making for a huge task, and doing it is at least as complicated as
> porting Linux software to Windows. That suggests that a Linux
> compatibility layer/library might be a good idea, but there have been
> several past attempts at that, and none seem to have got established.
>
> It's not obvious to me what VSI should concentrate on once OpenVMS is
> working on x86 and customer transitions have become routine. It is clear
> that should be some kind(s) of server work, but not which ones.
>
> Opinions?

I don't think VSI has said much about their plans beyond x86-64 port.

And it will also take a few years to get it out, get customers
migrated and stabilize it and fill the most obvious gaps.

But to me the focus should be obvious: operating systems are
sold by applications - VMS needs more applications, so work
should focus on getting more applications developed for and
ported to VMS.

Thinking loud that must include:
- extend available compilers
- create a model for distribution of native open source libraries (PCSI
is not the way top go for dozens or hundreds of libraries) - use
VCPKG as inspiration
- work with open source projects to include VMS as supported platform
in main repo
- work with commercial products to add support for VMS
- create VMS calling standard V2 with OO support and
add support for it to at least C++, Pascal and Basic

Arne




Phillip Helbig (undress to reply)

unread,
Sep 12, 2021, 2:53:54 PM9/12/21
to
In article <shldvp$1jl$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<ar...@vajhoej.dk> writes:

> > The current "open source on OpenVMS" caused me to wonder how VSI's
> > strategic plan for OpenVMS and its applications works. Some bits are
> > fairly easy to deduce, but others are far less clear.

> But to me the focus should be obvious: operating systems are
> sold by applications - VMS needs more applications, so work
> should focus on getting more applications developed for and
> ported to VMS.
>
> Thinking loud that must include:
> - extend available compilers

All compilers should support the latest standard, or at least the latest
supported by those from other vendors. And they need to be good
quality. DEC compilers used to be the gold standard.

> - work with open source projects to include VMS as supported platform
> in main repo

Definitely. LaTeX! Firefox!!!

John Dallman

unread,
Sep 12, 2021, 6:46:05 PM9/12/21
to
In article <shldvp$1jl$1...@gioia.aioe.org>, ar...@vajhoej.dk (Arne Vajhøj)
wrote:

> But to me the focus should be obvious: operating systems are
> sold by applications - VMS needs more applications, so work
> should focus on getting more applications developed for and
> ported to VMS.

Yes, but which applications? What fields of computing will give the best
return for VSI?

I doubt, for example, that Libre Office or Firefox will be especially
worthwhile. Current GUI apps are likely to need more than the X11/Motif
stack, and providing Qt looks like a big job. Databases, middleware and
the like might well be more worthwhile.

John

Arne Vajhøj

unread,
Sep 12, 2021, 7:17:27 PM9/12/21
to
The money is in business applications.

So COTS business applications and in-house business applications.

Those two need the same: compilers, libraries, databases, web servers,
message queue servers, cache servers etc..

Arne

Arne Vajhøj

unread,
Sep 12, 2021, 7:19:44 PM9/12/21
to
On 9/12/2021 2:53 PM, Phillip Helbig (undress to reply) wrote:
> In article <shldvp$1jl$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
> <ar...@vajhoej.dk> writes:
>
>>> The current "open source on OpenVMS" caused me to wonder how VSI's
>>> strategic plan for OpenVMS and its applications works. Some bits are
>>> fairly easy to deduce, but others are far less clear.
>
>> But to me the focus should be obvious: operating systems are
>> sold by applications - VMS needs more applications, so work
>> should focus on getting more applications developed for and
>> ported to VMS.
>>
>> Thinking loud that must include:
>> - extend available compilers
>
> All compilers should support the latest standard, or at least the latest
> supported by those from other vendors. And they need to be good
> quality. DEC compilers used to be the gold standard.

I think the compilers in general are still quite god.

They are just behind standard/feature wise.

>> - work with open source projects to include VMS as supported platform
>> in main repo
>
> Definitely. LaTeX! Firefox!!!

That will not sell many VMS licenses.

Arne

Chris Townley

unread,
Sep 12, 2021, 7:53:57 PM9/12/21
to
Perhaps Microsoft will port Edge to VMS?

That might keep Phillip happy :)

--
Chris

Simon Clubley

unread,
Sep 12, 2021, 8:02:54 PM9/12/21
to
On 2021-09-12, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
> In article <shldvp$1jl$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
><ar...@vajhoej.dk> writes:
>>
>> Thinking loud that must include:
>> - extend available compilers
>
> All compilers should support the latest standard, or at least the latest
> supported by those from other vendors. And they need to be good
> quality. DEC compilers used to be the gold standard.
>

DEC compilers stagnated for over 20 years while everyone else carried
on developing their compilers. We are now seeing the results of that.

>> - work with open source projects to include VMS as supported platform
>> in main repo

This is important because there will be security issues. Having VMS
as a supported platform within the project itself will be vital to
getting an updated release out quickly to VMS users.

>
> Definitely. LaTeX! Firefox!!!
>

That's not a strategy for VMS Phillip. That's a suicide note.

Simon.

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

Simon Clubley

unread,
Sep 12, 2021, 8:13:53 PM9/12/21
to
On 2021-09-12, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> The money is in business applications.
>
> So COTS business applications and in-house business applications.
>
> Those two need the same: compilers, libraries, databases, web servers,
> message queue servers, cache servers etc..
>

A good starting point will be to see what open source software IBM
is making sure works with z/OS. That collection of software is likely
to be the same list of applications needed for VMS.

Arne Vajhøj

unread,
Sep 12, 2021, 8:25:50 PM9/12/21
to
On 9/12/2021 8:13 PM, Simon Clubley wrote:
> On 2021-09-12, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>>
>> The money is in business applications.
>>
>> So COTS business applications and in-house business applications.
>>
>> Those two need the same: compilers, libraries, databases, web servers,
>> message queue servers, cache servers etc..
>
> A good starting point will be to see what open source software IBM
> is making sure works with z/OS. That collection of software is likely
> to be the same list of applications needed for VMS.

I am not so sure.

Different server sizes (very expensive pieces of iron), different
customers (mostly huge organizations) and different integration
strategy (my understanding is that IBM does not want to run the new
stuff under z/OS but want to run the new stuff on VM's running
Linux on z).

Arne


Scott Dorsey

unread,
Sep 12, 2021, 8:30:47 PM9/12/21
to
LaTeX won't sell very many, but the port is not that big a deal. Firefox
won't sell very many either, but the port would be a major undertaking.
So my guess is that we see the former and not the latter.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Arne Vajhøj

unread,
Sep 12, 2021, 8:41:12 PM9/12/21
to
On 9/12/2021 8:30 PM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
>> On 9/12/2021 2:53 PM, Phillip Helbig (undress to reply) wrote:
>>>
>>> Definitely. LaTeX! Firefox!!!
>>
>> That will not sell many VMS licenses.
>
> LaTeX won't sell very many, but the port is not that big a deal. Firefox
> won't sell very many either, but the port would be a major undertaking.
> So my guess is that we see the former and not the latter.

If there are willingness among VMS users to spend just a little time
porting latest LaTex to VMS, then sure it could happen.

Arne



Craig A. Berry

unread,
Sep 12, 2021, 9:31:00 PM9/12/21
to
FireFox now requires a Rust compiler in addition to C or C++. That
isn't completely out of the realm of possibilities with LLVM soon to be
available, but it also doesn't come for free. It would be a sizable
project and unlikely to be a realistic goal for a small compiler team
that has spent the last five or six years just trying to get the
existing VMS compilers into a state where they can target x86_64.

A chromium-based browser is also theoretically possible, but would
involve porting the V8 Javascript engine as well as several other very
large projects. Again, getting to OpenVMS x64 will remove or mitigate
some of the most obvious technical obstacles, but won't make anything
happen automatically or for free, and there is not much of a business
case to make it happen.

Joukj

unread,
Sep 13, 2021, 5:53:16 AM9/13/21
to
Qt would be nice, but I see more applications which are based on gtk. I
know there exists a port of gtk1, but newer versions are not available.
John Malmerg and myself both tried independently to get a newer versing
working, but only came to a versions that compiles, but crashes in most
cases at run-time.
A lot of Debugging is needed. But a good version of gtk+ would realy
help to port a lot of nice other tools.

Regards
Jouk

Bill Gunshannon

unread,
Sep 13, 2021, 8:07:28 AM9/13/21
to
Any browser requires a desktop. I thought that idea had been abandoned?

bill

Bill Gunshannon

unread,
Sep 13, 2021, 8:09:30 AM9/13/21
to
That and fork(). :-)

bill

chris

unread,
Sep 13, 2021, 8:29:09 AM9/13/21
to
VMS will need some sort of unix abstraction layer to make use of all
the Linux and other os open source packages. Done right, it should
make the porting task much easier.

As for Firefox. I tried to build a current version from source to run
under FreeBSD Sparc a couple of years ago, but put it to one side
after a shed load of dependent packages had been built. May revisit,
but it's no easy task at all...

Chris


Arne Vajhøj

unread,
Sep 13, 2021, 9:38:43 AM9/13/21
to
On 9/13/2021 8:29 AM, chris wrote:
> On 09/13/21 13:09, Bill Gunshannon wrote:
>> On 9/13/21 5:53 AM, Joukj wrote:
>>> John Dallman wrote:
>>>> In article <shldvp$1jl$1...@gioia.aioe.org>, ar...@vajhoej.dk (Arne Vajhøj)
>>>> wrote:
>>>>
>>>> I doubt, for example, that Libre Office or Firefox will be especially
>>>> worthwhile. Current GUI apps are likely to need more than the X11/Motif
>>>> stack, and providing Qt looks like a big job. Databases, middleware and
>>>> the like might well be more worthwhile.
>>>>
>>> Qt would be nice, but I see more applications which are based on gtk.
>>> I know there exists a port of gtk1, but newer versions are not
>>> available.
>>> John Malmerg and myself both tried independently to get a newer
>>> versing working, but only came to a versions that compiles, but
>>> crashes in most cases at run-time.
>>> A lot of Debugging is needed. But a good version of gtk+ would realy
>>> help to port a lot of nice other tools.
>>
>> That and fork(). :-)
>
> VMS will need some sort of unix abstraction layer to make use of all
> the Linux and other os open source packages. Done right, it should
> make the porting task much easier.

Compilers with support for latest language standards, runtime libraries
that provide what is expected today of any OS, VMS support in common
libraries will certainly help.

But I doubt there is value in true Linux emulation (non-Linux Unix
is not relevant). It probably would have been relevant 15 years ago.
But I am not so sure about today.

The industry trend is moving towards huge libraries that encapsulate
the OS and avoid OS specific calls in application code.

Sure it is easier if those libraries can use the Linux code
on VMS, but applications should outnumber libraries by a few magnitudes.

If someone really needs Linux then they will probably run Linux.

I believe Microsofts take on WSL is telling - they started by
trying to emulate Linux and then in version 2 they just started a VM
and ran Linux.

> As for Firefox. I tried to build a current version from source to run
> under FreeBSD Sparc a couple of years ago, but put it to one side
> after a shed load of dependent packages had been built. May revisit,
> but it's no easy task at all...

Yep.

High cost. Almost no revenue. No chance VSI will work on that.

Arne

Arne Vajhøj

unread,
Sep 13, 2021, 9:44:09 AM9/13/21
to
The importance of fork has decrease a lot the last couple of
decades.

The world is moving to the threading model.

C++ 11, C 11, Java, C#, Rust etc..

(even Python supports threads even though GIL reduces
its usability)

Arne


Arne Vajhøj

unread,
Sep 13, 2021, 10:15:13 AM9/13/21
to
Apropos.

https://vmssoftware.com/resources/blog/2021-09-09-thinking-of-moving-to-postresql/

<quote>
SSIO (Shared Stream I/O) is mentioned on our roadmap, and once this is
available, customers will be able to run PostgreSQL (and other
applications requiring SSIO) natively on their OpenVMS systems, which is
most definitely something to look forward to.
</quote>

I like the use of the phrase "once this is available".

:-)

Arne

Jan-Erik Söderholm

unread,
Sep 13, 2021, 10:46:14 AM9/13/21
to
What is written into the roadmap is:
"Shared Stream IO (SSIO) (Non-clustered)"

That "non-clustred" phrase might be an issue for some...


Arne Vajhøj

unread,
Sep 13, 2021, 10:49:03 AM9/13/21
to
> What is written into the roadmap is:
> "Shared Stream IO (SSIO) (Non-clustered)"
>
> That "non-clustred" phrase might be an issue for some...

True.

But I don't think PostgreSQL on VMS will support active/active with
shared storage anyway, so it should not be a problem for PostgreSQL
port.

Arne

Jan-Erik Söderholm

unread,
Sep 13, 2021, 10:50:21 AM9/13/21
to
I think so too. And what VMS has to have is good support for messaging
and other interoperational standards and tools.

Personally, I'd like to see an updated and supported IBM MQ client.
Doesn't have to be a full MQ server, there is already an IBM WebSphere
environment in the corporate IT map that has all that...

calliet gérard

unread,
Sep 13, 2021, 12:51:11 PM9/13/21
to
I have been waiting for such a thread for years. A VMS user who dares
open questions about the VMS supplier strategy.

I'm not kidding. The VMS ecosystem culture is not about collaboration
between the suppliers and the users to determine their common future.

I have been thinking about differences of paradigms between IBM,
Free-World and VMS. In the Free-World everyone is the leader. In IBM
world the board is the leader, and the customer is the king. In VMS
world the board is the leader, and he does'nt need any advice from
anyone, because he knows what is good :)

What makes me happy is the time did change somethings. Decades of
utilisation of the very-well-thought Digital products created
wery-well-formed users. And perhaps they can now help the board.

My opinion is that a successfull strategy has to be founded - also - on
an accute analysis of the identity of the ecosystem.

The first question could be: why did VMS survive? I remember discussion
here in 2013. Everyone was thinking VMS will die. And it was a very well
founded opinion. VMS could have die like sun, for example: old things
die, new things take their place... I'm not sure we have totally
understood why VMS escaped the common rule. And it seems we have to
understand that to continue escaping the common rule.

There are two pieces of answer on that. First we have to understand what
have been the major things which explain the success of VMS in the
beginning. And second, understand how theses specific qualities match
our time needs and trends.

My hypothesis is twofold. The bet for mini-computer - against the main
frame, and more ingenieered than the unix constant rewriting - was about
locality and for mastery. VMS survived because it offers at the place
where it is needed a way of mastering the computer usage.

- A parenthesis for the new VMS ceo, who had been leader in a company
helping main frame users : VMS ecosystem is not at all the same world.
IBM & co did succeeded with a strong value for service. VMS users are
more individual masters, who are a little bit suspicious about the
marvelous offers of service -

Locality and mastering, which involves temporal stability, are the new
major needs of the future decades. It is yet a little bit clandestine,
because the huge investments are all about miracoulous service. However
the x milions invested on Vms are just a tip compared to the billions
invested to serve us, it is not the same world. And it is possible that
VMS is beginning to build something more humbly usefull, which would
resist even to the storms.

To be able to cope with the long cycles, maturing tools because of real
needs, being able to analyze the successes and the failures, thinking
structurally, avoiding waste, thinking about reusability... all that is
the major (future) trend of our time. It is that trend which has been
met with the revival of VMS, and which is at least one of the conditions
of the revival.

So I think VSI strategy will be a success if VSI knows about that, and
conforms with the actual potential of the ecosystem. And also if the
users themselves analyze why they are successfull with VMS, and dare
express their advice.

I have to say until today the VMS ecosystem strategy is not at all on
such a way.

You are talking about what will be the future with the transition to x86
done. I dare say let's work for this transition to be a success, because
it is a huge challenge, and perhaps don't think only in terms of
transition, but in terms of respect of the passage of time. And even we
could emit critics, if we think they can help... but it is another thread.

Gérard Calliet





--
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

Phillip Helbig (undress to reply)

unread,
Sep 13, 2021, 1:22:40 PM9/13/21
to
In article <iq8t7t...@mid.individual.net>, Bill Gunshannon
<bill.gu...@gmail.com> writes:

> Any browser requires a desktop. I thought that idea had been abandoned?

Most people have a desk. I'm sure that there are x86 systems which will
fit on such a desk (or at least beside it). A monitor will certainly
fit on the desk. VSI has said that they will support the on-chip
graphics (few if any VMS users will need more than that). So, by that
definition, I will have a VSI-VMS desktop system. Will it run Windows
applications? No, but I neither need nor want them.

Phillip Helbig (undress to reply)

unread,
Sep 13, 2021, 1:23:15 PM9/13/21
to
In article <shng6j$iru$1...@gioia.aioe.org>, chris
<chris-...@tridac.net> writes:

> On 09/13/21 13:09, Bill Gunshannon wrote:
> > On 9/13/21 5:53 AM, Joukj wrote:
> >> John Dallman wrote:
> >>> In article <shldvp$1jl$1...@gioia.aioe.org>, ar...@vajhoej.dk (Arne VajhÞj)
> >>> wrote:
> >>>
> >>> I doubt, for example, that Libre Office or Firefox will be especially
> >>> worthwhile. Current GUI apps are likely to need more than the X11/Motif
> >>> stack, and providing Qt looks like a big job. Databases, middleware and
> >>> the like might well be more worthwhile.
> >>>
> >> Qt would be nice, but I see more applications which are based on gtk.
> >> I know there exists a port of gtk1, but newer versions are not available.
> >> John Malmerg and myself both tried independently to get a newer
> >> versing working, but only came to a versions that compiles, but
> >> crashes in most cases at run-time.
> >> A lot of Debugging is needed. But a good version of gtk+ would realy
> >> help to port a lot of nice other tools.
> >>
> >
> >
> > That and fork(). :-)
> >
> > bill
> >
>
> VMS will need some sort of unix abstraction layer to make use of all
> the Linux and other os open source packages.

Posix 2.0? :-)

Scott Dorsey

unread,
Sep 13, 2021, 1:24:03 PM9/13/21
to
Bill Gunshannon <bill.gu...@gmail.com> wrote:
>
>Any browser requires a desktop. I thought that idea had been abandoned?

No it doesn't, that is the beauty of DECWindows. Mind you, there's really
no reason to have a browser on a machine without a desktop, other than
for diagnostic purposes and downloads. But it's not required, and it is
occasionally handy.

Does "occasionally handy" warrant an enormous effort to port a modern browser
to VMS? I don't think so. But if someone here wants to give it a try, have
at it. That's the beauty of open source.

chris

unread,
Sep 13, 2021, 2:03:59 PM9/13/21
to
On 09/13/21 14:38, Arne Vajhøj wrote:

>
> Compilers with support for latest language standards, runtime libraries
> that provide what is expected today of any OS, VMS support in common
> libraries will certainly help.

Perhaps, but that doesn't provide the abstraction needed to decouple
the os from the source.

>
> But I doubt there is value in true Linux emulation (non-Linux Unix
> is not relevant). It probably would have been relevant 15 years ago.
> But I am not so sure about today.

I tend to agree with that, but a standard C library abstraction layer
and header files would allow a lot of unix related (note: not
necessarily linux) open source to build far more easily.

Starting to see a lot more apps in Java now, so that would be useful
to have as well, if not already done...

Chris

Arne Vajhøj

unread,
Sep 13, 2021, 2:15:54 PM9/13/21
to
On 9/13/2021 2:03 PM, chris wrote:
> On 09/13/21 14:38, Arne Vajhøj wrote:
>> Compilers with support for latest language standards, runtime libraries
>> that provide what is expected today of any OS, VMS support in common
>> libraries will certainly help.
>
> Perhaps, but that doesn't provide the abstraction needed to decouple
> the os from the source.

Not for the libraries but for the applications.

The application developers just use the library.

Whether that library is using the same OS function or are #ifdef vms
does not matter for the application programmers.

>> But I doubt there is value in true Linux emulation (non-Linux Unix
>> is not relevant). It probably would have been relevant 15 years ago.
>> But I am not so sure about today.
>
> I tend to agree with that, but a standard C library abstraction layer
> and header files would allow a lot of unix related (note: not
> necessarily linux) open source to build far more easily.

That stuff is useful.

Emulating reading from /dev/urandom may not be as useful.

> Starting to see a lot more apps in Java now, so that would be useful
> to have as well, if not already done...

Java 8 is available for VMS. (Itanium, Alpha is stuck on Java 5)

Java 11 is not.

And Java 17 will not be when it is released tomorrow.

Arne

Arne Vajhøj

unread,
Sep 13, 2021, 2:36:19 PM9/13/21
to
On 9/13/2021 10:50 AM, Jan-Erik Söderholm wrote:
> Den 2021-09-13 kl. 15:38, skrev Arne Vajhøj:
>> On 9/13/2021 8:29 AM, chris wrote:
>>> VMS will need some sort of unix abstraction layer to make use of all
>>> the Linux and other os open source packages. Done right, it should
>>> make the porting task much easier.
>>
>> Compilers with support for latest language standards, runtime libraries
>> that provide what is expected today of any OS, VMS support in common
>> libraries will certainly help.
>>
>> But I doubt there is value in true Linux emulation (non-Linux Unix
>> is not relevant). It probably would have been relevant 15 years ago.
>> But I am not so sure about today.
>>
>> The industry trend is moving towards huge libraries that encapsulate
>> the OS and avoid OS specific calls in application code.
>>
>> Sure it is easier if those libraries can use the Linux code
>> on VMS, but applications should outnumber libraries by a few magnitudes.
>>
>> If someone really needs Linux then they will probably run Linux.
>
> I think so too. And what VMS has to have is good support for messaging
> and other interoperational standards and tools.
>
> Personally, I'd like to see an updated and supported IBM MQ client.
> Doesn't have to be a full MQ server, there is already an IBM WebSphere
> environment in the corporate IT map that has all that...

Message queues are certainly something relevant.

Note that it is really a matrix.

Message queue:
* IBM MQ
* AMQP standard
* STOMP standard
* OpenWire (Apache)
* Kafka

Language/technology:
* C/C++
* descriptor languages
* Python
* Java
* PHP

So we have:
* IBM MQ - C/C++ in old version
* AMQP - C/C++ (VSI)
* STOMP - C/C++ (open source that builds on VMS)
* AMQP - Python
* STOMP - Python (??)
* all - Java (pure Java client libs)

Anything missing?

Arne


Dave Froble

unread,
Sep 13, 2021, 2:39:59 PM9/13/21
to
On 9/13/2021 10:46 AM, Jan-Erik Söderholm wrote:
Back in the day I did some work for a customer. They had a cluster, all
at one site, of maybe 6 11/780 systems. The reason for the cluster was
for additional compute capability. Today, with multi-core CPUs, that
particular need is serviced without running a VMS cluster.

Yes, there are multiple reasons to run a VMS cluster. But compute
resources for the most part is no longer one of those reasons.

I have no information to know what the breakdown is among VMS cluster
users. But, I'll pull an Arne and state my factless opinion. I'm
thinking that VMS clusters will not be an issue for many VMS users.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Simon Clubley

unread,
Sep 13, 2021, 2:42:04 PM9/13/21
to
On 2021-09-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 9/13/2021 2:03 PM, chris wrote:
>>
>> I tend to agree with that, but a standard C library abstraction layer
>> and header files would allow a lot of unix related (note: not
>> necessarily linux) open source to build far more easily.
>
> That stuff is useful.
>
> Emulating reading from /dev/urandom may not be as useful.
>

Only because VMS doesn't have random number device drivers with a
central entropy pool and with access to kernel-level information
that allows it to generate better quality entropy.

In normal circumstances, if VMS itself supported random number
generation to the same standards as on other operating systems,
/dev/urandom would be a _very_ useful thing to emulate.

Emulating a blocking /dev/random would also be a very good thing
to emulate if VMS had a suitable device driver for that as well.

Dave Froble

unread,
Sep 13, 2021, 2:44:16 PM9/13/21
to
On 9/13/2021 8:29 AM, chris wrote:
That seems to be the problem with building an application by going out
and pulling in a bunch of apps, tools, and such. Consider how much
better a browser might be if it was purpose designed and implemented
rather than a kluge of pieces from elsewhere.

Simon Clubley

unread,
Sep 13, 2021, 2:46:04 PM9/13/21
to
On 2021-09-13, Dave Froble <da...@tsoft-inc.com> wrote:
>
> I have no information to know what the breakdown is among VMS cluster
> users. But, I'll pull an Arne and state my factless opinion. I'm
> thinking that VMS clusters will not be an issue for many VMS users.
>

Attacking Arne is a bit of a change from you always disagreeing with me. :-)

You aren't starting to agree with me in general are you ? :-)

Simon.

PS: $ set response/mode=good_natured

Simon Clubley

unread,
Sep 13, 2021, 2:49:05 PM9/13/21
to
On 2021-09-13, Dave Froble <da...@tsoft-inc.com> wrote:
>
> That seems to be the problem with building an application by going out
> and pulling in a bunch of apps, tools, and such. Consider how much
> better a browser might be if it was purpose designed and implemented
> rather than a kluge of pieces from elsewhere.
>

Implementing a full-blown browser these days is probably about as
much work as implementing an operating system.

It shouldn't be like that, but it is unfortunately.

Simon.

Arne Vajhøj

unread,
Sep 13, 2021, 2:55:16 PM9/13/21
to
On 9/13/2021 2:42 PM, Simon Clubley wrote:
> On 2021-09-13, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 9/13/2021 2:03 PM, chris wrote:
>>>
>>> I tend to agree with that, but a standard C library abstraction layer
>>> and header files would allow a lot of unix related (note: not
>>> necessarily linux) open source to build far more easily.
>>
>> That stuff is useful.
>>
>> Emulating reading from /dev/urandom may not be as useful.
>
> Only because VMS doesn't have random number device drivers with a
> central entropy pool and with access to kernel-level information
> that allows it to generate better quality entropy.
>
> In normal circumstances, if VMS itself supported random number
> generation to the same standards as on other operating systems,
> /dev/urandom would be a _very_ useful thing to emulate.
>
> Emulating a blocking /dev/random would also be a very good thing
> to emulate if VMS had a suitable device driver for that as well.

VMS should have a way of providing such data.

But providing a pseudo to read from is *nix specific and
in many ways an outdated approach.

Application developers should use the standard libraries for their
programming language to get the data (Java SecureRandom, Python
SystemRandom etc.). Those libraries use an OS specific
way to get the data - reading from /dev/urandom on Linux,
calling CAPI or CNG on Windows, calling a future
LIB$CSPRNG on VMS.

Arne





Arne Vajhøj

unread,
Sep 13, 2021, 2:58:13 PM9/13/21
to
VMS clusters are probably pretty rare today.

But since the specific topic is about a feature not
supporting clustering used by an application that does not support
(this type of) clustering then it will not be a problem.

Arne



Arne Vajhøj

unread,
Sep 13, 2021, 3:02:15 PM9/13/21
to
On 9/13/2021 2:49 PM, Simon Clubley wrote:
> On 2021-09-13, Dave Froble <da...@tsoft-inc.com> wrote:
>> That seems to be the problem with building an application by going out
>> and pulling in a bunch of apps, tools, and such. Consider how much
>> better a browser might be if it was purpose designed and implemented
>> rather than a kluge of pieces from elsewhere.
>
> Implementing a full-blown browser these days is probably about as
> much work as implementing an operating system.
>
> It shouldn't be like that, but it is unfortunately.

It needs to do a lot.

HTML and CSS support.

JavaScript support - and JIT compilation is a must have.

Graphic formats support.

Bookmarks.

History.

Print.

Saving of credentials.

Web Assembly.

SSL.

HTTP/2.

Anonymous browsing.

Etc.

Arne

Phillip Helbig (undress to reply)

unread,
Sep 13, 2021, 4:29:23 PM9/13/21
to
In article <sho5ts$lt3$1...@dont-email.me>, Dave Froble
<da...@tsoft-inc.com> writes:

> Yes, there are multiple reasons to run a VMS cluster. But compute
> resources for the most part is no longer one of those reasons.

There are certainly many big VMS customers who run clusters partly for
increased computing power. Of course, disaster tolerance, rolling
upgrades, and so on are also reasons.

> I have no information to know what the breakdown is among VMS cluster
> users. But, I'll pull an Arne and state my factless opinion. I'm
> thinking that VMS clusters will not be an issue for many VMS users.

Does "many" mean more than half? Even if more than half of the users,
perhaps not more than half of the machines.

Phillip Helbig (undress to reply)

unread,
Sep 13, 2021, 4:31:55 PM9/13/21
to
In article <sho6eu$7e1$4...@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2021-09-13, Dave Froble <da...@tsoft-inc.com> wrote:
> >
> > That seems to be the problem with building an application by going out
> > and pulling in a bunch of apps, tools, and such. Consider how much
> > better a browser might be if it was purpose designed and implemented
> > rather than a kluge of pieces from elsewhere.
> >
>
> Implementing a full-blown browser these days is probably about as
> much work as implementing an operating system.

There is something between Lynx (which runs fine on VMS) and a
full-blown modern browser. Most VMS users who want a modern browser on
VMS would probably not need all of the features of a typical modern
browser, but more than with what is available now, say with an old
version of Mozilla.

Scott Dorsey

unread,
Sep 13, 2021, 4:57:20 PM9/13/21
to
Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>In article <sho5ts$lt3$1...@dont-email.me>, Dave Froble
><da...@tsoft-inc.com> writes:
>
>> Yes, there are multiple reasons to run a VMS cluster. But compute
>> resources for the most part is no longer one of those reasons.
>
>There are certainly many big VMS customers who run clusters partly for
>increased computing power. Of course, disaster tolerance, rolling
>upgrades, and so on are also reasons.

In the case of web services, clusters get you improved reliability, more
CPU, but most importantly more I/O. The thing is, few people are using
VMS for web services, and that's a shame because it's something where it
could do well.

Jan-Erik Söderholm

unread,
Sep 13, 2021, 5:56:53 PM9/13/21
to
And I think that you are right. Most VMS loads can be handled by single
system VMS systems today. And todays systems a way more relaible then what
the 11/7x0 once was...



Dave Froble

unread,
Sep 13, 2021, 6:35:00 PM9/13/21
to
On 9/13/2021 2:46 PM, Simon Clubley wrote:
> On 2021-09-13, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> I have no information to know what the breakdown is among VMS cluster
>> users. But, I'll pull an Arne and state my factless opinion. I'm
>> thinking that VMS clusters will not be an issue for many VMS users.
>>
>
> Attacking Arne is a bit of a change from you always disagreeing with me. :-)

I'm not attacking, I'm copying ...

> You aren't starting to agree with me in general are you ? :-)

I don't agree or disagree with anyone, I just state my opinions ...

Dave Froble

unread,
Sep 13, 2021, 6:40:34 PM9/13/21
to
:-) :-)

Jan-Erik, I'm ALWAYS right. I thought you knew that.

:-)

chris

unread,
Sep 13, 2021, 8:01:18 PM9/13/21
to
A lot of system management is done via browsers, for years now. Also,
for software dev, nothing beats a windowing system with multiple
terminal windows and tabbed full screen editors. I used to be pretty
deft with edt on a vt terminal but those days are gone forever. All the
ilom i've worked with works far better using a browser for access. A
sort of universal access method for systems. So yes, lack of a browser
might be seen as a serious disadvantage.

As for built in frame buffer support, they are often very low end
hardware devices and none i've seen have been good or fast enough
for X windows use. Important to know what's being promised in that
respect...

Chris

Arne Vajhøj

unread,
Sep 13, 2021, 8:09:22 PM9/13/21
to
I find that hard to see.

Web services need:
* low cost HW
* low cost OS & web SW
* uptodate web SW

Arne

Arne Vajhøj

unread,
Sep 13, 2021, 8:12:08 PM9/13/21
to
On 9/13/2021 4:29 PM, Phillip Helbig (undress to reply) wrote:
> In article <sho5ts$lt3$1...@dont-email.me>, Dave Froble
> <da...@tsoft-inc.com> writes:
>> Yes, there are multiple reasons to run a VMS cluster. But compute
>> resources for the most part is no longer one of those reasons.
>
> There are certainly many big VMS customers who run clusters partly for
> increased computing power. Of course, disaster tolerance, rolling
> upgrades, and so on are also reasons.

30 years ago: certainly.

Today: not so sure.

A single Itanium got lots of power.

Disaster tolerance can be achieved in different ways.

>> I have no information to know what the breakdown is among VMS cluster
>> users. But, I'll pull an Arne and state my factless opinion. I'm
>> thinking that VMS clusters will not be an issue for many VMS users.
>
> Does "many" mean more than half? Even if more than half of the users,
> perhaps not more than half of the machines.

Half??

I would be surprised if it was >5%.

Arne


Arne Vajhøj

unread,
Sep 13, 2021, 8:14:06 PM9/13/21
to
On 9/13/2021 8:01 PM, chris wrote:
> On 09/13/21 18:24, Scott Dorsey wrote:
>> Bill Gunshannon<bill.gu...@gmail.com>  wrote:
>>> Any browser requires a desktop.  I thought that idea had been abandoned?
>>
>> No it doesn't, that is the beauty of DECWindows.  Mind you, there's
>> really
>> no reason to have a browser on a machine without a desktop, other than
>> for diagnostic purposes and downloads.  But it's not required, and it is
>> occasionally handy.
>>
>> Does "occasionally handy" warrant an enormous effort to port a modern
>> browser
>> to VMS?  I don't think so.  But if someone here wants to give it a
>> try, have
>> at it.  That's the beauty of open source.
>
> A lot of system management is done via browsers, for years now. Also,
> for software dev, nothing beats a windowing system with multiple
> terminal windows and tabbed full screen editors. I used to be pretty
> deft with edt on a vt terminal but those days are gone forever. All the
> ilom i've worked with works far better using a browser for access. A
> sort of universal access method for systems. So yes, lack of a browser
> might be seen as a serious disadvantage.

Web interfaces are very common for admin stuff today.

But usually running the browser on a PC will work fine.

Arne

Phillip Helbig (undress to reply)

unread,
Sep 14, 2021, 12:37:06 AM9/14/21
to
In article <shohf2$qnm$3...@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com>
writes:

> And I think that you are right. Most VMS loads can be handled by single
> system VMS systems today.

That was probably true in 1980 as well. But loads have increased since
then.

> And todays systems a way more relaible then what
> the 11/7x0 once was...

Sure. And people are doing a lot more than they were 40 years ago.
There are certainly clusters which exist because one machine isn't
enough. Maybe not the majority of customers, but perhaps the majority
of revenue, I don't know.

Phillip Helbig (undress to reply)

unread,
Sep 14, 2021, 12:40:00 AM9/14/21
to
In article <shopcl$b49$2...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<ar...@vajhoej.dk> writes:

> On 9/13/2021 4:29 PM, Phillip Helbig (undress to reply) wrote:
> > In article <sho5ts$lt3$1...@dont-email.me>, Dave Froble
> > <da...@tsoft-inc.com> writes:
> >> Yes, there are multiple reasons to run a VMS cluster. But compute
> >> resources for the most part is no longer one of those reasons.
> >
> > There are certainly many big VMS customers who run clusters partly for
> > increased computing power. Of course, disaster tolerance, rolling
> > upgrades, and so on are also reasons.
>
> 30 years ago: certainly.
>
> Today: not so sure.
>
> A single Itanium got lots of power.

Sure, but what are big VMS customers doing today?

> Disaster tolerance can be achieved in different ways.

But none as good as a VMS cluster.

> >> I have no information to know what the breakdown is among VMS cluster
> >> users. But, I'll pull an Arne and state my factless opinion. I'm
> >> thinking that VMS clusters will not be an issue for many VMS users.
> >
> > Does "many" mean more than half? Even if more than half of the users,
> > perhaps not more than half of the machines.
>
> Half??
>
> I would be surprised if it was >5%.

Probably all of use are familiar with some part of the VMS market and
none of us has an overview.

Phillip Helbig (undress to reply)

unread,
Sep 14, 2021, 12:41:04 AM9/14/21
to
In article <shopgc$b49$3...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<ar...@vajhoej.dk> writes:

> On 9/13/2021 8:01 PM, chris wrote:
> > On 09/13/21 18:24, Scott Dorsey wrote:
> >> Bill Gunshannon<bill.gu...@gmail.com>  wrote:
> >>> Any browser requires a desktop.  I thought that idea had been abandoned?
> >>
> >> No it doesn't, that is the beauty of DECWindows.  Mind you, there's
> >> really
> >> no reason to have a browser on a machine without a desktop, other than
> >> for diagnostic purposes and downloads.  But it's not required, and it is
> >> occasionally handy.
> >>
> >> Does "occasionally handy" warrant an enormous effort to port a modern
> >> browser
> >> to VMS?  I don't think so.  But if someone here wants to give it a
> >> try, have
> >> at it.  That's the beauty of open source.
> >
> > A lot of system management is done via browsers, for years now. Also,
> > for software dev, nothing beats a windowing system with multiple
> > terminal windows and tabbed full screen editors. I used to be pretty
> > deft with edt on a vt terminal but those days are gone forever. All the
> > ilom i've worked with works far better using a browser for access. A
> > sort of universal access method for systems. So yes, lack of a browser
> > might be seen as a serious disadvantage.
>
> Web interfaces are very common for admin stuff today.
>
> But usually running the browser on a PC will work fine.

Right. But if one downloads and uploads files from VMS, then a browser
on VMS allows one to avoid going through a third system.

Jan-Erik Söderholm

unread,
Sep 14, 2021, 2:34:07 AM9/14/21
to
I'd say that the browser is *never* run on the system that is managed.

Arne Vajhøj

unread,
Sep 14, 2021, 8:16:05 AM9/14/21
to
Most VMS systems runs something important and do not have
access to download directly from the internet.

Arne

Arne Vajhøj

unread,
Sep 14, 2021, 8:20:02 AM9/14/21
to
On 9/14/2021 12:39 AM, Phillip Helbig (undress to reply) wrote:
> In article <shopcl$b49$2...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
> <ar...@vajhoej.dk> writes:
>
>> On 9/13/2021 4:29 PM, Phillip Helbig (undress to reply) wrote:
>>> In article <sho5ts$lt3$1...@dont-email.me>, Dave Froble
>>> <da...@tsoft-inc.com> writes:
>>>> Yes, there are multiple reasons to run a VMS cluster. But compute
>>>> resources for the most part is no longer one of those reasons.
>>>
>>> There are certainly many big VMS customers who run clusters partly for
>>> increased computing power. Of course, disaster tolerance, rolling
>>> upgrades, and so on are also reasons.
>>
>> 30 years ago: certainly.
>>
>> Today: not so sure.
>>
>> A single Itanium got lots of power.
>
> Sure, but what are big VMS customers doing today?

Most likely running the same applications they did 30 years ago.

>> Disaster tolerance can be achieved in different ways.
>
> But none as good as a VMS cluster.

Businesses are interested in application availability. They
do not care whether that is provided by OS features or
application features.

>>>> I have no information to know what the breakdown is among VMS cluster
>>>> users. But, I'll pull an Arne and state my factless opinion. I'm
>>>> thinking that VMS clusters will not be an issue for many VMS users.
>>>
>>> Does "many" mean more than half? Even if more than half of the users,
>>> perhaps not more than half of the machines.
>>
>> Half??
>>
>> I would be surprised if it was >5%.
>
> Probably all of use are familiar with some part of the VMS market and
> none of us has an overview.

True.

But cluster pricing/setup/monitoring/programming questions
appears rather rare both here and other places.

Arne


chris

unread,
Sep 14, 2021, 8:25:33 AM9/14/21
to
A lot of excuses why a browser should not be included. It's a
standard tool that everyone takes for granted these days and is
universal in terms of cross platform operation and compatibility

just one more thing that would help drag vms into the modern age..

Chris





Arne Vajhøj

unread,
Sep 14, 2021, 8:39:27 AM9/14/21
to
On 9/14/2021 8:25 AM, chris wrote:
> On 09/14/21 13:16, Arne Vajhøj wrote:
>> On 9/14/2021 12:41 AM, Phillip Helbig (undress to reply) wrote:
>>> In article <shopgc$b49$3...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>>> <ar...@vajhoej.dk> writes:
>>>> On 9/13/2021 8:01 PM, chris wrote:
>>>>> A lot of system management is done via browsers, for years now. Also,
>>>>> for software dev, nothing beats a windowing system with multiple
>>>>> terminal windows and tabbed full screen editors. I used to be pretty
>>>>> deft with edt on a vt terminal but those days are gone forever. All
>>>>> the
>>>>> ilom i've worked with works far better using a browser for access. A
>>>>> sort of universal access method for systems. So yes, lack of a browser
>>>>> might be seen as a serious disadvantage.
>>>>
>>>> Web interfaces are very common for admin stuff today.
>>>>
>>>> But usually running the browser on a PC will work fine.
>>>
>>> Right. But if one downloads and uploads files from VMS, then a browser
>>> on VMS allows one to avoid going through a third system.
>>
>> Most VMS systems runs something important and do not have
>> access to download directly from the internet.
>
> A lot of excuses why a browser should not be included. It's a
> standard tool that everyone takes for granted these days and is
> universal in terms of cross platform operation and compatibility
>
> just one more thing that would help drag vms into the modern age..

Every desktop OS or tablet OS or phone OS comes with a browser.

But servers today are mostly headless. They reside in
a server room or at a hosting facility or at a cloud provider.
They can be accessed via ssh or browser or some dedicated
fat client GUI. Sure some of them may have a browser installed
and there are some ways to run browser on them and get
the display on a PC, but in those cases there already are
a PC involved that already has a browser.

Arne

Jan-Erik Söderholm

unread,
Sep 14, 2021, 8:53:40 AM9/14/21
to
No, a web *browser* on VMS would do nothing positive for VMS.
It is simply neither asked for or needed.
Browsers are run on desktop environments.

David Jones

unread,
Sep 14, 2021, 9:38:06 AM9/14/21
to
On Tuesday, September 14, 2021 at 8:53:40 AM UTC-4, Jan-Erik Söderholm wrote:
> No, a web *browser* on VMS would do nothing positive for VMS.
> It is simply neither asked for or needed.
> Browsers are run on desktop environments.

A GUI browser isn't necessary, but a current curl using up-to-date TLS and root
certificate list is pretty useful for download scripts.

Arne Vajhøj

unread,
Sep 14, 2021, 9:59:44 AM9/14/21
to
Direct download from the internet to VMS may not be wise or common.

But uptodate openssl and curl libraries are very important also
for internal integrations. If a VMS system is going to consume
services at a Linux system, then HTTPS is likely the protocol
required.

Arne


Bill Gunshannon

unread,
Sep 14, 2021, 10:05:03 AM9/14/21
to
I doubt that is true, but maybe. And then you have so many calling
for VMS to find a way back into academia. Without a real desktop and
a decent browser that is never going to happen (not that it is likely
to happen anyway). The user community you will find in academia today
is not going to want to work with a CLI or vt-class editors.

bill


Bill Gunshannon

unread,
Sep 14, 2021, 10:08:08 AM9/14/21
to
And very efficient I/O.

bill


Arne Vajhøj

unread,
Sep 14, 2021, 10:17:17 AM9/14/21
to
EDT/EVE will probaly not cut it today.

But VS Code should be fine.

And they can use that (VMS IDE).

I don't think the students will have a problem with ssh and
a bit of command line work.

That is common other platforms as well.

Windows (Core) and PowerShell.

Linux various shells.

The entire container world is very much command lines
and json or yaml config files.

The data guys mess around with files and Python scripts as well.

I am obviously not talking about any student. But let us say those
in a relevant field (computer science , software engineering etc.),
among the 25% most curious and among the 50% most skilled.

The same type of people that 35 years ago learned Macro-32.

Arne




Arne Vajhøj

unread,
Sep 14, 2021, 10:19:13 AM9/14/21
to
Very efficient network IO.

The web services should be all in memory with practically
no disk IO.

Disk IO becomes relevant back at the data/persistence/storage
tier.

Arne


chris

unread,
Sep 14, 2021, 11:12:37 AM9/14/21
to
Sorry, but that requires another machine and makes the assumption
that vms will never be asked to access and manage other systems,
typically using a browser. If it's going to cut it in the 20B0's,
it needs as much capability and range to tools as possible.
Being set against provision of a browser is just the sort of
dinosaur thinking that has cast vms into a minority interest for
decades. It may have been brilliant decades ago, but is totally
outclassed these days, and will need real effort to make any
headway at all without most of the capability of it's competitors.

An inconvenient truth ?, yes, but true none the less...

Chris

chris

unread,
Sep 14, 2021, 11:16:29 AM9/14/21
to
Perhaps not for or by you, but others may b=have a different view and
vms stopped being in any way exclusive decades ago...

Chris



chris

unread,
Sep 14, 2021, 11:26:58 AM9/14/21
to
I'm still using makefiles for all my code, but quite have
three or four terminal / shell windows, file mgr and one or two
tabbed full screen editor windows open typically. Still
coommand line, but the gui provides so much more flexibility
and can't imagein going back to edt and vt class terminels,
far too restrictive.

One thing that might be useful for vms would be a vnc server
to allow remote access. use that a lot here for headless
machines and is more than fast enough with modern processors...

Chris

Arne Vajhøj

unread,
Sep 14, 2021, 11:45:11 AM9/14/21
to
On 9/14/2021 11:26 AM, chris wrote:
> On 09/14/21 15:17, Arne Vajhøj wrote:
>> On 9/14/2021 10:04 AM, Bill Gunshannon wrote:
>>> I doubt that is true, but maybe.  And then you have so  many calling
>>> for VMS to find a way back into academia.  Without a real desktop and
>>> a decent browser that is never going to happen (not that it is likely
>>> to happen anyway).  The user community you will find  in academia today
>>> is not going to want to work with a CLI or vt-class editors.
>>
>> EDT/EVE will probaly not cut it today.
>>
>> But VS Code should be fine.
>>
>> And they can use that (VMS IDE).
>>
>> I don't think the students will have a problem with ssh and
>> a bit of command line work.
>>
>> That is common other platforms as well.

> I'm still using makefiles for all my code, but quite have
> three or four terminal / shell windows, file mgr and one or two
> tabbed full screen editor windows open typically. Still
> coommand line, but the gui provides so much more flexibility
> and can't imagein going back to edt and vt class terminels,
> far too restrictive.

A mix of GUI and command line is common.

I do that on Windows and Linux as well.

Mostly JEdit (I do not like VS Code) and command windows.

> One thing that might be useful for vms would be a vnc server
> to allow remote access. use that a lot here for headless
> machines and is more than fast enough with modern processors...

Interesting thought.

I assume you want GUI not CLI. CLI should be fine with SSH.

As I remember VNC (been some years) then it duplicates
the GUI.

Many VMS systems will not have a graphic capable console, so
nothing to duplicate.

But it does not really need to duplicate. Being original
GUI would be fine.

A pseudo device connected to the "VNC like server"
exposing a GUI to the client could work.

I know that it is possible to tunnel X over SSH,
but I believe that is a complicated exercise in
todays network.

Start a "VNC like client" and getting a DECWindows
console could be cool.

I do do still not see the point in running a browser there.

But file manager or a GUI editor.

Not sure how much effort to make DECWindows use a pseudo
device connected to a TCP server, but it may
not be so bad.

Arne




chris

unread,
Sep 14, 2021, 1:09:00 PM9/14/21
to
The original vnc was quite slow on the machines of the 1990's,
but orders of magnitude faster processors and networks now make
it very usable and in some tests here, was subjectively just as
fast as an on board low end frame buffers such as the Radeon 2200
or 2250. Doing some work on FreeBSD Sparc a couple of years back,
almost none existent frame buffer support, so looked again at vnc.

The original Xvnc had a built in X server, which means it doesn't
need an X install on the system to run. Some later versions do, but
I chose Xvnc to get round some package issues and it runs very
well. Got as far as an xfce4 desktop and utilities, but failed at
the time with the Firefox build, too many package dependencies and
version number requirements.

In a way, vms deficiencies are similar to the FreeBSD Sparc
issues I found, but can't believe it would be that difficult to
get a vnc server running, which would make it far more useful.
One alternative is the microsoft rdp, but would shudder at that
idea.

In the modern world, comms and methods of access across the network
are key requirements, so vms will need a good chunk of that to be
taken seriously. As for decwindows, that was an X system, so must
have had all the low level X networking suport built in for remote
application display. Yes, other than for tcp/ip support, vms was
quite up to date even 30 years ago...

Chris


>
>

Simon Clubley

unread,
Sep 14, 2021, 1:51:19 PM9/14/21
to
On 2021-09-14, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>
> I know that it is possible to tunnel X over SSH,
> but I believe that is a complicated exercise in
> todays network.
>

Why ?

You login to the server over SSH with the appropriate command line option,
you run the X11 application on the server from the command line, and the
X11 output gets sent over the SSH connection back to your local X11 display.

Has something changed very recently that means this is no longer viable ?

Simon.

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

Dave Froble

unread,
Sep 14, 2021, 3:18:44 PM9/14/21
to
On 9/14/2021 12:41 AM, Phillip Helbig (undress to reply) wrote:
Most of us don't seem to have a major problem pulling data now and then,
then moving it to VMS.

Now, if you're doing a lot, then using manual procedures really isn't
the best practice. It is not too hard to set up procedures on VMS to go
out and pull data without manual intervention.

Not a problem, if one approaches the needs with an open mind.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Dave Froble

unread,
Sep 14, 2021, 3:21:35 PM9/14/21
to
Well, if we're talking a "desktop system", perhaps that is not doing all
those "important" somethings.

If such exists, then it could be used for such communication tasks.

A browser is not needed for communications ....

Dave Froble

unread,
Sep 14, 2021, 3:25:58 PM9/14/21
to
Desktop? No freaking way that RX2660 in the basement is getting
anywhere near my desk. Loud doesn't even begin to describe it.

:-)

Dave Froble

unread,
Sep 14, 2021, 3:28:33 PM9/14/21
to
Maybe not for some, but here VMS is exclusive, required, and appreciated.

Arne Vajhøj

unread,
Sep 14, 2021, 3:45:31 PM9/14/21
to
On 9/14/2021 3:23 PM, Dave Froble wrote:
> On 9/14/2021 8:53 AM, Jan-Erik Söderholm wrote:
>> Den 2021-09-14 kl. 14:25, skrev chris:
>>> A lot of excuses why a browser should not be included. It's a
>>> standard tool that everyone takes for granted these days and is
>>> universal in terms of cross platform operation and compatibility
>>>
>>> just one more thing that would help drag vms into the modern age..
>>
>> No, a web *browser* on VMS would do nothing positive for VMS.
>> It is simply neither asked for or needed.
>> Browsers are run on desktop environments.
>
> Desktop?  No freaking way that RX2660 in the basement is getting
> anywhere near my desk.  Loud doesn't even begin to describe it.

The owners of VMS has not produced desktop systems able to
run VMS for about 2 decades (I believe last AlphaStation was
from around 2000/2001).

Of course that will change soon. When VMS x86-64 becomes
production ready, then any desktop or laptop (there are a
few requirements but ...) should be able to run VMS.

But don't expect VSI to spend money on supporting that config.

And I suspect that almost all needing VMS for development
professionally will run Windows/Linux/macOS and a VM with
VMS. Just more convenient.

Arne





Dave Froble

unread,
Sep 14, 2021, 3:49:55 PM9/14/21
to
On 9/13/2021 8:09 PM, Arne Vajhøj wrote:
> On 9/13/2021 4:57 PM, Scott Dorsey wrote:
>> Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de>
>> wrote:
>>> In article <sho5ts$lt3$1...@dont-email.me>, Dave Froble
>>> <da...@tsoft-inc.com> writes:
>>>
>>>> Yes, there are multiple reasons to run a VMS cluster. But compute
>>>> resources for the most part is no longer one of those reasons.
>>>
>>> There are certainly many big VMS customers who run clusters partly for
>>> increased computing power. Of course, disaster tolerance, rolling
>>> upgrades, and so on are also reasons.
>>
>> In the case of web services, clusters get you improved reliability, more
>> CPU, but most importantly more I/O. The thing is, few people are using
>> VMS for web services, and that's a shame because it's something where it
>> could do well.
>
> I find that hard to see.
>
> Web services need:
> * low cost HW

I find this to be a double standard. People talk about the high cost of
Alpha, and VMS HW in general.

I was doing some looking at multicore CPUs. Ran across a 56 core Intel
chip with a price tag of around $12,000. That ain't low cost HW.

Intel server CPUs are not low cost.

Just saying ...

> * low cost OS & web SW
> * uptodate web SW
>
> Arne

Dave Froble

unread,
Sep 14, 2021, 3:52:59 PM9/14/21
to
On 9/13/2021 8:12 PM, Arne Vajhøj wrote:
> On 9/13/2021 4:29 PM, Phillip Helbig (undress to reply) wrote:
>> In article <sho5ts$lt3$1...@dont-email.me>, Dave Froble
>> <da...@tsoft-inc.com> writes:
>>> Yes, there are multiple reasons to run a VMS cluster. But compute
>>> resources for the most part is no longer one of those reasons.
>>
>> There are certainly many big VMS customers who run clusters partly for
>> increased computing power. Of course, disaster tolerance, rolling
>> upgrades, and so on are also reasons.
>
> 30 years ago: certainly.
>
> Today: not so sure.
>
> A single Itanium got lots of power.
>
> Disaster tolerance can be achieved in different ways.
>
>>> I have no information to know what the breakdown is among VMS cluster
>>> users. But, I'll pull an Arne and state my factless opinion. I'm
>>> thinking that VMS clusters will not be an issue for many VMS users.
>>
>> Does "many" mean more than half? Even if more than half of the users,
>> perhaps not more than half of the machines.
>
> Half??
>
> I would be surprised if it was >5%.

More factless opinion ???????????????

We don't really have a clue, do we?

But even if it is a low percentage, if a capability is needed, then it's
needed, and very important to those in need.

Dave Froble

unread,
Sep 14, 2021, 3:59:36 PM9/14/21
to
On 9/14/2021 8:19 AM, Arne Vajhøj wrote:
> On 9/14/2021 12:39 AM, Phillip Helbig (undress to reply) wrote:
>> In article <shopcl$b49$2...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>> <ar...@vajhoej.dk> writes:
>>
>>> On 9/13/2021 4:29 PM, Phillip Helbig (undress to reply) wrote:
>>>> In article <sho5ts$lt3$1...@dont-email.me>, Dave Froble
>>>> <da...@tsoft-inc.com> writes:
>>>>> Yes, there are multiple reasons to run a VMS cluster. But compute
>>>>> resources for the most part is no longer one of those reasons.
>>>>
>>>> There are certainly many big VMS customers who run clusters partly for
>>>> increased computing power. Of course, disaster tolerance, rolling
>>>> upgrades, and so on are also reasons.
>>>
>>> 30 years ago: certainly.
>>>
>>> Today: not so sure.
>>>
>>> A single Itanium got lots of power.
>>
>> Sure, but what are big VMS customers doing today?
>
> Most likely running the same applications they did 30 years ago.

If someone has been running an application for 30 years, then it is
probably very important to them.

>>> Disaster tolerance can be achieved in different ways.
>>
>> But none as good as a VMS cluster.
>
> Businesses are interested in application availability. They
> do not care whether that is provided by OS features or
> application features.

Businesses, by and large, are not capable of evaluating such features.
Sure, there are better and poorer methods, and some may have chosen
poorer. But that in no way changes what is better, or not.

>>>>> I have no information to know what the breakdown is among VMS cluster
>>>>> users. But, I'll pull an Arne and state my factless opinion. I'm
>>>>> thinking that VMS clusters will not be an issue for many VMS users.
>>>>
>>>> Does "many" mean more than half? Even if more than half of the users,
>>>> perhaps not more than half of the machines.
>>>
>>> Half??
>>>
>>> I would be surprised if it was >5%.
>>
>> Probably all of use are familiar with some part of the VMS market and
>> none of us has an overview.
>
> True.
>
> But cluster pricing/setup/monitoring/programming questions
> appears rather rare both here and other places.

Most likely users of VMS clusters have more knowledge than they could
find here.

Cluster pricing and marketing has been a great failing of DEC, Compaq,
HP, and we await to discover how VSI will do so.

Arne Vajhøj

unread,
Sep 14, 2021, 4:01:21 PM9/14/21
to
Xeon CPU's vary a lot in price.

The super high end and those ready for multi-socket tend to be a
bit pricey.

But you can get a low end model like 12 core pretty cheap.

In a year or two then 24 core will be cheap as well.

Arne

Arne Vajhøj

unread,
Sep 14, 2021, 4:34:39 PM9/14/21
to
On 9/14/2021 3:50 PM, Dave Froble wrote:
> On 9/13/2021 8:12 PM, Arne Vajhøj wrote:
>> On 9/13/2021 4:29 PM, Phillip Helbig (undress to reply) wrote:
>>> In article <sho5ts$lt3$1...@dont-email.me>, Dave Froble
>>> <da...@tsoft-inc.com> writes:
>>>> I have no information to know what the breakdown is among VMS cluster
>>>> users.  But, I'll pull an Arne and state my factless opinion.  I'm
>>>> thinking that VMS clusters will not be an issue for many VMS users.
>>>
>>> Does "many" mean more than half?  Even if more than half of the users,
>>> perhaps not more than half of the machines.
>>
>> Half??
>>
>> I would be surprised if it was >5%.
>
> More factless opinion ???????????????
>
> We don't really have a clue, do we?

How many questions do you see related to VMS clustering
here, at VSI forum and at SO?

How many VMS clusters do you know about?

They seem pretty rare today.

As opposed to 80's and 90's where a lot ran VMS clusters.
VAX 700 series cluster, VAX 6000 series clusters, MicroVAX & VAXStation
clusters, Alpha 3000 series clusters, mixed VAX and Alpha,
you name it.

> But even if it is a low percentage, if a capability is needed, then it's
> needed, and very important to those in need.

Yes.

Anyone running a VMS cluster in 2021 most likely have a very good
reason to do so.

There must be some running Rdb in cluster.

Arne

Scott Dorsey

unread,
Sep 14, 2021, 4:36:01 PM9/14/21
to
chris <chris-...@tridac.net> wrote:
>A lot of system management is done via browsers, for years now. Also,
>for software dev, nothing beats a windowing system with multiple
>terminal windows and tabbed full screen editors. I used to be pretty
>deft with edt on a vt terminal but those days are gone forever. All the
>ilom i've worked with works far better using a browser for access. A
>sort of universal access method for systems. So yes, lack of a browser
>might be seen as a serious disadvantage.

Right, but who sits in front of a server these days anyway? You sit in
front of a workstation, maybe one halfway across the country from the
server, and that workstation is running a browser. What you need on the
server isn't a browser, but a webserver, and tools to allow remote
administration via web.

>As for built in frame buffer support, they are often very low end
>hardware devices and none i've seen have been good or fast enough
>for X windows use. Important to know what's being promised in that
>respect...

These days, most cheap video cards in VGA mode are enough for basic
X11 use. It would not be difficult to get a basic DECWindows server
working under x86 VMS. What would be difficult is getting all the other
millions of applications that people want. Even so, it's probably not
worth the effort for something that so few people will ever want to use.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Scott Dorsey

unread,
Sep 14, 2021, 4:38:55 PM9/14/21
to
=?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
>> In the case of web services, clusters get you improved reliability, more
>> CPU, but most importantly more I/O. The thing is, few people are using
>> VMS for web services, and that's a shame because it's something where it
>> could do well.
>
>I find that hard to see.
>
>Web services need:
>* low cost HW
>* low cost OS & web SW
>* uptodate web SW

I agree strongly about that last one, but I am not so sure about the first
two. I think that there is still a market for high end web server hardware
and software, but only if the performance warrants it. If you can do ten
times the transaction rate of a machine that costs a tenth of your machines
cost, you still have a win.

Still, I think the move to x86 hardware is a step in the right direction
both in terms of performance and cost.

Arne Vajhøj

unread,
Sep 14, 2021, 4:41:42 PM9/14/21
to
On 9/14/2021 3:57 PM, Dave Froble wrote:
> On 9/14/2021 8:19 AM, Arne Vajhøj wrote:
>> On 9/14/2021 12:39 AM, Phillip Helbig (undress to reply) wrote:
>>> In article <shopcl$b49$2...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>>> <ar...@vajhoej.dk> writes:
>>>> A single Itanium got lots of power.
>>>
>>> Sure, but what are big VMS customers doing today?
>>
>> Most likely running the same applications they did 30 years ago.
>
> If someone has been running an application for 30 years, then it is
> probably very important to them.

Yes.

My point was that even though the company may have doubled or tripled
customers and they may have doubled or tripled historic data, then one
new system that are several orders of magnitudes faster can most likely
do what required a cluster many years ago.

>>>> Half??
>>>>
>>>> I would be surprised if it was >5%.
>>>
>>> Probably all of use are familiar with some part of the VMS market and
>>> none of us has an overview.
>>
>> True.
>>
>> But cluster pricing/setup/monitoring/programming questions
>> appears rather rare both here and other places.
>
> Most likely users of VMS clusters have more knowledge than they could
> find here.

I don't see why they should be asking fewer questions than non-cluster
users.

> Cluster pricing and marketing has been a great failing of DEC, Compaq,
> HP, and we await to discover how VSI will do so.

I suspect that they may price it pretty high.

The general trend in software seems to be that base/standard
becomes very low cost but that the extended/enterprise features
stays rather expensive.

Arne


Arne Vajhøj

unread,
Sep 14, 2021, 4:45:47 PM9/14/21
to
On 9/14/2021 4:38 PM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <ar...@vajhoej.dk> wrote:
>>> In the case of web services, clusters get you improved reliability, more
>>> CPU, but most importantly more I/O. The thing is, few people are using
>>> VMS for web services, and that's a shame because it's something where it
>>> could do well.
>>
>> I find that hard to see.
>>
>> Web services need:
>> * low cost HW
>> * low cost OS & web SW
>> * uptodate web SW
>
> I agree strongly about that last one, but I am not so sure about the first
> two. I think that there is still a market for high end web server hardware
> and software, but only if the performance warrants it. If you can do ten
> times the transaction rate of a machine that costs a tenth of your machines
> cost, you still have a win.

Expensive HW seems to becoming niche in the server market. x86-64 is
taking it all. And the only real threat lurking is ARM.

And regarding OS then a lot of places prefer CentOS/RockyLinux
over RHEL for that type of servers, which to me indicate that
they are very price sensitive.

> Still, I think the move to x86 hardware is a step in the right direction
> both in terms of performance and cost.

Oh yes.

That will be a jump 15 years ahead or so.

Arne


Phillip Helbig (undress to reply)

unread,
Sep 14, 2021, 5:02:43 PM9/14/21
to
In article <shq3q1$15bl$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<ar...@vajhoej.dk> writes:

> >> Web interfaces are very common for admin stuff today.
> >>
> >> But usually running the browser on a PC will work fine.
> >
> > Right. But if one downloads and uploads files from VMS, then a browser
> > on VMS allows one to avoid going through a third system.
>
> Most VMS systems runs something important and do not have
> access to download directly from the internet.

True in some cases. Of course, all systems are important. Downloading
stuff from the internet to a development system makes sense.

Phillip Helbig (undress to reply)

unread,
Sep 14, 2021, 5:04:17 PM9/14/21
to
In article <shq41f$1ca5$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<ar...@vajhoej.dk> writes:

> >>> There are certainly many big VMS customers who run clusters partly for
> >>> increased computing power. Of course, disaster tolerance, rolling
> >>> upgrades, and so on are also reasons.
> >>
> >> 30 years ago: certainly.
> >>
> >> Today: not so sure.
> >>
> >> A single Itanium got lots of power.
> >
> > Sure, but what are big VMS customers doing today?
>
> Most likely running the same applications they did 30 years ago.

Are you sure? Some are running SIMILAR applications, which however have
grown so that orders of magnitude more power is required.

> >> Disaster tolerance can be achieved in different ways.
> >
> > But none as good as a VMS cluster.
>
> Businesses are interested in application availability. They
> do not care whether that is provided by OS features or
> application features.

They should care if they have to hire twice as many people to implement
the non-VMS solution.

Phillip Helbig (undress to reply)

unread,
Sep 14, 2021, 5:05:15 PM9/14/21
to
In article <shq60i$uq2$1...@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com>
writes:

> No, a web *browser* on VMS would do nothing positive for VMS.
> It is simply neither asked for or needed.
> Browsers are run on desktop environments.

But VMS can be a desktop system if you want it to be. Desktop to data
center!

Phillip Helbig (undress to reply)

unread,
Sep 14, 2021, 5:05:51 PM9/14/21
to
In article <shq9sa$djn$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<ar...@vajhoej.dk> writes:

> On 9/14/2021 9:38 AM, David Jones wrote:
> > On Tuesday, September 14, 2021 at 8:53:40 AM UTC-4, Jan-Erik Söderholm wrote:
> >> No, a web *browser* on VMS would do nothing positive for VMS.
> >> It is simply neither asked for or needed.
> >> Browsers are run on desktop environments.
> >
> > A GUI browser isn't necessary, but a current curl using up-to-date TLS and root
> > certificate list is pretty useful for download scripts.
>
> Direct download from the internet to VMS may not be wise or common.

Probably much less of a worry than direct download to Windows.

chris

unread,
Sep 14, 2021, 5:33:55 PM9/14/21
to
On 09/14/21 21:35, Scott Dorsey wrote:
> chris<chris-...@tridac.net> wrote:
>> A lot of system management is done via browsers, for years now. Also,
>> for software dev, nothing beats a windowing system with multiple
>> terminal windows and tabbed full screen editors. I used to be pretty
>> deft with edt on a vt terminal but those days are gone forever. All the
>> ilom i've worked with works far better using a browser for access. A
>> sort of universal access method for systems. So yes, lack of a browser
>> might be seen as a serious disadvantage.
>
> Right, but who sits in front of a server these days anyway? You sit in
> front of a workstation, maybe one halfway across the country from the
> server, and that workstation is running a browser. What you need on the
> server isn't a browser, but a webserver, and tools to allow remote
> administration via web.

Absolutely, but that's only one scenario and many people do development
on server hardware for all kinds of reasons. VMS needs to support
local development, with the tools ready and available to support that.
That includes the use of a browser to lookup some technical point
or another. Do that all the time here and don't want to keep switching
machines to do it.

>
>> As for built in frame buffer support, they are often very low end
>> hardware devices and none i've seen have been good or fast enough
>> for X windows use. Important to know what's being promised in that
>> respect...
>
> These days, most cheap video cards in VGA mode are enough for basic
> X11 use. It would not be difficult to get a basic DECWindows server
> working under x86 VMS. What would be difficult is getting all the other
> millions of applications that people want. Even so, it's probably not
> worth the effort for something that so few people will ever want to use.
> --scott

I don't differentiate between desktop and server class machines,
hardware is the same under the skin. I tend to use server class
machines here for desktop use, as they are more likely to include
multiple network interfaces, ecc memory, better system management
capability and built in raid controllers. Also, they have common
physical outline designed to fit in a rack, which saves space.
Again, same hardware under skin though and a far cry from the days
of 8600 and ilk vax machines of old compared to desktop
workstations of the time, where the server / desktop naming really
meant something. I would not try to use the average desktop machine
for server duty, as they lack most of the capability of server class
hardware, The difference isn't so much hardware quality, but what's
added to make it really useful for the task.

As for the video cards on some modern servers, what I find is that they
have limited performance and there are no drivers available to run X
anyway. Strictly vga console duty use only. Forget running X on them,
without writing appropriate drivers. Hence suggestion of using vnc
for remote access, or perhaps even a built in web server. As I said,
understand what you are being promised and the limitations of hardware.

Chris

Arne Vajhøj

unread,
Sep 14, 2021, 6:14:17 PM9/14/21
to
No.

Risk wise Windows may be more targeted but it should also be more
uptodate patch wise.

The big difference is the impact. The Windows desktop PC should not
be critical for the business and there should be firewalls
behind it and systems that are critiocal for the business. The VMS
system most likely ruins something critical for the business.

Arne


Arne Vajhøj

unread,
Sep 14, 2021, 6:24:39 PM9/14/21
to
On 9/14/2021 5:04 PM, Phillip Helbig (undress to reply) wrote:
> In article <shq41f$1ca5$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
> <ar...@vajhoej.dk> writes:
>>>>> There are certainly many big VMS customers who run clusters partly for
>>>>> increased computing power. Of course, disaster tolerance, rolling
>>>>> upgrades, and so on are also reasons.
>>>>
>>>> 30 years ago: certainly.
>>>>
>>>> Today: not so sure.
>>>>
>>>> A single Itanium got lots of power.
>>>
>>> Sure, but what are big VMS customers doing today?
>>
>> Most likely running the same applications they did 30 years ago.
>
> Are you sure? Some are running SIMILAR applications, which however have
> grown so that orders of magnitude more power is required.

The investment in VMS applications seems to have been relative
low for the last couple of decades.

The large new features seems to have been implemented outside
of VMS most places.

The VMS applications has been maintained and enhanced as business
requirements has evolved.

But way more +5% code projects than x5 code projects.

>>>> Disaster tolerance can be achieved in different ways.
>>>
>>> But none as good as a VMS cluster.
>>
>> Businesses are interested in application availability. They
>> do not care whether that is provided by OS features or
>> application features.
>
> They should care if they have to hire twice as many people to implement
> the non-VMS solution.

But why should they need to hitre more people??

Let us take Rdb vs Oracle DB aka Classic with RAC (real RAC
not RAC One). Both use a DLM but Rdb use VMS DLM while Oracle DB
RAC use its own DLM.

Does it matter for developers or operations? Not really.

Arne



kemain...@gmail.com

unread,
Sep 14, 2021, 7:30:06 PM9/14/21
to comp.os.vms to email gateway
While service availability is what concerns end users and/or the business
types, in today's typical world, requiring every application developer to
understand all of the nuances of availability, multi-site site clustering,
add/removal of servers, data partitioning, data integrity is a massive
amount of inefficiencies.

As an example, read this article about what App developers need to be
concerned about when they are in charge of addressing HA, data integrity,
workload distribution and using typical shared nothing OS strategies:
<http://highscalability.com/blog/2015/10/12/making-the-case-for-building-sca
lable-stateful-services-in-t.html>

Imho, App developers should be focussed on optimizing their applications to
meet business functionality requirements (there are typically large queues
of new functionality requests) and let the other concerns be handled at the
DB and OS / network layers.

In terms of server clustering, there is only 2 cluster types - shared disk
and shared nothing. Depending on Application designs, there are pro's and
con's with each strategy. The typical OpenVMS cluster is an example of a
shared disk cluster strategy.

Reference:
<http://www.benstopford.com/2009/11/24/understanding-the-shared-nothing-arch
itecture/>
"Shared Disk Architectures are write-limited where multiple writer nodes
must coordinate their locks around the cluster. Shared Nothing Architectures
are write limited where writes span multiple partitions necessitating a
distributed two-phase commit."


Regards,

Kerry Main
Kerry dot main at starkgaming dot com





--
This email has been checked for viruses by AVG.
https://www.avg.com


David Goodwin

unread,
Sep 14, 2021, 7:52:58 PM9/14/21
to
On Wednesday, September 15, 2021 at 3:12:37 AM UTC+12, chris wrote:
> On 09/14/21 13:39, Arne Vajhøj wrote:
> > On 9/14/2021 8:25 AM, chris wrote:
>
> >> A lot of excuses why a browser should not be included. It's a
> >> standard tool that everyone takes for granted these days and is
> >> universal in terms of cross platform operation and compatibility
> >>
> >> just one more thing that would help drag vms into the modern age..
> >
> > Every desktop OS or tablet OS or phone OS comes with a browser.
> >
> > But servers today are mostly headless. They reside in
> > a server room or at a hosting facility or at a cloud provider.
> > They can be accessed via ssh or browser or some dedicated
> > fat client GUI. Sure some of them may have a browser installed
> > and there are some ways to run browser on them and get
> > the display on a PC, but in those cases there already are
> > a PC involved that already has a browser.
> >
> > Arne
> Sorry, but that requires another machine and makes the assumption
> that vms will never be asked to access and manage other systems,
> typically using a browser. If it's going to cut it in the 20B0's,
> it needs as much capability and range to tools as possible.
> Being set against provision of a browser is just the sort of
> dinosaur thinking that has cast vms into a minority interest for
> decades. It may have been brilliant decades ago, but is totally
> outclassed these days, and will need real effort to make any
> headway at all without most of the capability of it's competitors.
>
> An inconvenient truth ?, yes, but true none the less...

You know whats really an inconvenient truth? Its probably impossible
for a proprietary operating system to compete with Linux in the long term
regardless of whether it has a web browser.

Because realistically what can VMS do that isn't cheaper and easier
on Linux besides "run existing VMS applications"? Why pay for VMS to
run ports of Linux software when you could just run Linux software on
its native platform for free?

Even Windows Server is struggling here for the same reason. Most stuff
targets Linux now so Microsoft runs more Linux virtual machines in Azure
than Windows and has for some years now. We're at the point where
Microsoft has added Linux binary compatibility to Windows because
thats what most development tools are built for now.

It *might* be possible to co-exist long-term with Linux as an open-source
operating system. The *BSDs seem to be doing OK. And Solaris lives on
in the form of Illumos (a fork of OpenSolaris). Maybe this path would
work for OpenVMS too.

Arne Vajhøj

unread,
Sep 14, 2021, 8:24:18 PM9/14/21
to
On 9/14/2021 7:52 PM, David Goodwin wrote:
> Because realistically what can VMS do that isn't cheaper and easier
> on Linux besides "run existing VMS applications"? Why pay for VMS to
> run ports of Linux software when you could just run Linux software on
> its native platform for free?

There is no license cost for Linux, but companies
pay for support. Using RHEL is not free.

So there is be room for charging.

But long term RHEL can probably be seen as a cap for what
can be charged.

> Even Windows Server is struggling here for the same reason. Most stuff
> targets Linux now so Microsoft runs more Linux virtual machines in Azure
> than Windows and has for some years now.

Yep.

> We're at the point where
> Microsoft has added Linux binary compatibility to Windows because
> thats what most development tools are built for now.

WSL 1 was a compatibility layer, but WSL 2 is a VM actually running
Linux. And it is for developing Linux software on Windows.

Arne

David Goodwin

unread,
Sep 14, 2021, 10:08:38 PM9/14/21
to
On Wednesday, September 15, 2021 at 12:24:18 PM UTC+12, Arne Vajhøj wrote:
> On 9/14/2021 7:52 PM, David Goodwin wrote:
> > Because realistically what can VMS do that isn't cheaper and easier
> > on Linux besides "run existing VMS applications"? Why pay for VMS to
> > run ports of Linux software when you could just run Linux software on
> > its native platform for free?
> There is no license cost for Linux, but companies
> pay for support. Using RHEL is not free.
>
> So there is be room for charging.
>
> But long term RHEL can probably be seen as a cap for what
> can be charged.

Any idea what RHEL actually costs compared to OpenVMS? I've really
got no idea. RedHat must make a fair bit of money though given what IBM
spent buying them in 2019 ($34bn). Thats more than twice what Compaq
spent buying all of DEC ($15bn in 2019 money).

> > Even Windows Server is struggling here for the same reason. Most stuff
> > targets Linux now so Microsoft runs more Linux virtual machines in Azure
> > than Windows and has for some years now.
> Yep.
> > We're at the point where
> > Microsoft has added Linux binary compatibility to Windows because
> > thats what most development tools are built for now.
> WSL 1 was a compatibility layer, but WSL 2 is a VM actually running
> Linux. And it is for developing Linux software on Windows.

Yeah, WSL is pretty much a case of better people use Windows to develop
Linux server apps then leave Windows altogether. Interestingly WSL2 is
getting proper support for graphical Linux apps in Windows 11 IIRC - some
sort of wayland-RDP bridge. I think I read that support for Android apps is
coming too thought that may not be relying on WSL. On the server Microsoft
just expects people will run real Linux and ideally pay them to host it.

What surprised me though is in Azure Microsoft doesn't seem to try and push
you towards Windows at all. Linux is cheaper than Windows and in some cases
the only option (no hosting python apps on a windows app service).

Arne Vajhøj

unread,
Sep 14, 2021, 10:24:06 PM9/14/21
to
On 9/14/2021 10:08 PM, David Goodwin wrote:
> On Wednesday, September 15, 2021 at 12:24:18 PM UTC+12, Arne Vajhøj wrote:
>> On 9/14/2021 7:52 PM, David Goodwin wrote:
>>> Because realistically what can VMS do that isn't cheaper and easier
>>> on Linux besides "run existing VMS applications"? Why pay for VMS to
>>> run ports of Linux software when you could just run Linux software on
>>> its native platform for free?
>> There is no license cost for Linux, but companies
>> pay for support. Using RHEL is not free.
>>
>> So there is be room for charging.
>>
>> But long term RHEL can probably be seen as a cap for what
>> can be charged.
>
> Any idea what RHEL actually costs compared to OpenVMS? I've really
> got no idea. RedHat must make a fair bit of money though given what IBM
> spent buying them in 2019 ($34bn). Thats more than twice what Compaq
> spent buying all of DEC ($15bn in 2019 money).

Not that much per system.

https://www.redhat.com/en/store/linux-platforms

But some customers got a lot of systems.

Arne

David Goodwin

unread,
Sep 14, 2021, 10:55:14 PM9/14/21
to
I suppose an interesting point is that companies _choose_ to pay RedHat,
Canonical, SuSE, etc. There is no threat of having their servers turned off
if they decide to stop paying a subscription fee or RedHat goes out of
business. There is always the option of paying nothing and running a Linux
distribution with no commercial support.

If there were a fully functional version of OpenVMS that was free for
commercial use would enough companies continue to pay VSI for support
to keep the whole thing viable? Or is RedHats business model only viable
due to the sheer size of the Linux market?

Dave Froble

unread,
Sep 14, 2021, 11:13:07 PM9/14/21
to
On 9/14/2021 10:55 PM, David Goodwin wrote:

> I suppose an interesting point is that companies _choose_ to pay RedHat,

If you were running a business that absolutely needed the computer
systems, and you'd lose the business if they didn't, would you choose to
run without support?

It's like insurance, and plenty of businesses pay for insurance, of
various kinds.

Phillip Helbig (undress to reply)

unread,
Sep 15, 2021, 1:00:21 AM9/15/21
to
In article <shr7f4$tnu$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<ar...@vajhoej.dk> writes:

> >> Businesses are interested in application availability. They
> >> do not care whether that is provided by OS features or
> >> application features.
> >
> > They should care if they have to hire twice as many people to implement
> > the non-VMS solution.
>
> But why should they need to hire more people??
>
> Let us take Rdb vs Oracle DB aka Classic with RAC (real RAC
> not RAC One). Both use a DLM but Rdb use VMS DLM while Oracle DB
> RAC use its own DLM.
>
> Does it matter for developers or operations? Not really.

Have you ever worked anywhere where one tried to emulate the
functionality of VMS with regard to clustering, availability, and so on
with non-VMS hardware and software?

Joukj

unread,
Sep 15, 2021, 2:36:31 AM9/15/21
to
Arne Vajhøj wrote:

> I know that it is possible to tunnel X over SSH,
> but I believe that is a complicated exercise in
> todays network.

Complicated? I always use this. when communicating with my Linux and
OpenVMS systems (even from home, since it easy in our university to set
IP-port 22 open in the firewall).It just involves switching it on on the
server (if it is not already on and adding one option on the ssh command.

Maybe it is complicated on windows because of the lack of native
X11-support.

John Dallman

unread,
Sep 15, 2021, 4:16:59 AM9/15/21
to
In article <shr1le$ano$2...@gioia.aioe.org>, ar...@vajhoej.dk (Arne Vajhøj)
wrote:

> And regarding OS then a lot of places prefer CentOS/RockyLinux
> over RHEL for that type of servers, which to me indicate that
> they are very price sensitive.

It's a bit subtler than that, if my employers are any example. They have
a few thousand Linux machines, which are mostly for software development
and testing, since they're an ISV. Only a small proportion are used as
servers. RHEL support on thousands of machines is quite a lot of money,
and you don't have to be very price sensitive to notice that.

They have enough sysadmins to allow them to solve most of their own Linux
problems. So they mostly use CentOS and its equivalents. RHEL is
theoretically free for development work, but the license admin is onerous
enough that an entirely free distribution is preferable.

John
It is loading more messages.
0 new messages