On 2024-04-09, motk <yep@yep.yep> wrote:
> On 9/4/24 11:00, Arne Vajhøj wrote:
>
> > We would see:>
>> ...
>> VMS 9.2-2H41 - added support for VM Foo 17 and VM Bar 3
>> VMS 9.2-2H42 - added support for VM Bar 4 and VM FooBar 7
>
> Just looking at the supported hardware/virtualization environments on
> https://vmssoftware.com/about/v92/ and noting a couple of things:
>
> There's no actual 'supported' list, only 'tested'.
> The latest tested QEMU version is 5.2.0, from 2020.
> The list of 'tested' virt environments is pretty baroque and I wonder
> how it's tested.
>

Interesting. What is worrying from that page is that a recent version
of some VMware products causes VMS to fail during boot. I would really
like to know why that is as this is not something I would have expected
to see.

Simon.

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

On 4/10/2024 8:10 AM, Simon Clubley wrote:
> On 2024-04-09, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 4/9/2024 8:45 AM, Simon Clubley wrote:
>>> On 2024-04-08, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> But I think it would be very problematic with VMS complaining
>>>> over configs that are not known to work.
>>>>
>>>> Because removing that test would require a release.
>>>>
>>>> We would see:
>>>>
>>>> ...
>>>> VMS 9.2-2H41 - added support for VM Foo 17 and VM Bar 3
>>>> VMS 9.2-2H42 - added support for VM Bar 4 and VM FooBar 7
>>>> ..
>>>>
>>>> No thanks.
>>>
>>> It does not have to be a release - it could be a patch.
>>
>> True.
>>
>> But I don't like:
>> ...
>> VMS 9.2-2 with HW patch 41
>> VMS 9.2-2 with HW patch 42
>> ...
>>
>> either.
>>
>
> How many VM solutions do you think there are out there ? :-)
>
> Hint: there isn't 41 of them. :-)

Considering versions - yes there are.

And adding host and versions of that we will probably pass 410.

>>> VMS is used in mission-critical production environments. You should
>>> not be allowed to accidentally boot into an unsupported configuration
>>> without being made _VERY_ aware of that fact.
>>
>> Hopefully those running a mission critical production environment
>> on VMS read about supported configs before moving production to
>> that config and never runs it in anything accidentally
>> booted.
>>
>
> According to some people: "There is no need for anything more safer than
> the C or C++ programming language. You just have to be careful when writing
> your code...". Your comment above is from the same incorrect mindset.
>
> In the real world, people make mistakes, especially in an outsourced
> environment where people cost, not people capability, is the driving
> factor and hence people are not as skilled with VMS as they could be.

People makes mistakes. Especially when it is easy to to make
mistakes.

Bringing the mission critical production VM down.
Accidentally install an unsupported VM in production environment.
Accidentally copy the production environment from the supported
VM to the unsupported VM. Accidentally bring up on the unsupported VM.
Is not a mistake, but a series of mistakes. It is not a seconds/minutes
mess up, but hours/days mess up.

It is good to protect against mistakes, but at some point one need
to stop.

What is the plan to prevent people with privs from by mistake to do:

$ DEL SYS$COMMON:[000000...]*.*;*

?

There is no plan. And I don't think we need a plan for that.

I don't think these weird examples are equivalent to people
messing up array indexes in languages not checking those.

These weird examples are the equivalent of the language
enabling checks by default and allowing developers to
bypass checks by putting an unsafe {} block around it and
then having the developer mistakenly put unsafe {}
around some code where it should not have been.

Arne

On 4/10/2024 9:45 AM, Arne Vajhøj wrote:

> What is the plan to prevent people with privs from by mistake to do:
>
> $ DEL SYS$COMMON:[000000...]*.*;*

Well, since similar has already happened ...

$ De [*...]*.*;*

:-)

I'd guess nothing would stop that.

And it didn't ...

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

On 4/10/2024 8:12 AM, Simon Clubley wrote:
> On 2024-04-09, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> But hasn't the discussion been about the CL stuff? I don't think CL and mission
>> critical co-exist. I'm sure VSI doesn't think that.
>>
>
> No. This is about adding checks to VMS itself.
>
>> As for due diligence, when did that go away? Any reasonable customer would
>> check, and re-check, that they are using supported stuff.
>>
>
> People make mistakes. See my reply to Arne.

