Discussion:
VSI strategy for OpenVMS
(too old to reply)
John Dallman
2021-09-12 11:19:00 UTC
Permalink
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
2021-09-12 17:39:05 UTC
Permalink
Post by John Dallman
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.
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)
2021-09-12 18:53:45 UTC
Permalink
Post by Arne Vajhøj
Post by John Dallman
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.
- 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.
Post by Arne Vajhøj
- work with open source projects to include VMS as supported platform
in main repo
Definitely. LaTeX! Firefox!!!
Arne Vajhøj
2021-09-12 23:19:42 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by John Dallman
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.
- 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.
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
- 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
2021-09-12 23:53:54 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by John Dallman
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.
- 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.
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
- 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
Perhaps Microsoft will port Edge to VMS?

That might keep Phillip happy :)
--
Chris
Scott Dorsey
2021-09-13 00:30:45 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
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.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2021-09-13 00:41:10 UTC
Permalink
Post by Scott Dorsey
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
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
Simon Clubley
2021-09-13 00:02:52 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
- 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.
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
- 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.
Post by Phillip Helbig (undress to reply)
Definitely. LaTeX! Firefox!!!
That's not a strategy for VMS Phillip. That's a suicide note.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Craig A. Berry
2021-09-13 01:30:55 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
- work with open source projects to include VMS as supported platform
in main repo
Definitely. LaTeX! Firefox!!!
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.
Bill Gunshannon
2021-09-13 12:07:25 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
- work with open source projects to include VMS as supported platform
    in main repo
Definitely.  LaTeX!  Firefox!!!
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.
Any browser requires a desktop. I thought that idea had been abandoned?

bill
Scott Dorsey
2021-09-13 17:24:00 UTC
Permalink
Post by Bill Gunshannon
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.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
chris
2021-09-14 00:01:11 UTC
Permalink
Post by Scott Dorsey
Post by Bill Gunshannon
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.
--scott
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
2021-09-14 00:14:05 UTC
Permalink
Post by chris
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)
2021-09-14 04:41:02 UTC
Permalink
Post by Arne Vajhøj
Post by chris
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.
Arne Vajhøj
2021-09-14 12:16:00 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by chris
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.
Most VMS systems runs something important and do not have
access to download directly from the internet.

Arne
chris
2021-09-14 12:25:29 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by chris
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.
Most VMS systems runs something important and do not have
access to download directly from the internet.
Arne
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
2021-09-14 12:39:23 UTC
Permalink
Post by chris
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by chris
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
chris
2021-09-14 15:12:34 UTC
Permalink
Post by Arne Vajhøj
Post by 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..
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...

Chris
David Goodwin
2021-09-14 23:52:56 UTC
Permalink
Post by chris
Post by Arne Vajhøj
Post by 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..
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
2021-09-15 00:24:15 UTC
Permalink
Post by David Goodwin
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.
Post by David Goodwin
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.
Post by David Goodwin
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
2021-09-15 02:08:36 UTC
Permalink
Post by Arne Vajhøj
Post by David Goodwin
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).
Post by Arne Vajhøj
Post by David Goodwin
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.
Post by David Goodwin
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
2021-09-15 02:24:00 UTC
Permalink
Post by David Goodwin
Post by Arne Vajhøj
Post by David Goodwin
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
2021-09-15 02:55:13 UTC
Permalink
Post by Arne Vajhøj
Post by David Goodwin
Post by Arne Vajhøj
Post by David Goodwin
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.
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
2021-09-15 03:10:58 UTC
Permalink
Post by David Goodwin
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.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-15 13:00:13 UTC
Permalink
Post by David Goodwin
Post by Arne Vajhøj
Post by David Goodwin
Post by Arne Vajhøj
Post by David Goodwin
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.
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.
Yes.

They can run the exact same code base by running RockyLinux.

But some companies want support.

