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

[Stephen Hoffman]

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