[Info-vax] Working with broken hardware, was: Re: DECnet Phase IV broken after VSI update

[Stephen Hoffman]

On 2021-11-06 20:42:14 +0000, Simon Clubley said:

> Does VMS support hardware which doesn't correctly implement a standard 
> (by implementing a workaround as Linux tends to do), or has VMS 
> Engineering over the decades outright said that it doesn't follow the 
> standards, so it's broken, so we won't support it ?

DE500 Fast Ethernet support was... turbulent... during the hardware 
transition to auto-negotiation, and was a mixed bag around 
auto-negotiation.

As were some of the other NICs in that era. Later NICs worked better, 
and GbE NICs do much better with both speed and duplex. Earlier NICs 
can be hit or miss, and more than a few were settings-locked.

In the antediluvian era of networking, locking NIC settings was 
recommended for specific configurations, too.

> If it's the latter, is that going to change for x86-64 VMS, given some 
> of the hardware out there ?

I would expect to be rid of DE500 NICs when transitioning over to 
x86-64. Not at current GbE NIC prices and DE500 speeds, for those cases 
where the GbE or 10 GbE NIC isn't already server-integrated.

There are *lots* of ways to get in trouble with OpenVMS. Where it'll 
fail with weird errors. Duplicate MAC address detection checks were 
added there, and can catch some configuration issues. There are others.

DHCP client support in OpenVMS was problematic for instance and may 
still be (it's been a ~decade since I've bothered to try it), and 
hopefully that will be improving with what VSI has been and will be 
working on.

IPv6 support on OpenVMS similarly needs some help.

For those of you wondering how to find and learn about the more 
meddlesome areas?  Postings around here, of course. There are other 
ways. Over several years, there was a well-done and well-presented 
series of boot camp technical sessions offered by some HP/HPE folks, 
describing how to implement and debug and work around what was clearly 
some poorly-documented and seemingly busted OpenVMS code. Better 
documenting and hardening the associated OpenVMS code was seemingly 
somehow out of bounds. Looking around for code that has 
stupid-complicated configuration requirements and/or stupidly-manual 
configuration requirements is another. SMTP server had a wonderful 
failure mode for a while and may still, where a missing configuration 
file generated no diagnostics and the the SMTP server silently (and 
incredibly) defaulted to operating as an open relay. I've previously 
pointed to certificate authentication. IPv6. Etc.


-- 
Pure Personal Opinion | HoffmanLabs LLC