Especially when it is not prohibitive priced.
Post by David Goodwin
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?
VMS systems are usually business critical and not in massive scale - I
suspect that a pretty big share of VMS customer want support.

I do not expect VSI to make VMS available for free for general usage.

VSI already have good programs for ISV's and hobbyists.
Post by David Goodwin
Or is RedHats business model only viable
due to the sheer size of the Linux market?
The Linux model is a bit unique.

Arne
Jan-Erik Söderholm
2021-09-14 12:53:37 UTC
Permalink
Post by chris
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by chris
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.
Most VMS systems runs something important and do not have
access to download directly from the internet.
Arne
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
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
2021-09-14 13:38:05 UTC
Permalink
Post by Jan-Erik Söderholm
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
2021-09-14 13:59:37 UTC
Permalink
Post by David Jones
Post by Jan-Erik Söderholm
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.

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
Phillip Helbig (undress to reply)
2021-09-14 21:05:49 UTC
Permalink
Post by Arne Vajhøj
Post by David Jones
Post by Jan-Erik Söderholm
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.
Arne Vajhøj
2021-09-14 22:14:13 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by David Jones
Post by Jan-Erik Söderholm
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.
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
chris
2021-09-14 15:16:27 UTC
Permalink
Post by Jan-Erik Söderholm
Post by 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..
Chris
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.
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
Dave Froble
2021-09-14 19:26:15 UTC
Permalink
Post by chris
Post by Jan-Erik Söderholm
Post by 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..
Chris
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.
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
Maybe not for some, but here VMS is exclusive, required, and appreciated.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2021-09-14 19:23:41 UTC
Permalink
Post by Jan-Erik Söderholm
Post by chris
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by chris
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.
Most VMS systems runs something important and do not have
access to download directly from the internet.
Arne
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
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.

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-14 19:45:28 UTC
Permalink
Post by Jan-Erik Söderholm
Post by 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
Bill Gunshannon
2021-09-15 16:48:12 UTC
Permalink
Post by Jan-Erik Söderholm
Post by chris
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by chris
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.
Most VMS systems runs something important and do not have
access to download directly from the internet.
Arne
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
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.
:-)
I had a VAX 8600 three machine cluster as a desktop once. The
machine remained in the computer room and the monitor, keyboard
and mouse were on my desk. Long cables under the raised floor.
The same can be done with x86/64 class machines. Easier, actually.

bill
Phillip Helbig (undress to reply)
2021-09-14 21:05:13 UTC
Permalink
Post by Jan-Erik Söderholm
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!
Bill Gunshannon
2021-09-14 14:04:59 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by chris
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.
Most VMS systems runs something important and do not have
access to download directly from the internet.
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
Arne Vajhøj
2021-09-14 14:17:13 UTC
Permalink
Post by Arne Vajhøj
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.
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.

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
chris
2021-09-14 15:26:55 UTC
Permalink
Post by Arne Vajhøj
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
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.
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.
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
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
2021-09-14 15:45:07 UTC
Permalink
Post by chris
Post by Arne Vajhøj
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.
Post by chris
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
2021-09-14 17:08:51 UTC
Permalink
Post by Arne Vajhøj
Post by chris
Post by Arne Vajhøj
Post by Bill Gunshannon
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.
Post by chris
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
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
2021-09-14 17:51:17 UTC
Permalink
Post by Arne Vajhøj
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, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Joukj
2021-09-15 06:36:23 UTC
Permalink
Post by Arne Vajhøj
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.
Bill Gunshannon
2021-09-15 16:49:43 UTC
Permalink
Post by Joukj
Post by Arne Vajhøj
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.
I never found it to be complicated. Not even on Windows. And lack
of native X11 support in Windows is a non-problem.

bill

