Discussion:
WHY IS VSI REQUIRING A HYPERVISOR FOR X86 OPENVMS?
(too old to reply)
s***@gmail.com
2020-12-18 16:41:31 UTC
Permalink
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
Arne Vajhøj
2020-12-18 16:47:47 UTC
Permalink
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
The last roadmap I have seen says:

9.0 : VBOX and KVM
9.1 : VBOX, KVM and HPE DL380
9.2 : VBOX, KVM, VMware, HPE DL380 and HPE DL385
9.2-x : VBOX, KVM, VMware, HPE DL580 and unspecified Del servers (and I
assume still HPE DL380 and HPE DL385)

(VBOX must be VirtualBox)

so a mix of physical, commercial virtual and free virtual.

Arne
s***@gmail.com
2020-12-19 18:38:30 UTC
Permalink
Post by Arne Vajhøj
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
9.0 : VBOX and KVM
9.1 : VBOX, KVM and HPE DL380
9.2 : VBOX, KVM, VMware, HPE DL380 and HPE DL385
9.2-x : VBOX, KVM, VMware, HPE DL580 and unspecified Del servers (and I
assume still HPE DL380 and HPE DL385)
(VBOX must be VirtualBox)
so a mix of physical, commercial virtual and free virtual.
Arne
CERTS TO DATE

VMWARE 66

KVM 30
geze...@rlgsc.com
2020-12-18 17:11:22 UTC
Permalink
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
Super...,

At release, certain x86-64 hardware platforms are have been identified as "supported". As in any situation, it is a question of hardware drivers and qualification.

The present field test releases are released for use on VMs for simplicity. It is far simpler to qualify a system on the standardized environment provided by a VM than supporting the myriad hardware options.

- Bob Gezelter, http://www.rlgsc.com
Stephen Hoffman
2020-12-18 21:03:18 UTC
Permalink
Post by ***@rlgsc.com
Post by s***@gmail.com
This adds more cost.
Why can't it run by itself on x86? Or am I misunderstanding that you do
not have to buy vmware or some other VM to run it?
Super...,
At release, certain x86-64 hardware platforms are have been identified
as "supported". As in any situation, it is a question of hardware
drivers and qualification.
The present field test releases are released for use on VMs for
simplicity. It is far simpler to qualify a system on the standardized
environment provided by a VM than supporting the myriad hardware
options.
Yes, the VSI roadmap is less than explicit on this topic, and the VSI
website navigation isn't particularly helpful.
https://vmssoftware.com/pdfs/VMS_Software_Roadmap_2020.pdf

Native boot support is planned. There've been requests for tooling that
can identify supported hardware, but then the production release is
still a year or three out—and that'll prolly involve a generation or
two of newer hardware, too.

As for pricing, both VirtualBox and KVM are free, and VMware pricing
varies; Fusion on macOS is cheap. This so long as you avoid the
optional extensions pack licensing with VirtualBox:
https://www.virtualbox.org/wiki/Licensing_FAQ

Previous discussions include:
https://groups.google.com/g/comp.os.vms/c/rJGHKaFsa0A/m/5J2Au3-IAAAJ
and within that thread
https://groups.google.com/g/comp.os.vms/c/rJGHKaFsa0A/m/STp1WvMdAQAJ

Why is virtual machine support considered a priority at VSI, beyond
native x86-64 support? Some related reading:
https://groups.google.com/g/comp.os.vms/c/4WodYI9icWs/m/JHU78_VpAAAJ
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2020-12-18 17:13:54 UTC
Permalink
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
Well Bob, if you read as much as you write, you'd already know the
answer to that question.

VSI has mentioned, many times, that their goal is to support usage with
and without VMs. With, because so many customers are asking for it.
Without because of tradition, or whatever.

Consider, a VM allows one to have the effect of custom hardware, without
actually having said hardware. This can be very flexible. For one
thing, it makes their porting to x86 much easier, and less costly. They
do not have to have any specific hardware. Also consider that by the
time the port is ready for prime time, any hardware they ported to will
already be obsolete.

VSI has mentioned that some hardware will be supported. Not all, or
even most, because types of hardware have exploded into so many
varieties. It is no longer the 1980s where just a few types of hardware
existed.

But the biggest reason VMs will be supported is, because the customers
have asked for just that. And you know, the customer is always right.
--
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)
2020-12-18 18:39:40 UTC
Permalink
Post by Dave Froble
VSI has mentioned that some hardware will be supported. Not all, or
even most, because types of hardware have exploded into so many
varieties.
A while back, someone posted a script here to test whether a given
hardware would run VMS on x86. It seems that many different types of
hardware do, even though they might not be officially supported.
geze...@rlgsc.com
2020-12-18 19:05:33 UTC
Permalink
Post by Phillip Helbig (undress to reply)
VSI has mentioned that some hardware will be supported. Not all, or
even most, because types of hardware have exploded into so many
varieties.
A while back, someone posted a script here to test whether a given
hardware would run VMS on x86. It seems that many different types of
hardware do, even though they might not be officially supported.
Phillip,

Camiel posted the script to the newgroup. It is included with the Field Test kits.

However, the script only checks for CPU characteristics. Peripherals is another ball of wax.

- Bob Gezelter, http://www.rlgsc.com
s***@gmail.com
2020-12-19 18:21:08 UTC
Permalink
Post by Dave Froble
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
Well Bob, if you read as much as you write, you'd already know the
answer to that question.
VSI has mentioned, many times, that their goal is to support usage with
and without VMs. With, because so many customers are asking for it.
Without because of tradition, or whatever.
Consider, a VM allows one to have the effect of custom hardware, without
actually having said hardware. This can be very flexible. For one
thing, it makes their porting to x86 much easier, and less costly. They
do not have to have any specific hardware. Also consider that by the
time the port is ready for prime time, any hardware they ported to will
already be obsolete.
VSI has mentioned that some hardware will be supported. Not all, or
even most, because types of hardware have exploded into so many
varieties. It is no longer the 1980s where just a few types of hardware
existed.
But the biggest reason VMs will be supported is, because the customers
have asked for just that. And you know, the customer is always right.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
well DAVE THERE HAS BEEN NO MENTION OF IT AS A HYPERVISOR
IS A BIG FAT **** SECURITY HOLE **** JUST WAITING TO GIVE THE
BAD GUYS ACCESS TO YOUR DATA.
Andy Burns
2020-12-19 18:28:52 UTC
Permalink
Post by s***@gmail.com
well DAVE THERE HAS BEEN NO MENTION OF IT
Are we meant to interpret lowercase as emphasis?
Dave Froble
2020-12-19 20:11:09 UTC
Permalink
Post by s***@gmail.com
Post by Dave Froble
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
Well Bob, if you read as much as you write, you'd already know the
answer to that question.
VSI has mentioned, many times, that their goal is to support usage with
and without VMs. With, because so many customers are asking for it.
Without because of tradition, or whatever.
Consider, a VM allows one to have the effect of custom hardware, without
actually having said hardware. This can be very flexible. For one
thing, it makes their porting to x86 much easier, and less costly. They
do not have to have any specific hardware. Also consider that by the
time the port is ready for prime time, any hardware they ported to will
already be obsolete.
VSI has mentioned that some hardware will be supported. Not all, or
even most, because types of hardware have exploded into so many
varieties. It is no longer the 1980s where just a few types of hardware
existed.
But the biggest reason VMs will be supported is, because the customers
have asked for just that. And you know, the customer is always right.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
well DAVE THERE HAS BEEN NO MENTION OF IT AS A HYPERVISOR
IS A BIG FAT **** SECURITY HOLE **** JUST WAITING TO GIVE THE
BAD GUYS ACCESS TO YOUR DATA.
How does that fit with your original question?

As mentioned, you cvan have it either way, your choice.

And the bad guys could still get access to your data, either way.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Michael C
2020-12-19 18:44:23 UTC
Permalink
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
VMWARE JUST THIS YEAR


VMware Releases Security Updates - Updated October 20, 2020
Created: Thursday, October 22, 2020 - 10:44
Categories: Cybersecurity

October 20, 2020

VMware has released security updates to address vulnerabilities affecting multiple products. A remote attacker could exploit one of these vulnerabilities to take control of an affected system. CISA encourages users and administrators to review VMware Security Advisory VMSA-2020-0023 and apply the necessary updates or workarounds. Read the advisory at CISA.

July 10, 2020

VMware has released security updates to address a vulnerability in VMware Fusion, Remote Console, and Horizon Client. An attacker could exploit this vulnerability to take control of an affected system. ISA) encourages users and administrators to review VMware Security Advisory VMSA-2020-0017 and apply the necessary updates. Read the advisory at CISA.

July 8, 2020

VMware has released a security update to address a vulnerability in VeloCloud. An attacker could exploit this vulnerability to obtain sensitive information. CISA encourages users and administrators to review VMware Security Advisory VMSA-2020-0016 and apply the necessary update. Read the advisory at CISA.

June 24, 2020

VMware has released security updates to address multiple vulnerabilities in VMware ESXi, Workstation, Fusion, and Cloud Foundation. An attacker could exploit some of these vulnerabilities to take control of an affected system. CISA encourages users and administrators to review VMware Security Advisory VMSA-2020-0015 and apply the necessary updates or workarounds. Access the advisory at CISA.

June 10, 2020

VMware has released a security update to address a vulnerability in Horizon Client for Windows. An attacker could exploit this vulnerability to take control of an affected system. CISA encourages users and administrators to review VMware Security Advisory VMSA-2020-0013 and apply the necessary update. Read the advisory at CISA.

May 29, 2020

VMware has released security updates to address vulnerabilities affecting multiple products. An attacker could exploit one of these vulnerabilities to take control of an affected system. CISA encourages users and administrators to review the VMware Security Advisory VMSA-2020-0011 and apply the necessary updates. Read the advisory at CISA.

April 29, 2020

VMware has released security updates to address a vulnerability in ESXi. An attacker could exploit this vulnerability to take control of an affected system. CISA encourages users and administrators to review VMware Security Advisory VMSA-2020-0008 and apply the necessary updates. Read the advisory at CISA.

April 10, 2020

VMware has released security updates to address a vulnerability in VMware Directory Service (vmdir). An attacker could exploit this vulnerability to take control of an affected system. CISA encourages users and administrators to review VMware Security Advisory VMSA-2020-0006 and apply the necessary updates. Read the advisory at CISA.

March 16, 2020

VMware has released security updates to address vulnerabilities in multiple products. An attacker could exploit these vulnerabilities to take control of an affected system. CISA encourages users and administrators to review VMware Security Advisory VMSA-2020-0004 and apply the necessary updates. Read the advisory at CISA.

February 19, 2020

VMware has released security updates to address multiple vulnerabilities in vRealize Operations for Horizon Adapter. A remote attacker could exploit some of these vulnerabilities to take control of an affected system. CISA encourages users and administrators to review VMware Security Advisory VMSA-2020-0003 and apply the necessary updates. Read the advisory at CISA.
Michael C
2020-12-19 18:49:07 UTC
Permalink
Post by Dave Froble
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
Well Bob, if you read as much as you write, you'd already know the
answer to that question.
VSI has mentioned, many times, that their goal is to support usage with
and without VMs. With, because so many customers are asking for it.
Without because of tradition, or whatever.
Consider, a VM allows one to have the effect of custom hardware, without
actually having said hardware. This can be very flexible. For one
thing, it makes their porting to x86 much easier, and less costly. They
do not have to have any specific hardware. Also consider that by the
time the port is ready for prime time, any hardware they ported to will
already be obsolete.
VSI has mentioned that some hardware will be supported. Not all, or
even most, because types of hardware have exploded into so many
varieties. It is no longer the 1980s where just a few types of hardware
existed.
But the biggest reason VMs will be supported is, because the customers
have asked for just that. And you know, the customer is always right.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
A LITTLE LESSON DAVE ANYTHING WRITTEN IN C OR RUNNING ON LINUX OR WINDOZE WILL HAVE A VULNERABILITY LIST A MILE LONG.

THAT IS WHY YOU DON'T WANT NO MIDDLE MAN WITH OPENVMS
Simon Clubley
2020-12-21 01:05:49 UTC
Permalink
Post by Michael C
A LITTLE LESSON DAVE ANYTHING WRITTEN IN C OR RUNNING ON LINUX OR WINDOZE WILL HAVE A VULNERABILITY LIST A MILE LONG.
THAT IS WHY YOU DON'T WANT NO MIDDLE MAN WITH OPENVMS
Much of VMS is written in assembly language which is even worse than
C at letting silly errors through.

However, the latest work in VMS is done using C so that's an
improvement over Macro-32 when it comes to detecting silly errors.

Also, Linux has a number of good security features that VMS could
really benefit from such as mandatory access controls, ASLR and KASLR.

