On Friday, November 5, 2021 at 3:14:06 AM UTC+13, osuv...@gmail.com wrote:
>
> On Thursday, November 4, 2021 at 9:23:38 AM UTC-4, Arne Vajhøj wrote:
>>
>> Sounds like somebody did not like SYS$QIO(W).
>
> Considering how slow the VAX was and that terminal I/O was often many
> many small transfers, that kind of micro-optimization was probably worth
> while.

Remember the old saying, variously attributed to Hoare or Knuth: “premature optimization is the root of all evil”. By making pseudo-terminals a special case, they lost the ability to treat it uniformly as part of a common event loop I/O framework.

Meanwhile, Unix systems had the pty(7) device. Open one, and you get just another file descriptor, and you access it with normal read(2) and write(2) calls, same as any other file descriptor. And you can use it with select/poll/epoll.

On 11/4/2021 7:07 PM, Rich Jordan wrote:
> On Monday, November 1, 2021 at 1:40:00 PM UTC-5, Volker Halle wrote:
>> Rich,
>>
>> thanks for testing and sharing your notes. So it really looks like an upgrade vs. install issue. And it affects the LAN interface, irrelevant of the protocol used.
>>
>> Is the 'link LED' lit on the physical LAN interface ?
>>
>> SHOW DEV/FULL EIA0 shows 'no link' - right ?
>>
>> Please test with the system parameter file from the freshly installed system disk.
>>
>> Volker.
>
> Replacing the parameter file on the upgraded system with the one from the clean VSI install did not make a difference WRT the network; it did cause some complaints because DECwindows could not start, but everything else did after I updated SCSNODE and SCSSYSTEMID in the copied file to match the upgraded system's name and ID.
>
> I tried a second NIC port for the hell of it, but none of them come up. Counters show the same errors as before.
>
> I'm contacting the customer's VSI rep to find out how we can put in a support request; hopefully that side of things has been taken care of.
>
> Rich
>

I don't know if this is your problem. It was my problem.

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.

> $ MCR NCL PURGE CIRCUIT EWA-1 ALL
> $ MCR NCL PURGE LINE EWA-1 ALL

Then use STARTNET to start DECnet.

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

On Thursday, November 4, 2021 at 8:54:37 PM UTC-4, Lawrence D’Oliveiro wrote:
> On Thursday, November 4, 2021 at 5:54:21 PM UTC+13, osuv...@gmail.com wrote:
> > Most of PTD$ code runs in kernel mode with some at elevated IPL.
> So does a device driver. Why do the PTD functions have to be a separate layer from the device driver? Particularly a separate, caller-visible layer that breaks the normal driver QIO abstraction?
> > PTD$READ/WRITE queue request packets directly to FTDRIVER,
> > skipping some of the overhead of $QIO processing.
> Remember, these are terminals we are talking about -- devices geared to the limits of human I/O bandwidth. Any “overheads” associated with I/O processing would be insignificant compared to the time it takes for a human to type input or read output.

That's a PC menatility, VAXes were timesharing systems with many concurrent users. C was a second class
language in the VAX/VMS world, too, so the API wasn't designed to cater the patterns of the C RTL. Threads
didn't exist, your server process handling many PTYs was state driven by ASTs delivered by the terminal
driver.

On 11/5/21 1:46 AM, David Jones wrote:
> On Thursday, November 4, 2021 at 8:54:37 PM UTC-4, Lawrence D’Oliveiro wrote:
>> On Thursday, November 4, 2021 at 5:54:21 PM UTC+13, osuv...@gmail.com wrote:
>>> Most of PTD$ code runs in kernel mode with some at elevated IPL.
>> So does a device driver. Why do the PTD functions have to be a separate layer from the device driver? Particularly a separate, caller-visible layer that breaks the normal driver QIO abstraction?
>>> PTD$READ/WRITE queue request packets directly to FTDRIVER,
>>> skipping some of the overhead of $QIO processing.

>> Remember, these are terminals we are talking about -- devices
>> geared to the limits of human I/O bandwidth. Any “overheads” associated with
>> I/O processing would be insignificant compared to the time it takes for
>> a human to type input or read output.

> That's a PC menatility, VAXes were timesharing systems with many
> concurrent users. C was a second class language in the VAX/VMS world,
> too, so the API wasn't designed to cater the patterns of the C RTL.
> Threads didn't exist, your server process handling many PTYs was
> state driven by ASTs delivered by the terminal driver.

And I remember lots of complaints from people who had to slow down their
typing so the VAX could catch up.