Dave Froble
2021-09-14 19:19:18 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by chris
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.
Most VMS systems runs something important and do not have
access to download directly from the internet.
Arne
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 ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Phillip Helbig (undress to reply)
2021-09-14 21:02:40 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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.
Dave Froble
2021-09-14 19:16:26 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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 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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-09-14 06:34:03 UTC
Permalink
Post by Arne Vajhøj
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
I'd say that the browser is *never* run on the system that is managed.
Scott Dorsey
2021-09-14 20:35:58 UTC
Permalink
Post by chris
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.
Post by chris
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."
chris
2021-09-14 21:33:46 UTC
Permalink
Post by Scott Dorsey
Post by chris
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.
Post by Scott Dorsey
Post by chris
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
John Dallman
2021-09-12 22:46:00 UTC
Permalink
Post by Arne Vajhøj
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
2021-09-12 23:17:24 UTC
Permalink
Post by John Dallman
Post by Arne Vajhøj
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.
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
Simon Clubley
2021-09-13 00:13:50 UTC
Permalink
Post by Arne Vajhøj
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.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-09-13 00:25:45 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
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
Arne Vajhøj
2021-09-13 14:15:10 UTC
Permalink
Post by Arne Vajhøj
Post by John Dallman
Post by Arne Vajhøj
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.
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..
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
2021-09-13 14:46:09 UTC
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by John Dallman
Post by Arne Vajhøj
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.
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..
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
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
2021-09-13 14:48:57 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
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".
:-)
"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
Dave Froble
2021-09-13 18:37:26 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by John Dallman
Post by Arne Vajhøj
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.
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..
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
"Shared Stream IO (SSIO) (Non-clustered)"
That "non-clustred" phrase might be an issue for some...
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-09-13 18:46:02 UTC
Permalink
Post by Dave Froble
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, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-09-13 22:33:04 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
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 ...
Post by Simon Clubley
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 ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-13 18:58:11 UTC
Permalink
Post by Jan-Erik Söderholm
"Shared Stream IO (SSIO) (Non-clustered)"
That "non-clustred" phrase might be an issue for some...
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.
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
Phillip Helbig (undress to reply)
2021-09-13 20:29:18 UTC
Permalink
Post by Dave Froble
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.
Post by Dave Froble
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.
Scott Dorsey
2021-09-13 20:57:17 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2021-09-14 00:09:19 UTC
Permalink
Post by Scott Dorsey
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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
* low cost OS & web SW
* uptodate web SW

Arne
Bill Gunshannon
2021-09-14 14:08:05 UTC
Permalink
Post by Arne Vajhøj
Post by Scott Dorsey
Post by Phillip Helbig (undress to reply)
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.
* low cost HW
* low cost OS & web SW
* uptodate web SW
And very efficient I/O.