It also has an army of security researchers who go looking for
security issues so that ends up making Linux more secure.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John Reagan
2020-12-21 01:55:50 UTC
Permalink
Post by Simon Clubley
Post by Michael C
A LITTLE LESSON DAVE ANYTHING WRITTEN IN C OR RUNNING ON LINUX OR WINDOZE WILL HAVE A VULNERABILITY LIST A MILE LONG.
THAT IS WHY YOU DON'T WANT NO MIDDLE MAN WITH OPENVMS
Much of VMS is written in assembly language which is even worse than
C at letting silly errors through.
However, the latest work in VMS is done using C so that's an
improvement over Macro-32 when it comes to detecting silly errors.
"Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms.
Simon Clubley
2020-12-21 02:08:31 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
Post by Michael C
A LITTLE LESSON DAVE ANYTHING WRITTEN IN C OR RUNNING ON LINUX OR WINDOZE WILL HAVE A VULNERABILITY LIST A MILE LONG.
THAT IS WHY YOU DON'T WANT NO MIDDLE MAN WITH OPENVMS
Much of VMS is written in assembly language which is even worse than
C at letting silly errors through.
However, the latest work in VMS is done using C so that's an
improvement over Macro-32 when it comes to detecting silly errors.
"Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms.
Make that "Much of VMS was written in assembly language originally ...". :-)

I wonder what Bob thinks about BLISS ? :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Michael C
2020-12-21 12:43:20 UTC
Permalink
Post by Simon Clubley
Post by Simon Clubley
Post by Michael C
A LITTLE LESSON DAVE ANYTHING WRITTEN IN C OR RUNNING ON LINUX OR WINDOZE WILL HAVE A VULNERABILITY LIST A MILE LONG.
THAT IS WHY YOU DON'T WANT NO MIDDLE MAN WITH OPENVMS
Much of VMS is written in assembly language which is even worse than
C at letting silly errors through.
However, the latest work in VMS is done using C so that's an
improvement over Macro-32 when it comes to detecting silly errors.
"Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms.
Make that "Much of VMS was written in assembly language originally ...". :-)
I wonder what Bob thinks about BLISS ? :-)
A LOT BETTER THAN C
Post by Simon Clubley
Simon.
--
Walking destinations on a map are further away than they appear.
Wilm Boerhout
2020-12-21 15:02:08 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
Post by Michael C
A LITTLE LESSON DAVE ANYTHING WRITTEN IN C OR RUNNING ON LINUX OR WINDOZE WILL HAVE A VULNERABILITY LIST A MILE LONG.
THAT IS WHY YOU DON'T WANT NO MIDDLE MAN WITH OPENVMS
Much of VMS is written in assembly language which is even worse than
C at letting silly errors through.
However, the latest work in VMS is done using C so that's an
improvement over Macro-32 when it comes to detecting silly errors.
"Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms.
Apropos DECnet IV: a bunch of us in the HECnet alternate universe have
been running pydecnet (that is, DECnet IV written in python from the
original DECnet specifications) for a while now, thanks to Paul Koning's
implementation effort ***bows to Paul***

Just sayin'

/Wilm
Simon Clubley
2020-12-22 16:30:07 UTC
Permalink
Post by Wilm Boerhout
Post by John Reagan
"Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms.
Apropos DECnet IV: a bunch of us in the HECnet alternate universe have
been running pydecnet (that is, DECnet IV written in python from the
original DECnet specifications) for a while now, thanks to Paul Koning's
implementation effort ***bows to Paul***
$ set response/mode=good_natured

DECnet Phase IV in Python ??? That's just unnatural. ;-)

On a more serious note, I wonder why John was looking at the DECnet
Phase IV code. I wonder if something in there found a problem in the
new compilers ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Robert A. Brooks
2020-12-22 17:47:43 UTC
Permalink
Post by Simon Clubley
Post by Wilm Boerhout
Apropos DECnet IV: a bunch of us in the HECnet alternate universe have
been running pydecnet (that is, DECnet IV written in python from the
original DECnet specifications) for a while now, thanks to Paul Koning's
implementation effort ***bows to Paul***
$ set response/mode=good_natured
DECnet Phase IV in Python ??? That's just unnatural. ;-)
On a more serious note, I wonder why John was looking at the DECnet
Phase IV code. I wonder if something in there found a problem in the
new compilers ?
No, this was to fix an IA64-only problem related to MOP loading.

This problem does not exist on Alpha, nor does it exist if LANCP is used
to manage MOP clients.

I was picking at this on-and-off for about a year.

Solution was to delete a line of code.
--
-- Rob
Bill Gunshannon
2020-12-22 19:51:36 UTC
Permalink
Post by Robert A. Brooks
Post by Simon Clubley
Post by Wilm Boerhout
Apropos DECnet IV: a bunch of us in the HECnet alternate universe have
been running pydecnet (that is, DECnet IV written in python from the
original DECnet specifications) for a while now, thanks to Paul Koning's
implementation effort ***bows to Paul***
$ set response/mode=good_natured
DECnet Phase IV in Python ??? That's just unnatural. ;-)
On a more serious note, I wonder why John was looking at the DECnet
Phase IV code. I wonder if something in there found a problem in the
new compilers ?
No, this was to fix an IA64-only problem related to MOP loading.
This problem does not exist on Alpha, nor does it exist if LANCP is used
to manage MOP clients.
I was picking at this on-and-off for about a year.
Solution was to delete a line of code.
Any particular line of code? Or just pick one at random. :-)

bill
John Reagan
2020-12-22 17:54:06 UTC
Permalink
Post by Simon Clubley
Post by Wilm Boerhout
"Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms.
Apropos DECnet IV: a bunch of us in the HECnet alternate universe have
been running pydecnet (that is, DECnet IV written in python from the
original DECnet specifications) for a while now, thanks to Paul Koning's
implementation effort ***bows to Paul***
$ set response/mode=good_natured
DECnet Phase IV in Python ??? That's just unnatural. ;-)
On a more serious note, I wonder why John was looking at the DECnet
Phase IV code. I wonder if something in there found a problem in the
new compilers ?
Simon.
--
Walking destinations on a map are further away than they appear.
No conspiracies here. We were looking at the code that did MAC address lookups for MOP loads. It has some Alpha vs Itanium conditionals. I was asked by another engineer to explain why the two platforms were different what x86 needs. The original VAX version pushed routine addresses on the stack and did some "JSB @(SP)+" along with some hard resets of the SP (think of it as a cheap form of setjmp/longjmp). You can't do a store into SP on Itanium so the code had to do something else.

If you want a list of known bugs with the current x86 cross-compilers? I have that list too. There are several. I'm currently working on a linker issue that cropped up with our bootstrapping native compilers to x86. Our linker doesn't handle code in SHT_GROUP but EH data not in the group. It ended up trying to apply relocations to non-existent code. A sanity check was raised. What else do you want to know? For C, I have one bug dealing with a #pragma linkage, one with changing "align(page)", and request for a new builtin to read/write the Time Stamp Counter. There are a few open for Macro-32 and two for BLISS (all worked around with simple edits).
Simon Clubley
2020-12-22 18:17:25 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
Post by Wilm Boerhout
"Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms.
Apropos DECnet IV: a bunch of us in the HECnet alternate universe have
been running pydecnet (that is, DECnet IV written in python from the
original DECnet specifications) for a while now, thanks to Paul Koning's
implementation effort ***bows to Paul***
$ set response/mode=good_natured
DECnet Phase IV in Python ??? That's just unnatural. ;-)
On a more serious note, I wonder why John was looking at the DECnet
Phase IV code. I wonder if something in there found a problem in the
new compilers ?
Simon.
--
Walking destinations on a map are further away than they appear.
If you want a list of known bugs with the current x86 cross-compilers? I have that list too. There are several. I'm currently working on a linker issue that cropped up with our bootstrapping native compilers to x86. Our linker doesn't handle code in SHT_GROUP but EH data not in the group. It ended up trying to apply relocations to non-existent code. A sanity check was raised. What else do you want to know? For C, I have one bug dealing with a #pragma linkage, one with changing "align(page)", and request for a new builtin to read/write the Time Stamp Counter. There are a few open for Macro-32 and two for BLISS (all worked around with simple edits).
No conspiracy theory here. :-)

As I am sure _everyone_ around here knows, production code that was
working just fine in an old environment can sometimes break big time
in a new environment. Sometimes it turns out the code was only accidently
working :-) and sometimes it turns out the code found a problem in
the new environment. I was just curious if it was something like that.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John Reagan
2020-12-23 16:31:40 UTC
Permalink
Post by Simon Clubley
Post by Simon Clubley
Post by Wilm Boerhout
"Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms.
Apropos DECnet IV: a bunch of us in the HECnet alternate universe have
been running pydecnet (that is, DECnet IV written in python from the
original DECnet specifications) for a while now, thanks to Paul Koning's
implementation effort ***bows to Paul***
$ set response/mode=good_natured
DECnet Phase IV in Python ??? That's just unnatural. ;-)
On a more serious note, I wonder why John was looking at the DECnet
Phase IV code. I wonder if something in there found a problem in the
new compilers ?
Simon.
--
Walking destinations on a map are further away than they appear.
If you want a list of known bugs with the current x86 cross-compilers? I have that list too. There are several. I'm currently working on a linker issue that cropped up with our bootstrapping native compilers to x86. Our linker doesn't handle code in SHT_GROUP but EH data not in the group. It ended up trying to apply relocations to non-existent code. A sanity check was raised. What else do you want to know? For C, I have one bug dealing with a #pragma linkage, one with changing "align(page)", and request for a new builtin to read/write the Time Stamp Counter. There are a few open for Macro-32 and two for BLISS (all worked around with simple edits).
No conspiracy theory here. :-)
As I am sure _everyone_ around here knows, production code that was
working just fine in an old environment can sometimes break big time
in a new environment. Sometimes it turns out the code was only accidently
working :-) and sometimes it turns out the code found a problem in
the new environment. I was just curious if it was something like that.
Simon.
--
Walking destinations on a map are further away than they appear.
Oh, you want one of THOSE stories? Here's one.

Consider a broken C routine that is declared "int" but one or more paths don't have a valid 'return' statement. On Alpha/Itanium, the value in R0/r8 is often the return value from a prior call to something. GEM doesn't really want to reuse R0/r8 for any kind of temporary since it won't live past the next routine call (it will use them if pushed into a corner). The return without a 'return' just gets you that prior R0/r8 value. If your 'int' routine is really a true/false routine, you might have been working for years without any problems.

However, given the few registers on x86 (and how some of the instructions work), the return register %rax is used in many places for a short-term temporary. So when the C routine exits without a 'return' statement, the value in %rax can be very strange.

The C program has been broken on every platform. If you would have used something like /WARNING=ENABLE=QUESTCODE, the compiler can help identify those paths without a 'return'. You can look for those broken programs today on Alpha or Itanium. [I've been tempted to promote that check out of the QUESTCODE category and have it enabled by default. That decision was done long ago before I was in a position to do anything to help.]
Dave Froble
2020-12-23 18:33:42 UTC
Permalink
Post by John Reagan
The C program has been broken on every platform. If you would have
used something like /WARNING=ENABLE=QUESTCODE, the compiler can help
identify those paths without a 'return'. You can look for those
broken programs today on Alpha or Itanium. [I've been tempted to
promote that check out of the QUESTCODE category and have it enabled
by default. That decision was done long ago before I was in a
position to do anything to help.]
John, sometimes one really should give in to temptation ...
--
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
2020-12-26 11:09:31 UTC
Permalink
Post by John Reagan
Consider a broken C routine that is declared "int" but one or more paths don't have a valid 'return' statement. On Alpha/Itanium, the value in R0/r8 is often the return value from a prior call to something. GEM doesn't really want to reuse R0/r8 for any kind of temporary since it won't live past the next routine call (it will use them if pushed into a corner). The return without a 'return' just gets you that prior R0/r8 value. If your 'int' routine is really a true/false routine, you might have been working for years without any problems.
However, given the few registers on x86 (and how some of the instructions work), the return register %rax is used in many places for a short-term temporary. So when the C routine exits without a 'return' statement, the value in %rax can be very strange.
Interesting. I don't suppose we would happen to know the C program in
question ? :-)
Post by John Reagan
The C program has been broken on every platform. If you would have used something like /WARNING=ENABLE=QUESTCODE, the compiler can help identify those paths without a 'return'. You can look for those broken programs today on Alpha or Itanium. [I've been tempted to promote that check out of the QUESTCODE category and have it enabled by default. That decision was done long ago before I was in a position to do anything to help.]
The move to LLVM is your opportunity to do just this.

Besides, people should be compiling production code with warnings enabled
anyway and fixing the warnings, so you would just be helping to enforce
this practice.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John Reagan
2020-12-26 20:24:52 UTC
Permalink
Post by Simon Clubley
Consider a broken C routine that is declared "int" but one or more paths don't have a valid 'return' statement. On Alpha/Itanium, the value in R0/r8 is often the return value from a prior call to something. GEM doesn't really want to reuse R0/r8 for any kind of temporary since it won't live past the next routine call (it will use them if pushed into a corner). The return without a 'return' just gets you that prior R0/r8 value. If your 'int' routine is really a true/false routine, you might have been working for years without any problems.
However, given the few registers on x86 (and how some of the instructions work), the return register %rax is used in many places for a short-term temporary. So when the C routine exits without a 'return' statement, the value in %rax can be very strange.
Interesting. I don't suppose we would happen to know the C program in
question ? :-)
Seen them inside of PCSI and CMS recently.