And they pay for them, and hopefully learn from them.

You cannot protect from everything.

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

On 2024-04-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 4/10/2024 8:10 AM, Simon Clubley wrote:
>>
>> How many VM solutions do you think there are out there ? :-)
>>
>> Hint: there isn't 41 of them. :-)
>
> Considering versions - yes there are.
>
> And adding host and versions of that we will probably pass 410.
>

Why would you need a new version of VMS whenever a new point release
of the host VM software is released ? The whole point of a VM is to
isolate the OS running under the VM from the underlying hardware/OS.

You test that the VM software is compatible with VMS and then assume
that all future point releases are also compatible. That's the whole
point of a VM.

Simon.

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

Robert A. Brooks schrieb am 08.04.2024 um 18:49:
> On 4/8/2024 8:34 AM, Simon Clubley wrote:
>
>> If there's something VMS needs or a configuration it doesn't support,
>> then that should be probed at boot time and VMS should refuse to continue
>> booting with the reason why been made clear. The bug in this case is that
>> this check is missing from VMS.
>
> That's one way to look at it.
>
> Another way is that we have been quite clear what the requirements are
> to run VMS.
>
> Any variation from that is unsupported.  We recognize that there are
> likely configurations
> that are technically unsupported, but will still likely work.
> Preventing those
> configurations from working is someething we could do, but chose not to.
>
>> The other possibility is that VMS is _supposed_ to work OK in this
>> configuration, but this specific VM setup has been untested by VSI until
>> now. That means there is a bug in the VMS code itself which needs fixing.
>
> We are not claiming support for Proxmox, although that testing has begun.
> Given that it is a KVM-based hypervisor, getting it fully supported
> should not
> be difficult, but we're not there yet.
>
> It is for these reasons that we've been quite conservative about what is
> supported.
>
> We are interested in any feedback we get, but that doesn't mean we're
> going to respond to every
> problem immediately when it's an unsupported configuration.

At the Connect IT Symposium, Thilo Lauer (VSI) yesterday gave an
introduction to Proxmox and demoed an OpenVMS instance running under
Proxmox. Camiel Vanderhoeven also mentioned that official support for
Proxmox as a hypervisor is relatively high on their list, especially due
to the changes at VMware since the takeover by Broadcom.

So - stay tuned...

Hans.

PS: Camiel has been appointed "Chief Architect and Strategist" at VSI
recently. In his new role, he will relief Clair Grant from some of his
responsibilities.

On 4/11/2024 6:39 AM, Hans Bachner wrote:
> PS: Camiel has been appointed "Chief Architect and Strategist" at VSI
> recently. In his new role, he will relief Clair Grant from some of his
> responsibilities.

So he will be the key person for the discussion about what
happen to VMS *after* the x86-64 migration.

Arne

In article <uv8elm$1l1r1$1@dont-email.me>,
Hans Bachner <hans@bachner.priv.at> wrote:
>Robert A. Brooks schrieb am 08.04.2024 um 18:49:
>> On 4/8/2024 8:34 AM, Simon Clubley wrote:
>>
>>> If there's something VMS needs or a configuration it doesn't support,
>>> then that should be probed at boot time and VMS should refuse to continue
>>> booting with the reason why been made clear. The bug in this case is that
>>> this check is missing from VMS.
>>
>> That's one way to look at it.
>>
>> Another way is that we have been quite clear what the requirements are
>> to run VMS.
>>
>> Any variation from that is unsupported.  We recognize that there are
>> likely configurations
>> that are technically unsupported, but will still likely work.
>> Preventing those
>> configurations from working is someething we could do, but chose not to.
>>
>>> The other possibility is that VMS is _supposed_ to work OK in this
>>> configuration, but this specific VM setup has been untested by VSI until
>>> now. That means there is a bug in the VMS code itself which needs fixing.
>>
>> We are not claiming support for Proxmox, although that testing has begun.
>> Given that it is a KVM-based hypervisor, getting it fully supported
>> should not
>> be difficult, but we're not there yet.
>>
>> It is for these reasons that we've been quite conservative about what is
>> supported.
>>
>> We are interested in any feedback we get, but that doesn't mean we're
>> going to respond to every
>> problem immediately when it's an unsupported configuration.
>
>At the Connect IT Symposium, Thilo Lauer (VSI) yesterday gave an
>introduction to Proxmox and demoed an OpenVMS instance running under
>Proxmox. Camiel Vanderhoeven also mentioned that official support for
>Proxmox as a hypervisor is relatively high on their list, especially due
>to the changes at VMware since the takeover by Broadcom.
>
>So - stay tuned...
>
>Hans.
>
>PS: Camiel has been appointed "Chief Architect and Strategist" at VSI
>recently. In his new role, he will relief Clair Grant from some of his
>responsibilities.

