[Info-vax] DECnet Phase IV broken after VSI update

[Dave Froble]

On 11/6/2021 12:28 PM, Stephen Hoffman wrote:
> On 2021-11-06 13:52:03 +0000, Robert A. Brooks said:
>
>> On 11/5/2021 7:52 PM, Rich Jordan wrote:
>>
>>> VSI found it, though there's still a mystery of sorts attached.
>>>
>>> The original system also has EIA-0 (and 1) NICs.  The EIA-0 is set to 1Gbs full duplex, auto negotiation disabled, and the corresponding Cisco port is set the same.
>>
>>> This is because they've had the system long enough that they experienced the bad behavior between VMS and switches doing auto negotiations in the dim past.
>>
>> Unless they are referring back to the mid-90's when the early PCI Ethernet adapters on Alphas were not-so-great, that info is a bit stale.
>>
>> VMS Engineering (specifically, the guy who's been writing our Ethernet drivers for over 30 years) has stated that auto-negotiate should always be used.
>>
>> If it doesn't work, he'll fix it, or determine that the switch is non-conforming to the standard.
>
>
> That's been becoming the new policy since ~Y2K or so—though with some wrinkles around Alpha and Itanium NICs—then GbE controllers and late-era Fast Ethernet that are detected with auto-negotiate disabled should generate an informational message at OpenVMS boot, in the logs, when viewed within LANCP, and within the documentation. For important network switch settings preferences, I'd be included to post driver status information to end-users via SHOW DEVICE /FULL, and AMDS/AM, too.
>
> The distribution of this information—and of other analogous recommendations for many other API choices available—has been inconsistent, at best. An API with choices needs to have published opinions, and best has diagnostics when the existing settings are drifting out of current preferences. Y'all want us pesky customers to move in certain shorter-term or longer-term directions, y'all need to tell us that. WTFM, minimally. Displaying diagnostics is preferred.
>
> If y'all as developers don't have an opinion for an API or settings choice, there shouldn't be an API or settings choice. And preferences can shift over time, which means shifting our usages.
>
> Unfortunately for this and similar cases where the end-user really intends to have a bogus setting—this because there's a busted switch port or busted switch firmware or whatever—OpenVMS also lacks a means to provide overt alert messaging and to then suppress the the overt displays over time, moving the displays to status-related cases.  Such as into LANCP, here. That'll probably require some updates to the existing 1970s- and 1980s-era diagnostics and status-reporting infrastructure.
>
>

I've got to second this concept.  An example:

With one exception, every VMS system I set up had one ethernet port.  The exception
is my AlphaServer 800, which had a 4 ethernet port card when I got it.  After having
problems, I pulled out the 4 port card and installed a DE500-BA single port card.
Things worked, and I didn't look further.

One of your fine support people mentioned to me:

By default, DECnet Phase IV installation and configuration will enable DECnet protocol on all available interfaces on the system.  Once configured, the system administrator would want to go into NCP and purge all lines and circuits that are not needed from the database.

I never knew that.

When setting up DECnet, perhaps in NETCONFIG, or elsewhere, something
could be mentioned about that issue.

Just one example of how to make VMS more user friendly.

And yes, I'm aware, the list of such "hints" could be quite extensive.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486