The C NEEDSRETURN isn't perfect as a frontend can only statically analyze a program to see if edges to the end of a routine call contain a return, but control flow can change that. And I think /STAND=VAXC influences that too, not sure. We've been trying to remove /STAND=VAXC as we go. Some modules are trivial, some are just full of places that need typecasts (or better typedef's and macros). BLISS programmers that write C /STAND=VAXC, just go used to the "free typecasts" that K&R gives you.
David Jones
2020-12-26 14:04:03 UTC
Permalink
Consider a broken C routine that is declared "int" but one or more paths don't have a valid 'return' statement. On Alpha/Itanium, the value in R0/r8 is often the return value from a prior call to something. GEM doesn't really want to reuse R0/r8 for any kind of temporary since it won't live past the next routine call (it will use them if pushed into a corner). The return without a 'return' just gets you that prior R0/r8 value. If your 'int' routine is really a true/false routine, you might have been working for years without any problems.
However, given the few registers on x86 (and how some of the instructions work), the return register %rax is used in many places for a short-term temporary. So when the C routine exits without a 'return' statement, the value in %rax can be very strange.
The C program has been broken on every platform. If you would have used something like /WARNING=ENABLE=QUESTCODE, the compiler can help identify those paths without a 'return'. You can look for those broken programs today on Alpha or Itanium. [I've been tempted to promote that check out of the QUESTCODE category and have it enabled by default. That decision was done long ago before I was in a position to do anything to help.]
DECC's default settings have given warnings about that (%CC-W-MISSINGRETURN) for some time now, though it used to be an aggravating source of bugs.
Stephen Hoffman
2020-12-26 17:07:27 UTC
Permalink
Post by David Jones
Post by John Reagan
Consider a broken C routine that is declared "int" but one or more
paths don't have a valid 'return' statement. On Alpha/Itanium, the
value in R0/r8 is often the return value from a prior call to
something. GEM doesn't really want to reuse R0/r8 for any kind of
temporary since it won't live past the next routine call (it will use
them if pushed into a corner). The return without a 'return' just gets
you that prior R0/r8 value. If your 'int' routine is really a
true/false routine, you might have been working for years without any
problems.
However, given the few registers on x86 (and how some of the
instructions work), the return register %rax is used in many places for
a short-term temporary. So when the C routine exits without a 'return'
statement, the value in %rax can be very strange.
The C program has been broken on every platform. If you would have used
something like /WARNING=ENABLE=QUESTCODE, the compiler can help
identify those paths without a 'return'. You can look for those broken
programs today on Alpha or Itanium. [I've been tempted to promote that
check out of the QUESTCODE category and have it enabled by default.
That decision was done long ago before I was in a position to do
anything to help.]
DECC's default settings have given warnings about that
(%CC-W-MISSINGRETURN) for some time now, though it used to be an
aggravating source of bugs.
Discussions of the Clang -Wall (variously with -Wpendant and/or -Wextra
added) versus the less-than-recommended -Weverything have a long
history, too.

Clang warnings:
https://quuxplusone.github.io/blog/2018/12/06/dont-use-weverything/

For those new to Clang: https://nus-cs1010.github.io/2021-s1/clang.html

For OpenVMS, /WARNING=ENABLE=QUESTCODE being lit by default wouldn't
bother me, as I tend to use that and /STANDARD=C99 or RELAXED lit, and
a few other switches.

Which usually then evolves into something akin to: /STANDARD=C99
/WARN=( ENABLE=( NOC99, OBSOLESCENT, DEFUNCT, QUESTCODE, ...),
DISABLE=(...))

I've found that OpenVMS C code still written with VAXC features tends
to have latent bugs, too. Code with /STANDARD=VAXC is code that should
be looked at. Stuff that I'm maintaining that has /STANDARD=VAXC lit
eventually doesn't have that switch anymore.
--
Pure Personal Opinion | HoffmanLabs LLC
Galen
2020-12-27 03:34:49 UTC
Permalink
Post by David Jones
DECC's default settings have given warnings about that
(%CC-W-MISSINGRETURN) for some time now, though it used to be an
aggravating source of bugs.
I remember that the developers in my organization at Lockheed used a lot of
DCL-scripted build procedures that tested explicitly fo SS$_NORMAL after
compiling, and how they broke when this warning (and possibly others
introduced in that version of C) came into being.

We were also using MMS but not for every single application. I was possibly
using MMK myself. But I don’t recall if any builds broke that used those.
gérard Calliet
2020-12-23 14:39:07 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
Post by Michael C
A LITTLE LESSON DAVE ANYTHING WRITTEN IN C OR RUNNING ON LINUX OR WINDOZE WILL HAVE A VULNERABILITY LIST A MILE LONG.
THAT IS WHY YOU DON'T WANT NO MIDDLE MAN WITH OPENVMS
Much of VMS is written in assembly language which is even worse than
C at letting silly errors through.
However, the latest work in VMS is done using C so that's an
improvement over Macro-32 when it comes to detecting silly errors.
"Much"? I think Clair did a line count/module posting in the last year or so. The Macro-32 contribution was getting pretty low (less than 20%?) However, just the difficult and nasty parts that nobody wants to attempt to rewrite. I'd pay real money to watch somebody try to rewrite the shadow driver out of Macro-32 (pretty much every routine can jump into any other routine in an alternative universe threading scheme). And I've recently had to look at chunks of DECnet IV and even I couldn't make heads-or-tails out of some of the algorithms.
Hello VMS world,

The old and venerable passion for rewriting - as old and venerable as
the era of Shumpeterian economics: the holy creative destruction - is
getting its feet caught in the carpet of complexity inherited from the
even more venerable VMS. My delight.

Let's rewrite, my brothers, even if we don't understand much about the
intentions of our ancestors. Let's try to bring back to the mediocre
level of contemporary writings what was stroke of genius after stroke of
genius.

Do not polemic, it's just my testimony of good humor, with this adorable
refrain, a little jewel for me as a Christmas present.

Happy Holidays and Happy New Year.

Gérard Calliet
Scott Dorsey
2020-12-18 22:44:41 UTC
Permalink
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
This was discussed extensively here a year ago.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
John Dallman
1970-01-01 00:00:00 UTC
Permalink
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Device drivers. There is so much variety in x86 hardware that it's
completely impractical for VSI to write VMS device drivers for any
significant fraction of it. Hardware manufacturers produce Windows and
Linux drivers for their products, but they won't start writing VMS device
drivers unless it becomes highly successful.
Post by s***@gmail.com
Or am I misunderstanding that you do not have to buy vmware or some
other VM to run it?
You don't have to /pay/ for a VM system to run it.
Post by s***@gmail.com
9.0 : VBOX and KVM
9.1 : VBOX, KVM and HPE DL380
9.2 : VBOX, KVM, VMware, HPE DL380 and HPE DL385
9.2-x : VBOX, KVM, VMware, HPE DL580 and unspecified Del servers
(and I assume still HPE DL380 and HPE DL385)
(VBOX must be VirtualBox)
VirtualBox is free (https://www.virtualbox.org/) and runs on Windows,
Linux, Macintosh, and Solaris hosts.

KVM is part of the Linux kernel, and thus should be available on any
decent Linux distribution, again free.

John
David Wade
2020-12-19 15:48:41 UTC
Permalink
Post by John Dallman
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Device drivers. There is so much variety in x86 hardware that it's
completely impractical for VSI to write VMS device drivers for any
significant fraction of it. Hardware manufacturers produce Windows and
Linux drivers for their products, but they won't start writing VMS device
drivers unless it becomes highly successful.
Post by s***@gmail.com
Or am I misunderstanding that you do not have to buy vmware or some
other VM to run it?
You don't have to /pay/ for a VM system to run it.
Post by s***@gmail.com
9.0 : VBOX and KVM
9.1 : VBOX, KVM and HPE DL380
9.2 : VBOX, KVM, VMware, HPE DL380 and HPE DL385
9.2-x : VBOX, KVM, VMware, HPE DL580 and unspecified Del servers
(and I assume still HPE DL380 and HPE DL385)
(VBOX must be VirtualBox)
VirtualBox is free (https://www.virtualbox.org/) and runs on Windows,
Linux, Macintosh, and Solaris hosts.
KVM is part of the Linux kernel, and thus should be available on any
decent Linux distribution, again free.
John
If you need a bare metal Hypervisor even the basic vSphere ESXI is free
but with limits...

https://www.cbtnuggets.com/blog/certifications/cloud/vmware-esxi-free-vs-paid-a-look-at-license-limitations

Dave
Mark Daniel
2020-12-20 01:27:08 UTC
Permalink
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
Don't feed the troll.
Andrew Brehm
2020-12-20 18:00:39 UTC
Permalink
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
I don't see that they are requiring a hypervisor.

But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.

Where I work every bare metal server is a hassle. VMs deploy
automatically and there is no need to worry about the hardware. If the
hardware fails, VMs are moved to or restarted on different hardware. An
actual hypervisor _requirement_ would be perfect for us as it would cut
down on support costs and time.

But OpenVMS will, so they say, support both some HPE and Dell hardware
and some hypervisors, and all the supported hypervisors are available as
free editions as well as paid.

While VirtualBox is not a production environment VMM, both KVM and
vSphere are and all three can be free.

You can then install OpenVMS on your HPE hardware or install a free ESXi
on it or a free Linux with KVM and then OpenVMS. Where's the problem?
--
Andrew Brehm
Phillip Helbig (undress to reply)
2020-12-20 20:53:09 UTC
Permalink
Post by Andrew Brehm
I don't see that they are requiring a hypervisor.
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Assuming that you have such existing hardware. So, cheaper for those
already rich. :-|
Dave Froble
2020-12-20 21:28:57 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Andrew Brehm
I don't see that they are requiring a hypervisor.
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Assuming that you have such existing hardware. So, cheaper for those
already rich. :-|
First, I doubt you could find a bigger bigot than I am about having
anything between the HW and VMS. You could try, you would fail.

But that written, I did take a look at things, got an old version of
VirtualBox running on a WEENDOZE XP system, Got a current version
running on a WEENDOZE 7 system, and played around with some things. I
actually tried to create an instance of W95, W2K, XP, and W7, but some
of the older stuff was a problem. Regardless, I did see the advantages
of using a VM, I may be stubborn, but not inclined to cut off my nose to
spite my face.

On the other hand, I'm not too keen on getting some HP or Dell stuff. I
build my own systems. Fairly cheap.

So, I most likely will run x86 VMS on a VM instance, or more than one,
on the cheap HW I use, regardless of prior prejudice against anything
between VMS and the HW. Usage will mostly be software development, not
production Time will tell if that will be adequate.

The thing is, I'll be able to use the latest HW available, SSDs, and
such, and still run VMS. For several hundred dollars of HW. That's a
win. Spend more if you want. I cannot justify doing 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
Jan-Erik Söderholm
2020-12-20 23:02:24 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Andrew Brehm
I don't see that they are requiring a hypervisor.
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Assuming that you have such existing hardware.
Try to find one single VMS customer that has a VMS-only environment.
That will be quite hard. Rounded up a bit, I'd say that all sites
running VMS commercially (and paying VSI to do so!) also have a
suitable VM environment where they already run "everything else".

I don't think it is a question about being poor or rich.

And besides, if you have a VMS environment large enough and
can see the benefits, then do run it (VMS) on bare metal.

And for VMS amateurs, it is much easier to pick one of your last
laptops before you bought the latest one and run VirtualBox/VMS.
There you have a complete VMS system including a "console terminal"
in an inch thick package...
Post by Phillip Helbig (undress to reply)
So, cheaper for those already rich. :-|
Michael C
2020-12-21 01:06:38 UTC
Permalink
Post by Jan-Erik Söderholm
Try to find one single VMS customer that has a VMS-only environment.
YOU ARE CHATTING WITH HIM :)
Post by Jan-Erik Söderholm
That will be quite hard. Rounded up a bit, I'd say that all sites
running VMS commercially (and paying VSI to do so!) also have a
suitable VM environment where they already run "everything else".
Simon Clubley
2020-12-21 01:25:07 UTC
Permalink
Post by Michael C
Post by Jan-Erik Söderholm
Try to find one single VMS customer that has a VMS-only environment.
YOU ARE CHATTING WITH HIM :)
$ set response/mode=good_natured

Well then, you and Phillip are welcome to go and talk to each other
privately and leave the rest of us alone. :-)

BTW, what do you do for access to your VMS systems ?

How do your users read their email and do common office tasks such
as word processing and web browsing ?

