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

[Arne Vajhøj]

On 4/8/2024 12:49 PM, Robert A. Brooks wrote:
> 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.

I think the current practice makes sense.

It should be obvious that running an unsupported configuration
comes with a risk of problems.

It makes sense to have VMS complain about configs that are
known not to work.

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.

Arne