Interesting. Personally, I'd really like to see OpenVMS get
official support on Oxide hardware. https://oxide.computer/

- Dan C.

On 2024-04-08 17:30:15 +0000, Simon Clubley said:

> Given that the VMS mindset is supposed to be one of robustness and
> reliability, perhaps the proper approach is to enforce a default refuse
> to boot on unsupposed configuration, but allow an override with a boot
> flag or SYSGEN parameter.

A fondness for arcana, inappropriate defaults, and documented and
ill-documented knobs—many of these defaults and these knobs tracing
back to the fallout arising from compatibility—seemingly became
commonly-accepted practice decades ago.

Put differently, documenting the potential for or incidents of a limit
or a crash or appropriately-trained and experienced staff has long been
viewed as meeting minimal requirements, either via the SPD or via some
other detail or document elsewhere. One of the bootcamp sessions
covering known issues with a supported feature was just surreal, for
instance. There have been other examples. Expectations and assumptions
can all change, too. I know mine have. But that's all fodder for
another time.

> That way, people don't accidentally use an unsupported configuration in
> production use, but you also don't stop people from using an
> unsupported configuration if they choose to do so.

I fixed a whole pile of support calls with diagnostics shown for
unsupported configurations, and fixed even more support calls by
automatically detecting and fixing the most common of the errors.

It's quite correct that unsupported-hardware configurations are
incredibly difficult or ~impossible to detect, but overt
mistakes—configuration detection analogous to that Python script—should
be built in to the OpenVMS console or incorporated into the early
bootstrap. Same for similar detection built into (or shared with) the
installer.

Following another longstanding OpenVMS practice of far too chatty
bootstraps (q.v. inappropriate defaults), adding diagnostics and adding
a hardware configuration display and showing an unsupported
configuration diagnostic as needed there would parallel longstanding
console practices.

I'd probably add the unsupported display into the x86-64 error analysis
tooling or into SHOW CPU or some other diagnostic tooling visible at
run-time, and shown in SDA for crashes. This not to imply error-related
tooling is ever going to be remotely easy to create and maintain on
x86-64.

Architecturally, adding a hardware section into the system or
site-local device configuration database would make sense for this
detection. If somebody wants to mask the unsupported-configuration
error, they can edit their change into the site-local hardware
configuration data. (q.v. arcana)

> However, if you implement this, an impossible to miss message should be
> output on every boot so that the flag is not set and then forgotten
> about.

Identifying everything unsupported is ~impossible given the constraints
OpenVMS operates under. But I wouldn't be concerned about adding some
diagnostics to an already-chatty bootstrap either, given normal OpenVMS
bootstraps and startups are purpose-designed to make that easy to hide
info and easy to ignore. Hardware, too. Default Itanium startups are
just stupidly chatty.

--
Pure Personal Opinion | HoffmanLabs LLC

On Mon, 15 Apr 2024 14:44:10 -0400, Stephen Hoffman wrote:

> It's quite correct that unsupported-hardware configurations are
> incredibly difficult or ~impossible to detect ...

Which is why it would have been so much simpler if VSI had not gone the
“not invented here” route, and built their x86 port on top of an existing
OS, leaving all the tricky hardware stuff to that.