Unless you have put a VMS workstation on every user's desktop (and
_only_ a VMS workstation without a PC), then you are not running a
VMS-only environment.

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)
2020-12-21 07:23:44 UTC
Permalink
Post by Simon Clubley
Well then, you and Phillip are welcome to go and talk to each other
privately and leave the rest of us alone. :-)
BTW, what do you do for access to your VMS systems ?
How do your users read their email and do common office tasks such
as word processing and web browsing ?
With my hobbyist cluster, VTs and workstations. Word processing is
LaTeX (much of which was developed on VMS).
Post by Simon Clubley
Unless you have put a VMS workstation on every user's desktop (and
_only_ a VMS workstation without a PC), then you are not running a
VMS-only environment.
Yes.
Michael C
2020-12-21 12:42:50 UTC
Permalink
Post by Simon Clubley
Post by Michael C
Post by Jan-Erik Söderholm
Try to find one single VMS customer that has a VMS-only environment.
YOU ARE CHATTING WITH HIM :)
BTW, what do you do for access to your VMS systems ?
VTs and POWERTERM
Post by Simon Clubley
How do your users read their email and do common office tasks such
as word processing and web browsing ?
PMDF
Post by Simon Clubley
Simon.
--
Walking destinations on a map are further away than they appear.
Simon Clubley
2020-12-22 16:25:48 UTC
Permalink
Post by Michael C
Post by Simon Clubley
Post by Michael C
Post by Jan-Erik Söderholm
Try to find one single VMS customer that has a VMS-only environment.
YOU ARE CHATTING WITH HIM :)
BTW, what do you do for access to your VMS systems ?
VTs and POWERTERM
What operating system does your Powerterm emulator run on ?
Post by Michael C
Post by Simon Clubley
How do your users read their email and do common office tasks such
as word processing and web browsing ?
PMDF
Wow! PMDF certainly has expanded in functionality since I last looked
at it.

I had no idea it had become a bare metal operating system, an email GUI
client, a word processor and also a web browser. Very impressive. :-)

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)
2020-12-21 07:21:52 UTC
Permalink
Post by Jan-Erik Söderholm
And for VMS amateurs, it is much easier to pick one of your last
laptops before you bought the latest one and run VirtualBox/VMS.
I own no laptop.
Post by Jan-Erik Söderholm
There you have a complete VMS system including a "console terminal"
in an inch thick package...
Without a proper keyboard.
Hans Bachner
2020-12-21 20:36:52 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Jan-Erik Söderholm
And for VMS amateurs, it is much easier to pick one of your last
laptops before you bought the latest one and run VirtualBox/VMS.
I own no laptop.
Post by Jan-Erik Söderholm
There you have a complete VMS system including a "console terminal"
in an inch thick package...
Without a proper keyboard.
There are several LK keyboard models with a PS/2 connector, and
PS/2-to-USB adapters.

Look at David's webpage, he offers many of them. Interestingly, this one:

<https://www.islandco.com/3x-lk464-a2-openvms-keyboard-german>

is a USB keyboard which comes with an USB-to-PS/2 adapter :-)

Hans.
Chris Townley
2020-12-21 20:43:41 UTC
Permalink
Post by Hans Bachner
There are several LK keyboard models with a PS/2 connector, and
PS/2-to-USB adapters.
<https://www.islandco.com/3x-lk464-a2-openvms-keyboard-german>
is a USB keyboard which comes with an USB-to-PS/2 adapter :-)
Hans.
That is quite a price - especially if you include shipping to Europe!

Chris
Dave Froble
2020-12-21 21:48:37 UTC
Permalink
Post by Chris Townley
Post by Hans Bachner
There are several LK keyboard models with a PS/2 connector, and
PS/2-to-USB adapters.
<https://www.islandco.com/3x-lk464-a2-openvms-keyboard-german>
is a USB keyboard which comes with an USB-to-PS/2 adapter :-)
Hans.
That is quite a price - especially if you include shipping to Europe!
Chris
Didn't check the price. But they aren't being mfg any more. And they
are really much better than anything available today.

Back in the 90s, when people were changing over to PCs, I wasn't smart
enough to pick up all the VT5** stuff being thrown out. Another of
life's mistakes.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2020-12-20 23:42:40 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Andrew Brehm
I don't see that they are requiring a hypervisor.
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Assuming that you have such existing hardware. So, cheaper for those
already rich. :-|
If we are still talking VMS then it is always going to cheaper on a
VM because hardware wise only the top end are likely to be supported
and they will always be expensive.

bill
David Wade
2020-12-23 12:16:04 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Andrew Brehm
I don't see that they are requiring a hypervisor.
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Assuming that you have such existing hardware. So, cheaper for those
already rich. :-|
As others have said free versions of all the major Hypervisors are
available so I can't see what cost there is. Even for the poor it will
usually save money.

If you already have a server that is not fully loaded and enough
capacity to run VMS you can virtualize the exiting OS image and add VMS.
There are free tools to let you do this.

If you need to buy a new server, well I can't believe any one is going
to max out even the cheapest modern server running VMS. So if you have
to buy a new server using a Hypervisor allows you to utilize the spare
capacity.

You can run another OS or two instances of VMS so you have a test
environment.

You are taking to emulated hardware so your OS can easily be moved to
another platform.

I used to think like you, but these days, if I was installing almost any
server it would be with a virtual hypervisor.

Dave
Comp.os.vms
2020-12-23 16:01:14 UTC
Permalink
-----Original Message-----
via Info-vax
Sent: December-23-20 8:16 AM
Subject: Re: [Info-vax] WHY IS VSI REQUIRING A HYPERVISOR FOR X86
OPENVMS?
Post by Phillip Helbig (undress to reply)
Post by Andrew Brehm
I don't see that they are requiring a hypervisor.
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and
support/install extra hardware for the platform. With a hypervisor
you can just add OpenVMS instances on your existing hardware.
Assuming that you have such existing hardware. So, cheaper for those
already rich. :-|
As others have said free versions of all the major Hypervisors are
available so
I can't see what cost there is. Even for the poor it will usually save
money.
If you already have a server that is not fully loaded and enough capacity
to
run VMS you can virtualize the exiting OS image and add VMS.
There are free tools to let you do this.
If you need to buy a new server, well I can't believe any one is going to
max
out even the cheapest modern server running VMS. So if you have to buy a
new server using a Hypervisor allows you to utilize the spare capacity.
You can run another OS or two instances of VMS so you have a test
environment.
You are taking to emulated hardware so your OS can easily be moved to
another platform.
I used to think like you, but these days, if I was installing almost any
server it
would be with a virtual hypervisor.
Dave
Imho, VSI adopting virtualization is a great move as they are responding to
the OpenVMS base requesting reduced support risks, costs, and deployment
flexibility - especially in dev/test environments. Yes, native OpenVMS on
X86-64 support is still critical because there are large OpenVMS Customer
environments that will demand native OpenVMS X86-64 support for performance
and/or security reasons.

Background - The reality is that industry server HW performance has
increased so much in the last decade+ that there are few server Apps on ANY
OS platform that requires a dedicated physical server for performance
reasons.

Security - yes, there are cases to be made to not add another layer of risk
and security patches management that is a fact when using virtualization.
And yes, there are cases where virtualization will not address all
performance sensitive application environments.

Back to past performance considerations. Historically, the reason for big
gap in low utilization levels of servers that was first seen on
Windows/Linux servers 25 years+ ago (pre-VMware) was partly because of the
culture of running one business app per server i.e., migration to three tier
models. When this culture was combined with the IT culture of green fielding
newer much more powerful (albeit cheaper) x86 servers every 3 years on a
one-for-one basis, it is easy to see that the overall utilization of these
x86 servers dropped after each green fielding upgrade was completed.

C level managers began to twitch and get cranky when their IT depts told
them that the servers they had less than 10-15% utilized in peak periods.
Hence - the reason why VMware became so popular. It allowed Customers to
increase the overall utilization of X86 servers, while at the same time,
maintain the culture of one bus app per server instance. Win-win for
everyone(?). Of course, the big winners were Microsoft and Red Hat who get
paid regardless of whether the OS is virtual or physical. The ease of
creating new OS instances with little creation / cleanup governance has led
to OS instance sprawl which again benefits Microsoft and Red Hat's license
model.

The performance utilization background is not only the case for Linux and
Windows servers, but also for OpenVMS servers. Most OpenVMS Customers today
upgrade from VAX and Alpha to IA64 for support and reduced support
costs/risks - not performance reasons. Most OpenVMS Customers are running
just fine on their current HW platforms - typically running at less than 50%
utilization in peak periods.

The primary migration driver for OpenVMS X86-64 migrations will be for
reducing support (end-of-life maint, license, security) risks and costs. As
an example - Oracle on OpenVMS X86-64 servers will enjoy the same PCF
(processor core factor) as Windows and Linux (0.5 x overall Oracle costs) as
opposed to the PCF of existing OpenVMS Alpha/IA64/PowerX HW platforms (1.0 x
overall Oracle costs).


Kerry
--
This email has been checked for viruses by AVG.
https://www.avg.com
Andrew Brehm
2020-12-31 17:01:11 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Andrew Brehm
I don't see that they are requiring a hypervisor.
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Assuming that you have such existing hardware. So, cheaper for those
already rich. :-|
You mean in case one runs a company without computers and wants to
introduce OpenVMS. In that case you wouldn't have existing hardware.

But most companies I know already have an IT infrastructure or at least
unwilling to build one that cannot be shared with other OS.

Where I work it is certainly much cheaper and quicker to order a VM and
install an OS than to order a physical server and install an OS. For one
thing, the former is fully automatted already and can easily be adapted
to another OS.
--
Andrew Brehm
Michael C
2020-12-21 01:03:04 UTC
Permalink
Post by Andrew Brehm
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Where I work every bare metal server is a hassle. VMs deploy
automatically and there is no need to worry about the hardware. If the
hardware fails, VMs are moved to or restarted on different hardware. An
actual hypervisor _requirement_ would be perfect for us as it would cut
down on support costs and time.
1ST PROBLEM - RESTARTED

THERE ARE CUSTOMERS, MOST I WOULD THINK, WHO WANT 24/7 UPTIME THAT OPENVMS
OFFERS AND NOT THE REBOOT MINDSET OF WINDOZE AND LINUS USERS.
Post by Andrew Brehm
But OpenVMS will, so they say, support both some HPE and Dell hardware
and some hypervisors, and all the supported hypervisors are available as
free editions as well as paid.
While VirtualBox is not a production environment VMM, both KVM and
vSphere are and all three can be free.
You can then install OpenVMS on your HPE hardware or install a free ESXi
on it or a free Linux with KVM and then OpenVMS. Where's the problem?
DOWNTIME ABOVE WAS THE FIRST.

2ND PROBLEM - JOINING THE LINUX PATCH OF THE DAY CLUB

HERE IS THE OPENVMS CERT COUNTS AS OF 2018 COMPARE THEM WITH OTHER OSs - SEE THE PROBLEM?

HP » Openvms : Vulnerability Statistics
Vulnerabilities (19)
Vulnerability Trends Over Time
Year # of Vulnerabilities DoS Code Execution Overflow Memory Corruption Sql Injection XSS Directory Traversal Http Response Splitting Bypass something Gain Information Gain Privileges CSRF File Inclusion # of exploits
2005 2 1
2006 1 1
2007 6 4 1
2008 2 1 1 2
2010 3 1 2 2
2012 4 3 1
2018 1 1
Total 19 11 3 2 5
% Of All 57.9 0.0 15.8 0.0 0.0 0.0 0.0 0.0 0.0 10.5 26.3 0.0 0.0
Post by Andrew Brehm
--
Andrew Brehm
Andrew Brehm
2020-12-31 17:07:38 UTC
Permalink
Post by Michael C
Post by Andrew Brehm
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Where I work every bare metal server is a hassle. VMs deploy
automatically and there is no need to worry about the hardware. If the
hardware fails, VMs are moved to or restarted on different hardware. An
actual hypervisor _requirement_ would be perfect for us as it would cut
down on support costs and time.
1ST PROBLEM - RESTARTED
THERE ARE CUSTOMERS, MOST I WOULD THINK, WHO WANT 24/7 UPTIME THAT OPENVMS
OFFERS AND NOT THE REBOOT MINDSET OF WINDOZE AND LINUS USERS.
And you believe restarting a bare metal OpenVMS instance on another
server after a hardware failure would somehow solve that problem?

With vSphere you can move a running OpenVMS instance to another physical
server in case you notice the hardware problem coming. With a bare metal
instance you are limited to the situation you seem to think is a
particular problem of using a hypervisor.
Post by Michael C
Post by Andrew Brehm
But OpenVMS will, so they say, support both some HPE and Dell hardware
and some hypervisors, and all the supported hypervisors are available as
free editions as well as paid.
While VirtualBox is not a production environment VMM, both KVM and
vSphere are and all three can be free.
You can then install OpenVMS on your HPE hardware or install a free ESXi
on it or a free Linux with KVM and then OpenVMS. Where's the problem?
DOWNTIME ABOVE WAS THE FIRST.
The above was a win for the hypervisor. A bare metal instance would not
survive hardware failure, a VM can.
Post by Michael C
2ND PROBLEM - JOINING THE LINUX PATCH OF THE DAY CLUB
HERE IS THE OPENVMS CERT COUNTS AS OF 2018 COMPARE THEM WITH OTHER OSs - SEE THE PROBLEM?
No, I don't see the problem. How would Linux patches affect OpenVMS
running in a virtualised environment?

