VSI strategy for OpenVMS

1447 views
Skip to first unread message

John Dallman

unread,
Sep 12, 2021, 7:19:13 AMSep 12
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 PMSep 12
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 PMSep 12
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 PMSep 12
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 PMSep 12
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 PMSep 12
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 PMSep 12
to
Perhaps Microsoft will port Edge to VMS?

That might keep Phillip happy :)

--
Chris

Simon Clubley

unread,
Sep 12, 2021, 8:02:54 PMSep 12
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 PMSep 12
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 PMSep 12
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 PMSep 12
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 PMSep 12
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 PMSep 12
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 AMSep 13
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 AMSep 13
to
Any browser requires a desktop. I thought that idea had been abandoned?

bill

Bill Gunshannon

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

bill

chris

unread,
Sep 13, 2021, 8:29:09 AMSep 13
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 AMSep 13
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 AMSep 13
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 AMSep 13
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 AMSep 13
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 AMSep 13
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 AMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
to
:-) :-)

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

:-)

chris

unread,
Sep 13, 2021, 8:01:18 PMSep 13
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 PMSep 13
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 PMSep 13
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 PMSep 13
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
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 AMSep 14
to
And very efficient I/O.

bill


Arne Vajhøj

unread,
Sep 14, 2021, 10:17:17 AMSep 14
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