On 11/5/21 11:39 AM, Craig A. Berry wrote:
>
> On 11/5/21 1:46 AM, David Jones wrote:
>> On Thursday, November 4, 2021 at 8:54:37 PM UTC-4, Lawrence D’Oliveiro
>> wrote:
>>> On Thursday, November 4, 2021 at 5:54:21 PM UTC+13, osuv...@gmail.com
>>> wrote:
>>>> Most of PTD$ code runs in kernel mode with some at elevated IPL.
>>> So does a device driver. Why do the PTD functions have to be a
>>> separate layer from the device driver? Particularly a separate,
>>> caller-visible layer that breaks the normal driver QIO abstraction?
>>>> PTD$READ/WRITE queue request packets directly to FTDRIVER,
>>>> skipping some of the overhead of $QIO processing.
>
>>> Remember, these are terminals we are talking about -- devices
>>> geared to the limits of human I/O bandwidth. Any “overheads”
>>> associated with
>>> I/O processing would be insignificant compared to the time it takes for
>>> a human to type input or read output.
>
>> That's a PC menatility, VAXes were timesharing systems with many
>> concurrent users. C was a second class language in the VAX/VMS world,
>> too, so the API wasn't designed to cater the patterns of the C RTL.
>> Threads didn't exist, your server process handling many PTYs was
>> state driven by ASTs delivered by the terminal driver.
>
> And I remember lots of complaints from people who had to slow down their
> typing so the VAX could catch up.

The only time I ever saw that happen on a VAX was when I was using
EUNICE and someone else fired up the ADA Compiler. :-)

bill

On Thursday, November 4, 2021 at 8:35:20 PM UTC-5, Dave Froble wrote:
> On 11/4/2021 7:07 PM, Rich Jordan wrote:
> > On Monday, November 1, 2021 at 1:40:00 PM UTC-5, Volker Halle wrote:
> >> Rich,
> >>
> >> thanks for testing and sharing your notes. So it really looks like an upgrade vs. install issue. And it affects the LAN interface, irrelevant of the protocol used.
> >>
> >> Is the 'link LED' lit on the physical LAN interface ?
> >>
> >> SHOW DEV/FULL EIA0 shows 'no link' - right ?
> >>
> >> Please test with the system parameter file from the freshly installed system disk.
> >>
> >> Volker.
> >
> > Replacing the parameter file on the upgraded system with the one from the clean VSI install did not make a difference WRT the network; it did cause some complaints because DECwindows could not start, but everything else did after I updated SCSNODE and SCSSYSTEMID in the copied file to match the upgraded system's name and ID.
> >
> > I tried a second NIC port for the hell of it, but none of them come up. Counters show the same errors as before.
> >
> > I'm contacting the customer's VSI rep to find out how we can put in a support request; hopefully that side of things has been taken care of.
> >
> > Rich
> >
> I don't know if this is your problem. It was my problem.
>
> 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.
>
> > $ MCR NCL PURGE CIRCUIT EWA-1 ALL
> > $ MCR NCL PURGE LINE EWA-1 ALL
>
> Then use STARTNET to start DECnet.
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

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.

When we restored the image backup to the RX2800s, it brought that config along, and the RX2800 also uses the EI devices. Since this is just offsite testing, we're using a dumb as a stump GbE switch for the uplink. While running HP VMS, apparently it did not matter; the connection came up at GbE speed. After the upgrade, there was a problem with it. VSI had me purge the device from LANCP (we had already done that from DECNet MCP per Volker's suggestion, without success) and reboot. When the device came up with default settings, the link came up and it worked.

Huzzah.

The mystery is that we had already tried using the other three NIC ports on this box, all of which had auto-negotiation enabled, on the VSI upgraded system, and none of them would come up, though I'm pretty sure they were all set to autonegotiate enabled. The second NIC on the production RX3600 is not in use but has autonegotiation enabled. All three of them had the same issue being unable to bring up the link.

So I'm not sure why this worked but it did. I may test the other NICs for the hell of it but we've been delayed too much by this so probably have to just keep working on the transition now.

Thanks for all the replies and suggestions.

On Friday, November 5, 2021 at 7:46:15 PM UTC+13, osuv...@gmail.com wrote:
>
> On Thursday, November 4, 2021 at 8:54:37 PM UTC-4, Lawrence D’Oliveiro wrote:
>
>> On Thursday, November 4, 2021 at 5:54:21 PM UTC+13, osuv...@gmail.com wrote:
>>
>>> Most of PTD$ code runs in kernel mode with some at elevated IPL.
>>
>> So does a device driver. Why do the PTD functions have to be a separate layer from
>> the device driver? Particularly a separate, caller-visible layer that breaks the normal
>> driver QIO abstraction?
>>
>>> PTD$READ/WRITE queue request packets directly to FTDRIVER,
>>> skipping some of the overhead of $QIO processing.
>>
>> Remember, these are terminals we are talking about -- devices geared to the limits of
>> human I/O bandwidth. Any “overheads” associated with I/O processing would be
>> insignificant compared to the time it takes for a human to type input or read output.
>>
> That's a PC menatility, VAXes were timesharing systems with many concurrent users.