I'm not sure you understand virtualisation correctly.
--
Andrew Brehm
D W
2020-12-31 18:50:54 UTC
Permalink
Post by Andrew Brehm
Post by Michael C
Post by Andrew Brehm
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Where I work every bare metal server is a hassle. VMs deploy
automatically and there is no need to worry about the hardware. If the
hardware fails, VMs are moved to or restarted on different hardware. An
actual hypervisor _requirement_ would be perfect for us as it would cut
down on support costs and time.
1ST PROBLEM - RESTARTED
THERE ARE CUSTOMERS, MOST I WOULD THINK, WHO WANT 24/7 UPTIME THAT OPENVMS
OFFERS AND NOT THE REBOOT MINDSET OF WINDOZE AND LINUS USERS.
And you believe restarting a bare metal OpenVMS instance on another
server after a hardware failure would somehow solve that problem?
With vSphere you can move a running OpenVMS instance to another physical
server in case you notice the hardware problem coming. With a bare metal
instance you are limited to the situation you seem to think is a
particular problem of using a hypervisor.
Post by Michael C
Post by Andrew Brehm
But OpenVMS will, so they say, support both some HPE and Dell hardware
and some hypervisors, and all the supported hypervisors are available as
free editions as well as paid.
While VirtualBox is not a production environment VMM, both KVM and
vSphere are and all three can be free.
You can then install OpenVMS on your HPE hardware or install a free ESXi
on it or a free Linux with KVM and then OpenVMS. Where's the problem?
DOWNTIME ABOVE WAS THE FIRST.
The above was a win for the hypervisor. A bare metal instance would not
survive hardware failure, a VM can.
Post by Michael C
2ND PROBLEM - JOINING THE LINUX PATCH OF THE DAY CLUB
HERE IS THE OPENVMS CERT COUNTS AS OF 2018 COMPARE THEM WITH OTHER OSs - SEE THE PROBLEM?
No, I don't see the problem. How would Linux patches affect OpenVMS
running in a virtualised environment?
I'm not sure you understand virtualisation correctly.
--
Andrew Brehm
I understand VMs just fine. The linux kernal is inherently flawed as is windoze.

As for hardware failures I would I think OpenVMS clustering is a far superior solution than the VM solution.
Snowshoe
2020-12-31 22:35:45 UTC
Permalink
Post by Andrew Brehm
Post by Michael C
2ND PROBLEM - JOINING THE LINUX PATCH OF THE DAY CLUB
HERE IS THE OPENVMS CERT COUNTS AS OF 2018 COMPARE THEM WITH OTHER OSs - SEE THE PROBLEM?
No, I don't see the problem. How would Linux patches affect OpenVMS
running in a virtualised environment?
I'm not sure you understand virtualisation correctly.
Is there such a thing as an OS-less VM hypervisor? More specifically, a
hypervisor which is its own OS in a way, you boot it directly (not
booting Linux/Windoze then starting the hypervisor) and pretty much the
only thing you can do once booted is starting virtual machines.

I suspect this is the case but I am not familiar with hypervisors.
I also suspect that many/most/all are really Linux under the hood.
Stephen Hoffman
2020-12-31 23:00:33 UTC
Permalink
Post by Snowshoe
Is there such a thing as an OS-less VM hypervisor?
Nope.

The question is whether the hypervisor is built on its own pieces and
parts, or is built with and uses an existing operating system; Linux or
BSD or Windows or otherwise.

Some hypervisors are "thinner" than others, but all must boot and
perform I/O and related tasks, which makes the hypervisor an operating
system.

How much else might be included, varies.

Some hypervisors can abstract and can boot themselves as guests (e.g.
IBM VM), and some (e.g. HPIVM) cannot. Being able to boot a hypervisor
as a guest is handy for testing new versions of the hypervisor, among
other uses.

VMware has been migrating off Linux, per their statements: "VMware has
been actively working on a multi-year project with the goal of removing
vmklinux from vSphere, and hopes to accomplish this in an upcoming
major release." That from earlier in 2020. What they're migrating to?
Donno. Could well be custom, or could be based on BSD, or otherwise.
Post by Snowshoe
More specifically, a hypervisor which is its own OS in a way, you boot
it directly (not booting Linux/Windoze then starting the hypervisor)
and pretty much the only thing you can do once booted is starting
virtual machines.
There's less of a difference there than you might think, outside of
cases where the user is expecting to use both the operating system
booted directly and natively—say, macOS—and using VMware Fusion or
Parallels to boot Windows or Linux. Most folks running servers boot to
the hypervisor, load one or more guests potentially including other or
newer versions of hypervisors as guests, and don't operate their own
apps co-resident with but independent from the hypervisor. Folks
running hypervisors on clients tend to be more of a mixed bag.
Post by Snowshoe
I suspect this is the case but I am not familiar with hypervisors.
I also suspect that many/most/all are really Linux under the hood.
BSD avoids licensing issues, and there's been a fair amount of work
going into bhyve. macOS has its own hypervisor framework. Etc.

But for the folks that don't want to use a hypervisor, contact the
folks at VSI and work with them to ensure your preferred x86-64
platform is supported for native boot without a hypervisor. Or learn to
love hypervisors, like many of VSI's customers already do.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2021-01-01 01:01:02 UTC
Permalink
Post by Snowshoe
Post by Andrew Brehm
Post by Michael C
2ND PROBLEM - JOINING THE LINUX PATCH OF THE DAY CLUB
HERE IS THE OPENVMS CERT COUNTS AS OF 2018 COMPARE THEM WITH OTHER
OSs - SEE THE PROBLEM?
No, I don't see the problem. How would Linux patches affect OpenVMS
running in a virtualised environment?
I'm not sure you understand virtualisation correctly.
Is there such a thing as an OS-less VM hypervisor? More specifically, a
hypervisor which is its own OS in a way, you boot it directly (not
booting Linux/Windoze then starting the hypervisor) and pretty much the
only thing you can do once booted is starting virtual machines.
That is what a bare-metal hypervisor does.
Post by Snowshoe
I suspect this is the case but I am not familiar with hypervisors.
I also suspect that many/most/all are really Linux under the hood.
The most widely bare-metal hypervisor VMWare ESXi has its own
kernel, but it does come with a bunch of userland
Linux stuff and a compatibility layer that allow using
Linux device drivers besides native device drivers.

Arne
Scott Dorsey
2021-01-01 15:27:55 UTC
Permalink
Post by Snowshoe
Is there such a thing as an OS-less VM hypervisor? More specifically, a
hypervisor which is its own OS in a way, you boot it directly (not
booting Linux/Windoze then starting the hypervisor) and pretty much the
only thing you can do once booted is starting virtual machines.
Yes. This is rather common actually. VM/370 is of course the great
grandaddy.

But once you get to this you then start getting arguments about what really
constitutes and operating system.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Simon Clubley
2021-01-04 13:16:50 UTC
Permalink
Post by Scott Dorsey
Post by Snowshoe
Is there such a thing as an OS-less VM hypervisor? More specifically, a
hypervisor which is its own OS in a way, you boot it directly (not
booting Linux/Windoze then starting the hypervisor) and pretty much the
only thing you can do once booted is starting virtual machines.
Yes. This is rather common actually. VM/370 is of course the great
grandaddy.
I would still regard VM/370 as being an OS, just one with an unusual and
highly specific set of capabilities.
Post by Scott Dorsey
But once you get to this you then start getting arguments about what really
constitutes and operating system.
Are MS-DOS or RT-11 operating systems ? I would say yes, because they
provide services to the applications running on top of them. Likewise,
I would say that VM/370 is still an OS because it provides services to
the operating systems running on top of it.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
David Wade
2021-01-04 19:51:26 UTC
Permalink
Post by Simon Clubley
Post by Scott Dorsey
Post by Snowshoe
Is there such a thing as an OS-less VM hypervisor? More specifically, a
hypervisor which is its own OS in a way, you boot it directly (not
booting Linux/Windoze then starting the hypervisor) and pretty much the
only thing you can do once booted is starting virtual machines.
Yes. This is rather common actually. VM/370 is of course the great
grandaddy.
I would still regard VM/370 as being an OS, just one with an unusual and
highly specific set of capabilities.
When IBM announced VM/370 they included two operation systems.

There is CP which is sometimes called VM and which is almost a pure
Hypervisor. Its job is to provide virtual machines which look as much as
possible as like real S/370's.

Then there is CMS which is what users normally IPL into their virtual
machines. CMS is a very simple single user OS about as complex as MS DOS.

There is a shared spool that is usde for reading, printing and punching.
Post by Simon Clubley
Post by Scott Dorsey
But once you get to this you then start getting arguments about what really
constitutes and operating system.
Are MS-DOS or RT-11 operating systems ? I would say yes, because they
provide services to the applications running on top of them. Likewise,
I would say that VM/370 is still an OS because it provides services to
the operating systems running on top of it.
I would say VM is, in modern parlance a Hypervisor.
Post by Simon Clubley
Simon.
Dave
G4UGM
Andrew Brehm
2021-01-08 20:00:23 UTC
Permalink
Post by Snowshoe
Post by Andrew Brehm
Post by Michael C
2ND PROBLEM - JOINING THE LINUX PATCH OF THE DAY CLUB
HERE IS THE OPENVMS CERT COUNTS AS OF 2018 COMPARE THEM WITH OTHER
OSs - SEE THE PROBLEM?
No, I don't see the problem. How would Linux patches affect OpenVMS
running in a virtualised environment?
I'm not sure you understand virtualisation correctly.
Is there such a thing as an OS-less VM hypervisor? More specifically, a
hypervisor which is its own OS in a way, you boot it directly (not
booting Linux/Windoze then starting the hypervisor) and pretty much the
only thing you can do once booted is starting virtual machines.
Yes.

VMware vSphere works like this, it's a type 1 hypervisor (runs directly
on the hardware and not on another OS).

Technically Hyper-V and Xen are also type 1 hypervisors but they both
use a VM running Windows or Linux or NetBSD respectively for driver support.

Oracle's and IBM's hypervisors for SPARC and POWER also run directly on
the metal.
Post by Snowshoe
I suspect this is the case but I am not familiar with hypervisors.
I also suspect that many/most/all are really Linux under the hood.
KVM runs on Linux, Xen uses Linux or NetBSD for drivers.

Hyper-V uses Windows for drivers.

vSphere runs directly on the metal and has its own driver architecture.

Bhyve runs on FreeBSD.
--
Andrew Brehm
Dave Froble
2021-01-01 01:16:40 UTC
Permalink
Post by D W
Post by Andrew Brehm
Post by Michael C
Post by Andrew Brehm
Post by s***@gmail.com
This adds more cost. Why can't it run by itself on x86?
Or am I misunderstanding that you do not have to buy vmware or some other
VM to run it?
But I also don't see your point. In my experience bare metal
requirements cost more money because you need to buy and support/install
extra hardware for the platform. With a hypervisor you can just add
OpenVMS instances on your existing hardware.
Where I work every bare metal server is a hassle. VMs deploy
automatically and there is no need to worry about the hardware. If the
hardware fails, VMs are moved to or restarted on different hardware. An
actual hypervisor _requirement_ would be perfect for us as it would cut
down on support costs and time.
1ST PROBLEM - RESTARTED
THERE ARE CUSTOMERS, MOST I WOULD THINK, WHO WANT 24/7 UPTIME THAT OPENVMS
OFFERS AND NOT THE REBOOT MINDSET OF WINDOZE AND LINUS USERS.
And you believe restarting a bare metal OpenVMS instance on another
server after a hardware failure would somehow solve that problem?
With vSphere you can move a running OpenVMS instance to another physical
server in case you notice the hardware problem coming. With a bare metal
instance you are limited to the situation you seem to think is a
particular problem of using a hypervisor.
Post by Michael C
Post by Andrew Brehm
But OpenVMS will, so they say, support both some HPE and Dell hardware
and some hypervisors, and all the supported hypervisors are available as
free editions as well as paid.
While VirtualBox is not a production environment VMM, both KVM and
vSphere are and all three can be free.
You can then install OpenVMS on your HPE hardware or install a free ESXi
on it or a free Linux with KVM and then OpenVMS. Where's the problem?
DOWNTIME ABOVE WAS THE FIRST.
The above was a win for the hypervisor. A bare metal instance would not
survive hardware failure, a VM can.
Post by Michael C
2ND PROBLEM - JOINING THE LINUX PATCH OF THE DAY CLUB
HERE IS THE OPENVMS CERT COUNTS AS OF 2018 COMPARE THEM WITH OTHER OSs - SEE THE PROBLEM?
No, I don't see the problem. How would Linux patches affect OpenVMS
running in a virtualised environment?
I'm not sure you understand virtualisation correctly.
--
Andrew Brehm
I understand VMs just fine. The linux kernal is inherently flawed as is windoze.
As for hardware failures I would I think OpenVMS clustering is a far superior solution than the VM solution.
Perhaps the VMS kernal also has some flaws?

Might VMS cluster instances running on VMs be an even better solution?

