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

[Arne Vajhøj]

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.

>                                                          It is also
> absolutely no different from in the past when a new version of VMS
> used to add support for new CPUs from DEC.

Correct. This is the mechanism used in the past.

But the context has changed. Instead of DEC releasing a few new
models every year, then we have an huge number of VM, VM version,
host, host version combos.

H1..H4 is fine. H1..H100 is a problem.

> IOW, my suggested approach is a very long-established part of the
> VMS world. The only difference now is that VMS would be allowed to
> continue booting if you set an override flag or SYSGEN parameter.
> 
> Also, there should be no need to add support for "VM Bar 4" unless
> it brought new functionality over "VM Bar 3" that you wanted to
> support in VMS.

????

The interest in different VM's is not driven by what VMS need,
but from what customers want.

> 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.

Arne