[Info-vax] %SYSTEM-F-ACCVIO again

[Arne Vajhøj]

On 4/10/2024 8:10 AM, Simon Clubley wrote:
> On 2024-04-09, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> On 4/9/2024 8:45 AM, Simon Clubley wrote:
>>> On 2024-04-08, Arne Vajhøj <arne at 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