Doesn't have to be either or ....
--
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-01-01 01:17:35 UTC
Permalink
On 12/31/2020 1:50 PM, D W wrote:

Hey Bob, how many email addresses do you use?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John Dallman
1970-01-01 00:00:00 UTC
Permalink
Post by D W
As for hardware failures I would I think OpenVMS clustering is a
far superior solution than the VM solution.
Yes, in some ways. But the VM solution is familiar to most companies' IT
departments, and VMS clustering is not.

Also, modern x86-64 hardware is /fast/, and a single VMS instance should
be able to do the work of several Alpha boxes, or a couple of Itaniums.
In the common situation where VMS usage has been shrinking as a
proportion of a company's IT, replacing several old machines with a
single VMS VM will be attractive to management.

John
Phillip Helbig (undress to reply)
2021-01-01 12:17:20 UTC
Permalink
Post by John Dallman
Post by D W
As for hardware failures I would I think OpenVMS clustering is a
far superior solution than the VM solution.
Yes, in some ways. But the VM solution is familiar to most companies' IT
departments, and VMS clustering is not.
My guess is that almost all existing VMS customers use clustering, and
that almost all future VSI customers are current VMS customers.
Post by John Dallman
Also, modern x86-64 hardware is /fast/, and a single VMS instance should
be able to do the work of several Alpha boxes, or a couple of Itaniums.
But increased power is only one of many reasons for clustering.
Post by John Dallman
In the common situation where VMS usage has been shrinking as a
proportion of a company's IT, replacing several old machines with a
single VMS VM will be attractive to management.
Unless they need a solution where the application can survive the loss
of a data centre.
Arne Vajhøj
2021-01-01 15:13:24 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by John Dallman
Post by D W
As for hardware failures I would I think OpenVMS clustering is a
far superior solution than the VM solution.
Yes, in some ways. But the VM solution is familiar to most companies' IT
departments, and VMS clustering is not.
My guess is that almost all existing VMS customers use clustering,
I doubt that.

There must be a lot standalone Alpha and Itanium systems out there.
Post by Phillip Helbig (undress to reply)
and
that almost all future VSI customers are current VMS customers.
Short term: probably yes.

Long term: *hopefully* not.
Post by Phillip Helbig (undress to reply)
Post by John Dallman
Also, modern x86-64 hardware is /fast/, and a single VMS instance should
be able to do the work of several Alpha boxes, or a couple of Itaniums.
But increased power is only one of many reasons for clustering.
True.
Post by Phillip Helbig (undress to reply)
Post by John Dallman
In the common situation where VMS usage has been shrinking as a
proportion of a company's IT, replacing several old machines with a
single VMS VM will be attractive to management.
Unless they need a solution where the application can survive the loss
of a data centre.
That really has not much to do with VM vs non-VM or VMS vs non-VMS.

Data center redundancy is a common concept.

Arne
Dave Froble
2021-01-01 16:31:25 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Unless they need a solution where the application can survive the loss
of a data centre.
That really has not much to do with VM vs non-VM or VMS vs non-VMS.
Data center redundancy is a common concept.
Thinking a bit more about this ....

I have no experience using VMs, other than a bit of learning a few
months back. Thus I'm not real familiar with moving VM instances.

But what about a situation where flood waters are rising at one data
center? How much better would it be to be able to move VM instances to
an alternate data center vs just shutting down the local data center and
letting existing VMS instances at alternate data centers continue to run?

Seems to me to not be much of an advantage, but what do I know?
--
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-01-01 20:09:09 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Unless they need a solution where the application can survive the loss
of a data centre.
That really has not much to do with VM vs non-VM or VMS vs non-VMS.
Data center redundancy is a common concept.
Thinking a bit more about this ....
I have no experience using VMs, other than a bit of learning a few
months back.  Thus I'm not real familiar with moving VM instances.
But what about a situation where flood waters are rising at one data
center?  How much better would it be to be able to move VM instances to
an alternate data center vs just shutting down the local data center and
letting existing VMS instances at alternate data centers continue to run?
Seems to me to not be much of an advantage, but what do I know?
I believe VMWare's ability to spin up a VM on a different ESXi server
is mostly an "within data center" thing. If you have 3 ESXi servers
and one of them get a hardware problem then VMWare can move the VM"s
to the remaining two.

In case of a total data center meltdown, then I believe something
else is needed. But even though OS clustering is still somewhat rare
then application clustering is very common.

Arne
John H. Reinhardt
2021-01-02 00:37:17 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Unless they need a solution where the application can survive the loss
of a data centre.
That really has not much to do with VM vs non-VM or VMS vs non-VMS.
Data center redundancy is a common concept.
Thinking a bit more about this ....
I have no experience using VMs, other than a bit of learning a few months back.  Thus I'm not real familiar with moving VM instances.
But what about a situation where flood waters are rising at one data center?  How much better would it be to be able to move VM instances to an alternate data center vs just shutting down the local data center and letting existing VMS instances at alternate data centers continue to run?
Seems to me to not be much of an advantage, but what do I know?
I believe VMWare's ability to spin up a VM on a different ESXi server
is mostly an "within data center" thing. If you have 3 ESXi servers
and one of them get a hardware problem then VMWare can move the VM"s
to the remaining two.
In case of a total data center meltdown, then I believe something
else is needed. But even though OS clustering is still somewhat rare
then application clustering is very common.
Arne
While not a DR thing, the company I work for has moved data centers twice in "recent" times (once since I started 3 years ago) by just installing VMWare hosts in the new datacenter and migrating the guest VM to the new place via networks. It wasn't instantaneous, so in the case of flood waters rising you would need a few hours notice, but moves were made from Milwaukee to Salt Lake City and later on SLC to Plano, Texas in less then 8 hours for 30 some virtual machines. Yes, setup is required also so it would have to be a pre-planned contingency apposed to a "Oh, crap we gotta move someplace NOW!" situation. But no hardware was physically moved. In one case it was timed for when the old hardware was going off lease so incorporated a hardware upgrade at the same time.

We have also done the hardware failure scenario within a datacenter and, in that case, the failover time is milliseconds and Oracle (and therefore our users/customers), in our case never knew the VM moved hosts. For performance reasons VShpere can also move VMs around to lesser loaded hosts as required. Also without Oracle or the users ever knowing.
--
John H. Reinhardt
David Wade
2021-01-02 15:31:42 UTC
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Unless they need a solution where the application can survive the loss
of a data centre.
That really has not much to do with VM vs non-VM or VMS vs non-VMS.
Data center redundancy is a common concept.
Thinking a bit more about this ....
I have no experience using VMs, other than a bit of learning a few
months back.  Thus I'm not real familiar with moving VM instances.
But what about a situation where flood waters are rising at one data
center?  How much better would it be to be able to move VM instances
to an alternate data center vs just shutting down the local data
center and letting existing VMS instances at alternate data centers
continue to run?
Seems to me to not be much of an advantage, but what do I know?
I believe VMWare's ability to spin up a VM on a different ESXi server
is mostly an "within data center" thing. If you have 3 ESXi servers
and one of them get a hardware problem then VMWare can move the VM"s
to the remaining two.
There are tools to allow you to do spilt data centre Disaster Recovery.
Post by Arne Vajhøj
In case of a total data center meltdown, then I believe something
else is needed. But even though OS clustering is still somewhat rare
then application clustering is very common.
Well you need to have multiple copies of the data. So for mid-range to
high end sites you can replicate at the SAN level. For smaller sites
there are solutions that use VMWARE service VMs to replicate the data.

You can replicate to alternate sites, or to an off-site cloud based data
centre.

There are is also Site Recovery Manager which allows scripting in either
environment.
Post by Arne Vajhøj
Arne
Dave
Stephen Hoffman
2021-01-02 16:26:33 UTC
Permalink
Post by Arne Vajhøj
I believe VMWare's ability to spin up a VM on a different ESXi server
is mostly an "within data center" thing. If you have 3 ESXi servers and
one of them get a hardware problem then VMWare can move the VM"s to the
remaining two.
Per the VSI software product description, an OpenVMS Cluster maximum
spam is limited to a round-trip less than 6 milliseconds, and that span
only with VSI assistance.
https://vmssoftware.com/docs/VSI_Clusters_SPD.pdf

VMware vMotion migration permits guest migrations with a maximum
distance of 100 milliseconds' round-trip, per the VMware product
requirements. https://www.vmware.com/products/vsphere/vmotion.html

Put differently, VMware vMotion supported cabling-length distances
substantially exceed those of supported OpenVMS cluster configurations.

For those that wish to scrape the mental rust off of these speed and
distance calculations, or that just want some semi-related humor:
http://ibiblio.org/harris/500milemail.html
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2021-01-01 19:38:20 UTC
Permalink
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Post by John Dallman
Post by D W
As for hardware failures I would I think OpenVMS clustering is a
far superior solution than the VM solution.
Yes, in some ways. But the VM solution is familiar to most companies' IT
departments, and VMS clustering is not.
My guess is that almost all existing VMS customers use clustering,
I doubt that.
There must be a lot standalone Alpha and Itanium systems out there.
I'm with Arne here. Hardware has become way faster the last 20 years
so that is not a reason to cluster anymore. Hardare has also got more
reliable and stable. Storage is more on SAN's, so it is easy to start
up a backup system (if you can take the downtime).

And the cost and added complexity of VMS-Clusters works against it.

A lot of software, such as Rdb with its single-node optimizations,
are faster on non-clustred systems.
Post by Arne Vajhøj
Post by Phillip Helbig (undress to reply)
Unless they need a solution where the application can survive the loss
of a data centre.
With SAN, you can have HBS between datacenters without running VMS-Cluster.
Just shadow multiple disks from different SAN systems at different sites.
Or let the SAN systems hande the mirrowing of your data.
Simon Clubley
2021-01-04 13:23:45 UTC
Permalink
Post by Jan-Erik Söderholm
With SAN, you can have HBS between datacenters without running VMS-Cluster.
Just shadow multiple disks from different SAN systems at different sites.
Or let the SAN systems hande the mirrowing of your data.
That takes care of the data.

What about the coordination between application and operating system
instances at different sites so that another one picks up the load after
the original instance fails ?

How is the original instance blocked from resuming operations if it
recovers so that you don't have two instances of the application or
operating system trying to update the same data at the same time in
an uncoordinated way ?

In other words, what is the SAN version of the DLM and the VMS clustering
protocols ?

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-01-04 13:41:43 UTC
Permalink
Post by Simon Clubley
Post by Jan-Erik Söderholm
With SAN, you can have HBS between datacenters without running VMS-Cluster.
Just shadow multiple disks from different SAN systems at different sites.
Or let the SAN systems hande the mirrowing of your data.
That takes care of the data.
What about the coordination between application and operating system
instances at different sites so that another one picks up the load after
the original instance fails ?
How is the original instance blocked from resuming operations if it
recovers so that you don't have two instances of the application or
operating system trying to update the same data at the same time in
an uncoordinated way ?
In other words, what is the SAN version of the DLM and the VMS clustering
protocols ?
That is not the job of the SAN.

But application failover is a pretty universal feature also outside
of VMS, Implementation techniques vary a lot.

Arne
Simon Clubley
2021-01-04 18:17:29 UTC
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
Post by Jan-Erik Söderholm
With SAN, you can have HBS between datacenters without running VMS-Cluster.
Just shadow multiple disks from different SAN systems at different sites.
Or let the SAN systems hande the mirrowing of your data.
That takes care of the data.
What about the coordination between application and operating system
instances at different sites so that another one picks up the load after
the original instance fails ?
How is the original instance blocked from resuming operations if it
recovers so that you don't have two instances of the application or
operating system trying to update the same data at the same time in
an uncoordinated way ?
In other words, what is the SAN version of the DLM and the VMS clustering
protocols ?
That is not the job of the SAN.
That's what I thought but I wasn't 100% sure just in case something had
come along without me hearing about it.
Post by Arne Vajhøj
But application failover is a pretty universal feature also outside
of VMS, Implementation techniques vary a lot.
So it's the same as always in that you also need the additional supporting
infrastructure to provide what you get as standard with VMS clustering,
including being able to detect when a node has only temporarily failed
(in order to prevent everything that comes with that situation) when that
temporarily failed node comes back online.

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-01-04 18:37:54 UTC
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Post by Jan-Erik Söderholm
With SAN, you can have HBS between datacenters without running VMS-Cluster.
Just shadow multiple disks from different SAN systems at different sites.
Or let the SAN systems hande the mirrowing of your data.
That takes care of the data.
What about the coordination between application and operating system
instances at different sites so that another one picks up the load after
the original instance fails ?
How is the original instance blocked from resuming operations if it
recovers so that you don't have two instances of the application or
operating system trying to update the same data at the same time in
an uncoordinated way ?
In other words, what is the SAN version of the DLM and the VMS clustering
protocols ?
That is not the job of the SAN.
That's what I thought but I wasn't 100% sure just in case something had
come along without me hearing about it.
Post by Arne Vajhøj
But application failover is a pretty universal feature also outside
of VMS, Implementation techniques vary a lot.
So it's the same as always in that you also need the additional supporting
infrastructure to provide what you get as standard with VMS clustering,
Not really.