I was using time-sharing before I knew about PCs or even VAXes. When I first entered University, the main computer system was a PDP-11/70 running RSTS/E, which habitually coped with dozens of users. The most popular text editor was called “VTED”, which was a local variant on a screen-based editor written in TECO. I remember the system manager telling me that a single VTED instance consumed about 10% of the available CPU. You can see where this was going ...

The load of using full-screen interactive software, in itself, was never a problem on the VAX. What was a problem was things like MACSYMA, written in LISP, where the large memory usage combined with intensive garbage collection could still bring the system almost, but not quite, to its knees.

That, and the Ada compiler written in an interpreted language ...

> ... your server process handling many PTYs was state driven by ASTs delivered by the
> terminal driver.

True, but irrelevant.

On Saturday, November 6, 2021 at 4:39:59 AM UTC+13, Craig A. Berry wrote:
>
> And I remember lots of complaints from people who had to slow down their
> typing so the VAX could catch up.

What was your VAX doing? I’m a fast enough typist I was able to notice the very slight difference in echo time on a VT100 between a LAT connection and a direct serial line. (This before I gave up on real terminals and switched to NCSA Telnet on a Mac.)

On Saturday, November 6, 2021 at 5:11:39 AM UTC+13, Bill Gunshannon wrote:
> The only time I ever saw that happen on a VAX was when I was using
> EUNICE and someone else fired up the ADA Compiler. :-)

NYU Ada/Ed, I believe it was called? Written in SETL, and interpreted? And your programs were also compiled to SETL?

The one where, when your program hit an error, it took about 60 seconds† just to crash?

†I timed it.

On Saturday, November 6, 2021 at 5:11:39 AM UTC+13, Bill Gunshannon wrote:
> ... when I was using EUNICE ...

Ah, anybody else remember those HSH0NAEDA.HSH files proliferating on users’ accounts? (Why do I still remember that name...) And how its fork(2) emulation had to be implemented via a special executable called FORKDUMY.EXE or something like that? (Not that I understood how it worked -- I never used it.)

And when you built Perl on any *nix system for years after, one of the messages that could come from the build config system was “Congratulations, you’re not running EUNICE!”?

On 11/5/21 7:06 PM, Lawrence D’Oliveiro wrote:
>

> And when you built Perl on any *nix system for years after, one of
> the messages that could come from the build config system was
> “Congratulations, you’re not running EUNICE!”?

Still says it today:

<https://github.com/Perl/perl5/blob/4a1b9dd524007193213d3919d6a331109608b90c/Configure#L4519>

We should probably declutter a bit and rip out anything related to
eunice in the Perl sources.

On 11/5/21 6:57 PM, Lawrence D’Oliveiro wrote:
> On Saturday, November 6, 2021 at 4:39:59 AM UTC+13, Craig A. Berry wrote:
>>
>> And I remember lots of complaints from people who had to slow down their
>> typing so the VAX could catch up.
>
> What was your VAX doing?

Lots of circuit simulations, SPICE3 and various home-grown stuff. I
think increasing BYTLM quotas helped a little, but you couldn't increase
it too much on a 2MB VAX.

On 11/5/2021 7:59 PM, Lawrence D’Oliveiro wrote:
> On Saturday, November 6, 2021 at 5:11:39 AM UTC+13, Bill Gunshannon wrote:
>> The only time I ever saw that happen on a VAX was when I was using
>> EUNICE and someone else fired up the ADA Compiler. :-)
>
> NYU Ada/Ed, I believe it was called? Written in SETL, and interpreted? And your programs were also compiled to SETL?
>
> The one where, when your program hit an error, it took about 60 seconds† just to crash?
>
> †I timed it.

VAX Ada seems more likely.

Arne

Rich,

you might have been able to spot this yourself, if comparing the 'LAN Driver Messages' section (bottom couple of lines of LANCP> SHOW DEV/INTERNAL EIA0) between the good and the bad case.

Volker.

On 11/5/21 9:39 PM, Arne Vajhøj wrote:
> On 11/5/2021 7:59 PM, Lawrence D’Oliveiro wrote:
>> On Saturday, November 6, 2021 at 5:11:39 AM UTC+13, Bill Gunshannon
>> wrote:
>>> The only time I ever saw that happen on a VAX was when I was using
>>> EUNICE and someone else fired up the ADA Compiler. :-)
>>
>> NYU Ada/Ed, I believe it was called? Written in SETL, and interpreted?
>> And your programs were also compiled to SETL?
>>
>> The one where, when your program hit an error, it took about 60
>> seconds† just to crash?
>>
>> †I timed it.
>
> VAX Ada seems more likely.
>