bill
Arne Vajhøj
2021-09-14 14:19:10 UTC
Permalink
Post by Bill Gunshannon
Post by Arne Vajhøj
Post by Scott Dorsey
Post by Phillip Helbig (undress to reply)
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.
* low cost HW
* low cost OS & web SW
* uptodate web SW
And very efficient I/O.
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
Dave Froble
2021-09-14 19:47:34 UTC
Permalink
Post by Arne Vajhøj
Post by Scott Dorsey
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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.
* 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 ...
Post by Arne Vajhøj
* low cost OS & web SW
* uptodate web SW
Arne
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-14 20:01:18 UTC
Permalink
Post by Arne Vajhøj
Post by Scott Dorsey
Post by Phillip Helbig (undress to reply)
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.
* 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 ...
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
Scott Dorsey
2021-09-14 20:38:52 UTC
Permalink
Post by Arne Vajhøj
Post by Scott Dorsey
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.
* 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.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Arne Vajhøj
2021-09-14 20:45:34 UTC
Permalink
Post by Scott Dorsey
Post by Arne Vajhøj
Post by Scott Dorsey
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.
* 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.
Post by Scott Dorsey
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
John Dallman
2021-09-15 08:16:00 UTC
Permalink
Post by Arne Vajhøj
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
Arne Vajhøj
2021-09-14 00:12:06 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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.
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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
Phillip Helbig (undress to reply)
2021-09-14 04:39:58 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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?
Post by Arne Vajhøj
Disaster tolerance can be achieved in different ways.
But none as good as a VMS cluster.
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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.
Arne Vajhøj
2021-09-14 12:19:58 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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.
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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.
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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
Dave Froble
2021-09-14 19:57:13 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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.
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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.
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-14 20:41:39 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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.
Post by Dave Froble
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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.
Post by Dave Froble
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
Simon Clubley
2021-09-15 12:05:13 UTC
Permalink
Post by Dave Froble
Cluster pricing and marketing has been a great failing of DEC, Compaq,
HP, and we await to discover how VSI will do so.
Probably snatch defeat from the jaws of victory based on their last
licencing decision...

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Phillip Helbig (undress to reply)
2021-09-14 21:04:15 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
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.
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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.
Arne Vajhøj
2021-09-14 22:24:36 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
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.
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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
k***@gmail.com
2021-09-14 23:23:02 UTC
Permalink
-----Original Message-----
Info-vax
Sent: September-14-21 7:25 PM
Subject: Re: [Info-vax] VSI strategy for OpenVMS
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
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.
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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
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
Phillip Helbig (undress to reply)
2021-09-15 05:00:19 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Arne Vajhøj
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?
Dave Froble
2021-09-14 19:50:39 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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.
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
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.
Post by Arne Vajhøj
Arne
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-14 20:34:36 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
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.
Post by Dave Froble
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
Jan-Erik Söderholm
2021-09-13 21:56:50 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by John Dallman
Post by Arne Vajhøj
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.
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..
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
"Shared Stream IO (SSIO) (Non-clustered)"
That "non-clustred" phrase might be an issue for some...
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.
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
2021-09-13 22:38:38 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by John Dallman
Post by Arne Vajhøj
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.
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..
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
"Shared Stream IO (SSIO) (Non-clustered)"
That "non-clustred" phrase might be an issue for some...
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.
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...
:-) :-)

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

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Phillip Helbig (undress to reply)
2021-09-14 04:37:03 UTC
Permalink
Post by Jan-Erik Söderholm
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.
Post by Jan-Erik Söderholm
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.
Joukj
2021-09-13 09:53:13 UTC
Permalink
Post by John Dallman
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.

Regards
Jouk
Bill Gunshannon
2021-09-13 12:09:26 UTC
Permalink
Post by Joukj
Post by John Dallman
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
chris
2021-09-13 12:29:07 UTC
Permalink
Post by Joukj
Post by John Dallman
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. 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
2021-09-13 13:38:40 UTC
Permalink
Post by chris
Post by Joukj
Post by John Dallman
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.
Post by chris
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
Jan-Erik Söderholm
2021-09-13 14:50:18 UTC
Permalink
Post by Arne Vajhøj
Post by chris
Post by Joukj
Post by John Dallman
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 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...
Post by Arne Vajhøj
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.
Post by chris
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
2021-09-13 18:36:16 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
Post by chris
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
chris
2021-09-13 18:03:56 UTC
Permalink
Post by Arne Vajhøj
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.
Post by Arne Vajhøj
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
2021-09-13 18:15:51 UTC
Permalink
Post by chris
Post by Arne Vajhøj
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.
Post by chris
Post by Arne Vajhøj
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.
Post by chris
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
Simon Clubley
2021-09-13 18:42:02 UTC
Permalink
Post by Arne Vajhøj
Post by chris
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.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2021-09-13 18:49:03 UTC
Permalink
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.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-09-13 19:02:12 UTC
Permalink
Post by Simon Clubley
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)
2021-09-13 20:31:53 UTC
Permalink
Post by Simon Clubley
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.
Arne Vajhøj
2021-09-13 13:44:06 UTC
Permalink
Post by Joukj
Post by John Dallman
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().  :-)
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
calliet gérard
2021-09-13 16:51:07 UTC
Permalink
Post by John Dallman
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.
* 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
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
Loading...