It is a typical feature of the software you are running.

Your database, application server, web server, cache
server or whatever server cluster provides it.

Arne
Stephen Hoffman
2021-01-04 20:42:32 UTC
Permalink
Post by Simon Clubley
So it's the same as always in that you also need the additional
supporting infrastructure to provide what you get as standard with VMS
clustering, including being able to detect when a node has only
temporarily failed (in order to prevent everything that comes with that
situation) when that temporarily failed node comes back online.
I did a presentation on this topic way back 'round Y2K at a DECUS symposium.

It's rather more involved than the lock manager—electing a primary is a
piece of this, certainly.

LAN failover via IP and formerly DECnet, DNS and formerly DECdns,
application-level routers, host-based RAID-1 (HBVS), and various other
pieces can and usually are involved.

OpenVMS isn't all that good at 802.3ad link aggregation, either. But I digress.

Not much has changed with OpenVMS and clustering, which is both good and bad.

Bad: having done this more than a few times, OpenVMS DLM is a pain in
the arse to use, and I know how to use it for this and related
requirements.

There's still too little doc here. What doc is available is scattered
across a half-dozen manuals.

Things have changed on other platforms in the ensuing decades, though.

Apache ZooKeeper (variously with Curator) is in use, Paxos sometimes
gets mentioned around this, Linux has a cluster DLM, and approaches
such as Mosquitto try to avoid even having a primary. Sometimes LDAP
and Kerberos for authentication, too.

For those with an interest in this topic area:
https://www.coursera.org/lecture/cloud-computing-2/1-3-election-in-chubby-and-zookeeper-IDKhR

https://openreplica.org
https://en.wikipedia.org/wiki/Apache_ZooKeeper
https://en.wikipedia.org/wiki/Apache_Spark
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/high_availability_add-on_overview/ch-dlm

etc.

TL;DR: OpenVMS DLM is still nice albeit in need of better abstractions,
but DLM is no longer a particularly distinguishing feature.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2021-01-05 13:31:25 UTC
Permalink
Post by Stephen Hoffman
Post by Simon Clubley
So it's the same as always in that you also need the additional
supporting infrastructure to provide what you get as standard with VMS
clustering, including being able to detect when a node has only
temporarily failed (in order to prevent everything that comes with that
situation) when that temporarily failed node comes back online.
I did a presentation on this topic way back 'round Y2K at a DECUS symposium.
It's rather more involved than the lock manager?electing a primary is a
piece of this, certainly.
I know about at least some of the alternatives, especially ZooKeeper
and the components that use it.

My point was that I was surprised to see Jan-Erik suggest that a SAN
distributed over multiple sites could by itself be an alternative to
a VMS cluster because I couldn't see how that could be possible without
all the other bits that VMS clustering provides and which are required.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Jan-Erik Söderholm
2021-01-05 14:33:27 UTC
Permalink
Post by Simon Clubley
Post by Stephen Hoffman
Post by Simon Clubley
So it's the same as always in that you also need the additional
supporting infrastructure to provide what you get as standard with VMS
clustering, including being able to detect when a node has only
temporarily failed (in order to prevent everything that comes with that
situation) when that temporarily failed node comes back online.
I did a presentation on this topic way back 'round Y2K at a DECUS symposium.
It's rather more involved than the lock manager?electing a primary is a
piece of this, certainly.
I know about at least some of the alternatives, especially ZooKeeper
and the components that use it.
My point was that I was surprised to see Jan-Erik suggest that a SAN
distributed over multiple sites could by itself be an alternative to
a VMS cluster...
Depends on *why* you use and run a VMS-cluster. Could just be of old
habits and that no one has looked at the systems since a long time.

But of course, if you use some of the unique features, it is harder
to just replace it.
Post by Simon Clubley
because I couldn't see how that could be possible without
all the other bits that VMS clustering provides and which are required.
Yes, a VMS-cluster needs a lot of bits and pieces just to run in itself.
That does not mean that all application today needs the same features.
Not even an application that "used" a cluster 20-30 years ago.
Post by Simon Clubley
Simon.
Dave Froble
2021-01-05 19:52:45 UTC
Permalink
Post by Jan-Erik Söderholm
Yes, a VMS-cluster needs a lot of bits and pieces just to run in itself.
That does not mean that all application today needs the same features.
Not even an application that "used" a cluster 20-30 years ago.
When first introduced VMS cluster was to some extent a method to add
compute resources, just as adding disk drives added storage resources.
Not exclusively, but a major thing, then. Later other reasons to use
VMS cluster rose in significance, and as compute capabilities got
better, the "add compute resources" became less important.

The reasons to use VMS cluster has changed over time, and is still changing.

I had a customer with a room full of VAX 11/780 systems, six I believe,
in a VMS cluster configuration. Being in one room, disaster tolerance
was obviously not a desired configuration. That was then.
--
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-01-05 20:08:58 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Yes, a VMS-cluster needs a lot of bits and pieces just to run in itself.
That does not mean that all application today needs the same features.
Not even an application that "used" a cluster 20-30 years ago.
When first introduced VMS cluster was to some extent a method to add
compute resources, just as adding disk drives added storage resources.
Not exclusively, but a major thing, then. Later other reasons to use
VMS cluster rose in significance, and as compute capabilities got
better, the "add compute resources" became less important.
The reasons to use VMS cluster has changed over time, and is still changing.
I had a customer with a room full of VAX 11/780 systems, six I believe,
in a VMS cluster configuration. Being in one room, disaster tolerance
was obviously not a desired configuration. That was then.
Off the top of my head: adding resources, disaster tolerance, rolling
upgrades, satellites (yes!). Many reasons. Not all folks will have all
reasons.
Phillip Helbig (undress to reply)
2021-01-05 13:46:33 UTC
Permalink
Post by Simon Clubley
My point was that I was surprised to see Jan-Erik suggest that a SAN
distributed over multiple sites could by itself be an alternative to
a VMS cluster because I couldn't see how that could be possible without
all the other bits that VMS clustering provides and which are required.
It depends on what the cluster is used for.
Dave Froble
2021-01-01 16:23:19 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by John Dallman
Post by D W
As for hardware failures I would I think OpenVMS clustering is a
far superior solution than the VM solution.
Yes, in some ways. But the VM solution is familiar to most companies' IT
departments, and VMS clustering is not.
My guess is that almost all existing VMS customers use clustering, and
that almost all future VSI customers are current VMS customers.
While I have as much actual knowledge of VMS cluster usage as you do, my
suggestion is you might need to re-think you ability to make accurate
guesses.

I will agree, for now, VSI is playing to the installed base.
Post by Phillip Helbig (undress to reply)
Post by John Dallman
Also, modern x86-64 hardware is /fast/, and a single VMS instance should
be able to do the work of several Alpha boxes, or a couple of Itaniums.
But increased power is only one of many reasons for clustering.
Agreed
Post by Phillip Helbig (undress to reply)
Post by John Dallman
In the common situation where VMS usage has been shrinking as a
proportion of a company's IT, replacing several old machines with a
single VMS VM will be attractive to management.
Unless they need a solution where the application can survive the loss
of a data centre.
Yes, this is a strength of VMS clustering.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2021-01-01 17:58:52 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by John Dallman
Post by D W
As for hardware failures I would I think OpenVMS clustering is a far
superior solution than the VM solution.
Yes, in some ways. But the VM solution is familiar to most companies'
IT departments, and VMS clustering is not.
Hypervisors are generally not particularly related to clustering capabilities.

Hypervisors are rather closer to Galaxy in typical OpenVMS
consideration and usage.

Hypervisors are very popular for consolidation, certainly. Much more
efficient use of available hardware, so long as all guests don't spike
together past the available reserve capacity.

Clustering multiple hypervisor guests is possible, but—like clustering
Galaxy instances—quite possibly not the best available approach. And
clustering across hypervisors is little different from clustering
across Galaxy hosts.

Migrating hypervisor guests is popular with some, too—clustering
doesn't have a good match for that, and involves manually transitioning
the host and its file system contents whether standalone or clustered.
Post by Phillip Helbig (undress to reply)
My guess is that almost all existing VMS customers use clustering,
Nope. Not in my experience. Most don't. There are a *lot* of standalone
OpenVMS systems. Far fewer clusters.

Clustering priced itself out of common usage.
Post by Phillip Helbig (undress to reply)
and that almost all future VSI customers are current VMS customers.
Ayup.
Post by Phillip Helbig (undress to reply)
Also, modern x86-64 hardware is /fast/, and a single VMS instance
should be able to do the work of several Alpha boxes, or a couple of
Itaniums.
But increased power is only one of many reasons for clustering.
Ayup. Hardware has not only gotten faster, it's gotten much more
reliable. And much more dense. As has software. Hardware for a given
system load has gotten cheaper, too.

Disaster tolerance is another. Rolling upgrades, too.
Post by Phillip Helbig (undress to reply)
Post by John Dallman
In the common situation where VMS usage has been shrinking as a
proportion of a company's IT, replacing several old machines with a
single VMS VM will be attractive to management.
Unless they need a solution where the application can survive the loss
of a data centre.
Clustering is not the only means to that goal. With OpenVMS x86-64
hosted on AWS, S3 provides cross-region read-after-write consistency,
for instance. Other sites use controller-level local or remote
replication. Some other sites use remote database logging.

And for not the first time, if you want native boot, that's absolutely
planned and something VSI has discussed, and you'll want to coordinate
with VSI to ensure that your preferred x86-64 hardware configurations
are tested and supported.
--
Pure Personal Opinion | HoffmanLabs LLC
Andrew Brehm
2021-01-08 20:02:50 UTC
Permalink
Post by D W
Post by Andrew Brehm
No, I don't see the problem. How would Linux patches affect OpenVMS
running in a virtualised environment?
I'm not sure you understand virtualisation correctly.
--
Andrew Brehm
I understand VMs just fine. The linux kernal is inherently flawed as is windoze.
If you understand just fine, why are you talking about Linux and
Windows? VMware vSphere uses neither. You can also use a BSD-based
hypervisor or Xen using NetBSD for drivers. All these methods keep you
away from Linux and Windows.
Post by D W
As for hardware failures I would I think OpenVMS clustering is a far superior solution than the VM solution.
No. With vSphere you can even run an OS instance on two physical
machines at once. If one of them fails, all those VMs will keep running
on the other metal. There will not be any interruption.

For planned hardware outages, you can migrate running VMs to other hardware.
--
Andrew Brehm
D W
2021-01-11 12:22:16 UTC
Permalink
Post by Andrew Brehm
Post by D W
Post by Andrew Brehm
No, I don't see the problem. How would Linux patches affect OpenVMS
running in a virtualised environment?
I'm not sure you understand virtualisation correctly.
--
Andrew Brehm
I understand VMs just fine. The linux kernal is inherently flawed as is windoze.
If you understand just fine, why are you talking about Linux and
Windows? VMware vSphere uses neither. You can also use a BSD-based
hypervisor or Xen using NetBSD for drivers. All these methods keep you
away from Linux and Windows.
Post by D W
As for hardware failures I would I think OpenVMS clustering is a far superior solution than the VM solution.
No. With vSphere you can even run an OS instance on two physical
machines at once. If one of them fails, all those VMs will keep running
on the other metal. There will not be any interruption.
For planned hardware outages, you can migrate running VMs to other hardware.
--
Andrew Brehm
what makes you think BSD is superior to the linux/windows security risks?
So BSD is completely immune to hacks? No one can ever take over the machine?
Arne Vajhøj
2021-01-11 13:13:37 UTC
Permalink
Post by D W
Post by Andrew Brehm
Post by D W
I understand VMs just fine. The linux kernal is inherently flawed as is windoze.
If you understand just fine, why are you talking about Linux and
Windows? VMware vSphere uses neither. You can also use a BSD-based
hypervisor or Xen using NetBSD for drivers. All these methods keep you
away from Linux and Windows.
what makes you think BSD is superior to the linux/windows security risks?
So BSD is completely immune to hacks? No one can ever take over the machine?
He did not say so.

You said Linux and Windows were flawed.

So he pointed out that there are alternatives including
Free/Net/Open BSD.

Arne
Simon Clubley
2021-01-11 13:31:07 UTC
Permalink
Post by D W
Post by Andrew Brehm
Post by D W
I understand VMs just fine. The linux kernal is inherently flawed as is windoze.
If you understand just fine, why are you talking about Linux and
Windows? VMware vSphere uses neither. You can also use a BSD-based
hypervisor or Xen using NetBSD for drivers. All these methods keep you
away from Linux and Windows.
what makes you think BSD is superior to the linux/windows security risks?
He didn't say that. He said that using one of the BSDs is an option if you
don't want to use Linux.