Don't remember which Ada it was. One of the first validated Ada
Compilers. After all, this was around 1981.

bill

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.

--
-- Rob

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.

--
Pure Personal Opinion | HoffmanLabs LLC

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@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2021-11-06, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>
> 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 a very interesting way of expressing that and leads to a more
interesting general question:

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 ?

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

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/6/21 4:42 PM, Simon Clubley wrote:
> On 2021-11-06, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>>
>> 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 a very interesting way of expressing that and leads to a more
> interesting general question:
>
> 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 ?
>
> If it's the latter, is that going to change for x86-64 VMS, given some
> of the hardware out there ?
>

I don't think that's an issue as it has been stated from the
beginning that VMS was not going to support everything but
only a certain subset of systems and components.

bill

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

>-----Original Message-----
>From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Simon Clubley
>via Info-vax
>Sent: November-06-21 5:42 PM
>To: info-vax@rbnsn.com
>Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
>Subject: [Info-vax] Working with broken hardware, was: Re: DECnet Phase IV
>broken after VSI update
>
>On 2021-11-06, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>>
>> 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 a very interesting way of expressing that and leads to a more
>interesting general question:
>
>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 ?
>
>If it's the latter, is that going to change for x86-64 VMS, given some of
the
>hardware out there ?
>
>Simon.
>
>--

FWIW .. its still an industry problem (even today) - same issue on Linux and
Windows and Telecom gear in general platforms with old(er) switches and gear
that do not conform to todays standards.

Just google "auto-negotiation problems" ..

Sample -
<https://knowledge.broadcom.com/external/article/167467/why-am-i-getting-aut
onegotiation-problem.html>
"Auto-negotiation problems are common; they result from errors on the
Ethernet devices connected to the appliance, causing dropped packets,
reduced throughput, and session drops. Devices that are connected, such as
the router or a LAN switch could also switch from full-duplex to half-duplex
(and vice versa) because of auto-negotiation problems, resulting in poor
network performance.

In some cases, if a duplex mismatch occurs when the interface is
auto-negotiated and the connection is set to half-duplex, or the
auto-negotiation does not provide the optimal outcome. As a result, manually
setting the duplex setting might be the workaround to avoid this problem."

Since it is likely impossible for a host driver to be able to detect all
related issues (especially in X86 world), I would suggest the driver do a
small internal test and if it detects an issue, simply log the issue on the
console or host error log / event viewer.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com

On 11/6/2021 4:42 PM, Simon Clubley wrote:
> On 2021-11-06, Robert A. Brooks <FIRST.LAST@vmssoftware.com> wrote:
>>
>> 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 a very interesting way of expressing that and leads to a more
> interesting general question:
>
> 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 ?
>
> If it's the latter, is that going to change for x86-64 VMS, given some
> of the hardware out there ?
>
> Simon.
>

Which then brings up the question, just how many work-arounds do you want?
Perhaps until the code for work-arounds exceeds the code for the OS?

Since you asked, I'd suggest supporting conforming HW, and skip the rest.

If using a VM, the issue probably isn't. For "bare metal" (how did we ever
come up with such an idiot name?) as mentioned elsewhere, x86 VMS will
support a limited set of HW. Probably all new stuff, which most likely
doesn't include past kludges.

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

On Saturday, November 6, 2021 at 2:34:41 AM UTC-5, Volker Halle wrote:
> Rich,
>
> you might have been able to spot this yourself, if comparing the 'LAN Driver Messages' section (bottom couple of lines of LANCP> SHOW DEV/INTERNAL EIA0) between the good and the bad case.
>
> Volker.

Possibly. Also if I'd had it connected to a decent switch. If I have a chance I'll set the port back to fixed speed with autonegotiate disabled and see if usable messaging shows up, but I doubt there will be time. Ditto temporarily plugging it into a Meraki switch port to see what is says.

But while the problem was occurring, we tried the other three NIC ports, all of which had auto negotiation enabled and no hard codes for speed or duplex, and all of them failed the same way as EIA-0 for DECnet, and showed link down on the device. On two different desktop GbE switches (which are toys, so might be an issue though they worked with HP VMS initially). I did not plug into one of the Cisco or Meraki switches, though, which might have provided usable diagnostics. It is entirely possible the desktop switches are nonconforming and perhaps the engineer Robert mentioned has fixed things to the point that those switches are no longer good enough. In production the server will be connected to Cisco Catalyst switches; I just don't have enough ports here to handle the segregated network that the server, a test alpha, and a monitor/terminal emulator PC is on except by using the desktop switch.

On Sunday, November 7, 2021 at 8:32:26 AM UTC+13, Dave Froble wrote:
> 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.

There is something to be said for the convention that a subsystem will, by default, *not* look at any hardware unless it has been explicitly configured to do so.