I would also remind you Bob that Linux has security and isolation features
built into it as standard that VMS is missing and really needs.
Post by D W
So BSD is completely immune to hacks? No one can ever take over the machine?
You really shouldn't go there until VMS has had the same level of security
probing that other operating systems have as you might not like the results
of that probing.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-01-11 13:56:46 UTC
Permalink
Post by Simon Clubley
Post by D W
Post by Andrew Brehm
Post by D W
I understand VMs just fine. The linux kernal is inherently flawed as is windoze.
If you understand just fine, why are you talking about Linux and
Windows? VMware vSphere uses neither. You can also use a BSD-based
hypervisor or Xen using NetBSD for drivers. All these methods keep you
away from Linux and Windows.
what makes you think BSD is superior to the linux/windows security risks?
He didn't say that. He said that using one of the BSDs is an option if you
don't want to use Linux.
I would also remind you Bob that Linux has security and isolation features
built into it as standard that VMS is missing and really needs.
Post by D W
So BSD is completely immune to hacks? No one can ever take over the machine?
You really shouldn't go there until VMS has had the same level of security
probing that other operating systems have as you might not like the results
of that probing.
Perhaps you should differentiate between what has happened in some
instances, and what might happen in others.

Yes, there could be potential flaws in VMS. The key word is
"potential", which is very much not the same as "is". You are ready to
claim that VMS is unsafe, but you don't provide any proof, just innuendo.

Does VMS use some pieces of software that are already proven flawed?
Yes, it does, but those flaws are known, and can be fixed or not used.
But their existence does not prove that there are un-found flaws. It is
possible. There is a vast difference between unknown possible flaws and
known existing flaws.
--
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-01-11 14:07:14 UTC
Permalink
Post by Dave Froble
Post by Simon Clubley
You really shouldn't go there until VMS has had the same level of security
probing that other operating systems have as you might not like the results
of that probing.
Perhaps you should differentiate between what has happened in some
instances, and what might happen in others.
Yes, there could be potential flaws in VMS. The key word is
"potential", which is very much not the same as "is". You are ready to
claim that VMS is unsafe, but you don't provide any proof, just innuendo.
Well David, the one bit of security research I was motivated to do
showed that VAX/VMS (and later Alpha VMS) was wide open for 33 years
provided you could get to the DCL command line.

Next question ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-01-11 19:16:05 UTC
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
You really shouldn't go there until VMS has had the same level of security
probing that other operating systems have as you might not like the results
of that probing.
Perhaps you should differentiate between what has happened in some
instances, and what might happen in others.
Yes, there could be potential flaws in VMS. The key word is
"potential", which is very much not the same as "is". You are ready to
claim that VMS is unsafe, but you don't provide any proof, just innuendo.
Well David, the one bit of security research I was motivated to do
showed that VAX/VMS (and later Alpha VMS) was wide open for 33 years
provided you could get to the DCL command line.
Next question ?
No questions ...

Just because you found a flaw, in no way means that there are other
flaws. Maybe yes, maybe no, but you continue to insist there must be
more flaws. Rather poor logic there ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2021-01-11 19:25:19 UTC
Permalink
Just because you found a flaw, in no way means that there are other flaws.
There are other flaws, David.
Maybe yes, maybe no, but you continue to insist there must be more
flaws. Rather poor logic there ...
When discussing security and integrity of a platform and commonly-used
components are cleartext and ~unauthenticated, we're not off to a good
start.
--
Pure Personal Opinion | HoffmanLabs LLC
D W
2021-01-11 19:20:13 UTC
Permalink
Post by Simon Clubley
Post by D W
Post by Andrew Brehm
Post by D W
I understand VMs just fine. The linux kernal is inherently flawed as is windoze.
If you understand just fine, why are you talking about Linux and
Windows? VMware vSphere uses neither. You can also use a BSD-based
hypervisor or Xen using NetBSD for drivers. All these methods keep you
away from Linux and Windows.
what makes you think BSD is superior to the linux/windows security risks?
He didn't say that. He said that using one of the BSDs is an option if you
don't want to use Linux.
I would also remind you Bob that Linux has security and isolation features
built into it as standard that VMS is missing and really needs.
Post by D W
So BSD is completely immune to hacks? No one can ever take over the machine?
You really shouldn't go there until VMS has had the same level of security
probing that other operating systems have as you might not like the results
of that probing.
Simon.
--
Walking destinations on a map are further away than they appear.
If I am asking as a potential customer of VSI, I should not go there is the answer you would give as a sales rep?

How do you expect VSI to sell OpenVMS solutions with answers like that?
Andrew Brehm
2021-01-11 15:12:44 UTC
Permalink
Post by D W
Post by Andrew Brehm
Post by D W
Post by Andrew Brehm
No, I don't see the problem. How would Linux patches affect OpenVMS
running in a virtualised environment?
I'm not sure you understand virtualisation correctly.
--
Andrew Brehm
I understand VMs just fine. The linux kernal is inherently flawed as is windoze.
If you understand just fine, why are you talking about Linux and
Windows? VMware vSphere uses neither. You can also use a BSD-based
hypervisor or Xen using NetBSD for drivers. All these methods keep you
away from Linux and Windows.
Post by D W
As for hardware failures I would I think OpenVMS clustering is a far superior solution than the VM solution.
No. With vSphere you can even run an OS instance on two physical
machines at once. If one of them fails, all those VMs will keep running
on the other metal. There will not be any interruption.
For planned hardware outages, you can migrate running VMs to other hardware.
--
Andrew Brehm
what makes you think BSD is superior to the linux/windows security risks?
So BSD is completely immune to hacks? No one can ever take over the machine?
Yes, every improvement means perfection. Obviously, when I think that
BSD is more secure than Linux I must mean that BSD is "completely immune
to hacks".

Or did you want to say that while VMS is more secure than every
hypervisor, BSD cannot be more secure than Linux?
--
Andrew Brehm
Stephen Hoffman
2021-01-11 15:45:17 UTC
Permalink
Post by D W
what makes you think BSD is superior to the linux/windows security risks?
So BSD is completely immune to hacks? No one can ever take over the machine?
You have the answer and the configuration you wanted with the planned
native boot support for the production releases, and you don't have to
run BSD or Linux or another a hypervisor if you don't want to.

For security, OpenVMS has had malware—including the classic viruses and
worms—over the years. OpenVMS servers have had breaches.

With 1239 OpenVMS servers visible on the Internet—various of which are
running ancient versions—there's not a big market for botnets nor for
wider disclosures of flaws, which changes how flaws are managed.

On the subject of current usage and old OpenVMS releases, there's an
odd server running today: an OpenVMS V8.3-1H1 box is running on AWS.
(That'd mean Itanium emulation, or AWS Itanium hardware.) Or they're
spoofing OpenVMS.

But back to your utterly adorable trolling efforts: if you don't want a
hypervisor, don't run a hypervisor. Don't want BSD or Linux, don't run
it. Got favorite x86-64 hardware, let VSI know about that.

For BSD, there's the full-disclosure policy, and here are some of the
changes that the OpenBSD team have implemented:
http://www.openbsd.org/security.html OpenVMS is lacking in many of
these areas.

And call back in a year or three about your x86-64 native-boot hardware
requirements, as the OpenVMS production release becomes available, and
as a whole lot can change with hardware between now and then. We could
all be clamoring for Arm by then, after all.
--
Pure Personal Opinion | HoffmanLabs LLC
D W
2021-01-11 19:25:15 UTC
Permalink
Post by Stephen Hoffman
Post by D W
what makes you think BSD is superior to the linux/windows security risks?
So BSD is completely immune to hacks? No one can ever take over the machine?
You have the answer and the configuration you wanted with the planned
native boot support for the production releases, and you don't have to
run BSD or Linux or another a hypervisor if you don't want to.
For security, OpenVMS has had malware—including the classic viruses and
worms—over the years. OpenVMS servers have had breaches.
With 1239 OpenVMS servers visible on the Internet—various of which are
running ancient versions—there's not a big market for botnets nor for
wider disclosures of flaws, which changes how flaws are managed.
On the subject of current usage and old OpenVMS releases, there's an
odd server running today: an OpenVMS V8.3-1H1 box is running on AWS.
(That'd mean Itanium emulation, or AWS Itanium hardware.) Or they're
spoofing OpenVMS.
But back to your utterly adorable trolling efforts: if you don't want a
hypervisor, don't run a hypervisor. Don't want BSD or Linux, don't run
it. Got favorite x86-64 hardware, let VSI know about that.
For BSD, there's the full-disclosure policy, and here are some of the
http://www.openbsd.org/security.html OpenVMS is lacking in many of
these areas.
And call back in a year or three about your x86-64 native-boot hardware
requirements, as the OpenVMS production release becomes available, and
as a whole lot can change with hardware between now and then. We could
all be clamoring for Arm by then, after all.
--
Pure Personal Opinion | HoffmanLabs LLC
I have a potential customer that may want me to set up an OpenVMS web site
with heavy traffic.

I am trying to get questions answered but your answer is I am trolling?

Again how are you going to sell solutions with answers like that?
Arne Vajhøj
2021-01-11 19:54:42 UTC
Permalink
Post by D W
Post by Stephen Hoffman
Post by D W
what makes you think BSD is superior to the linux/windows security risks?
So BSD is completely immune to hacks? No one can ever take over the machine?
You have the answer and the configuration you wanted with the planned
native boot support for the production releases, and you don't have to
run BSD or Linux or another a hypervisor if you don't want to.
For security, OpenVMS has had malware—including the classic viruses and
worms—over the years. OpenVMS servers have had breaches.
I have a potential customer that may want me to set up an OpenVMS web site
with heavy traffic.
I am trying to get questions answered but your answer is I am trolling?
Your questions are pretty generic.

And the approach is a bit backwards. You don't start with the OS - you
start with the application and then you move to servers and then you
move to OS.

And VMS may not end up being a good candidate for OS.

web/proxy-server : definitely not VMS

app/web-server : unlikely VMS - maybe the software is not available, but
even if it is then VMS will not be cost effective

db-server : VMS could be a possibility if you want traditional database
Post by D W
Again how are you going to sell solutions with answers like that?
Well - Hoff does not sell VMS, so ...

Arne
Dave Froble
2021-01-11 23:50:39 UTC
Permalink
Post by Arne Vajhøj
Post by D W
Post by Stephen Hoffman
Post by D W
what makes you think BSD is superior to the linux/windows security risks?
So BSD is completely immune to hacks? No one can ever take over the machine?
You have the answer and the configuration you wanted with the planned
native boot support for the production releases, and you don't have to
run BSD or Linux or another a hypervisor if you don't want to.
For security, OpenVMS has had malware—including the classic viruses and
worms—over the years. OpenVMS servers have had breaches.
I have a potential customer that may want me to set up an OpenVMS web site
with heavy traffic.
I am trying to get questions answered but your answer is I am trolling?
Your questions are pretty generic.
And the approach is a bit backwards. You don't start with the OS - you
start with the application and then you move to servers and then you
move to OS.
And VMS may not end up being a good candidate for OS.
web/proxy-server : definitely not VMS
app/web-server : unlikely VMS - maybe the software is not available, but
even if it is then VMS will not be cost effective
db-server : VMS could be a possibility if you want traditional database
Post by D W
Again how are you going to sell solutions with answers like that?
Well - Hoff does not sell VMS, so ...
Arne
Perhaps the potential customer already has apps on VMS, and wants to
provide web access? If so, then it's a bit much to tell them to look
at other OSs, isn't it?

We are doing precisely this, however, for reasons we don't need to
discuss, we have the VMS systems provide services for the web servers
running on several different platforms including WEENDOZE. Works well
when the web developers have half a clue. Surprising how such can so
easily mis-use the services.

Example, one service provides inventory look-up. It can handle a list
of part numbers. Thousands if desired in one request. One web
developer made thousands of requests, one part number at a time. The
overhead was quite substantial.

Got lots of stories of inept web developers.
--
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-01-12 01:09:51 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by D W
I have a potential customer that may want me to set up an OpenVMS web site
with heavy traffic.
I am trying to get questions answered but your answer is I am trolling?
Your questions are pretty generic.
And the approach is a bit backwards. You don't start with the OS - you
start with the application and then you move to servers and then you
move to OS.
And VMS may not end up being a good candidate for OS.
web/proxy-server : definitely not VMS
app/web-server : unlikely VMS - maybe the software is not available, but
even if it is then VMS will not be cost effective
db-server : VMS could be a possibility if you want traditional database
Post by D W
Again how are you going to sell solutions with answers like that?
Well - Hoff does not sell VMS, so ...
Perhaps the potential customer already has apps on VMS, and wants to
provide web access?  If so, then it's a bit much to tell them to look at
other OSs, isn't it?
We are doing precisely this, however, for reasons we don't need to
discuss, we have the VMS systems provide services for the web servers
running on several different platforms including WEENDOZE.  Works well
when the web developers have half a clue.
That is a common scenario.

And I don't think it is more than a few days since I explicit
listed that in another thread.

But this thread was about high volume web sites. An example
was given with a social media web site.

Those are two very different contexts.
Post by Dave Froble
  Surprising how such can so
easily mis-use the services.
Example, one service provides inventory look-up.  It can handle a list
of part numbers.  Thousands if desired in one request.  One web
developer made thousands of requests, one part number at a time.  The
overhead was quite substantial.
Got lots of stories of inept web developers.
I believe that.

Arne

Loading...