For the Tops-20 mailer, depending on the length of the outage, it might not require manual intervention.  This is true even for MAIL11 routing.  MMAILR contains three queues:

  1. What to do now,
  2. What to do 'later' and
  3. What to do 'much later'.
I believe 'later' is tomorrow and I know that 'much later' is at least a week.  It is only after failing out of all three queues that the delivery is failed.  The sender gets a message on each re-queue and on the 3rd failure, the entire message is dequeued and returned to the sender.  These notifications can also be copied internally to the person or group responsible for the mail system so they can investigate and remediate if the problem is local or otherwise notify network operations.

If you are running my monitor patches, then the internal DECnet header will have the correct area.node number in it.  Otherwise, the mailer makes something up to put in the field.  That's right, it makes it up.  It doesn't matter what is actually in there because the number isn't used for anything when doing DECnet transport.  This is just to make integration with the other transport layers (such as TCP/IP, PUP and CHAOS) more straightforward.

The DECnet node name is resolved at the time of the connection attempt.  If you are running my monitor patches and my rewritten monitor node table updater (SETND2), then the regular batch job should update the node to the new number in time for queue three to work if the failure is because of a node renumber.

CCnet went through frequent additions, area splits and sometimes re-numberings within areas.  I can't remember how the node list was passed around.


On 1/24/22 5:00 PM, Johnny Billquist wrote:
On 2022-01-24 21:48, Mark J. Blair wrote:


On Jan 24, 2022, at 12:01 PM, Johnny Billquist <bqt@softjar.se> wrote:

As for subscribing from a machine on HECnet. There is no need to know anything about any owners of any area routers. All you need is to subscribe using the address you want to be subscribed from.

I think that the mention of knowing about owners was in reference to knowing other ways to reach certain people when one's HECnet connection is broken, so that one can't receive HECnet list mail over the HECnet network for help in debugging one of the other. If I were to use an address on the HECnet network for my HECnet mailing list subscription, then I'd be putting all of my eggs in one basket when things stop working, if I didn't keep note of how to contact Johnny and my upstream connection's owner without using HECnet itself.

Fair enough. However, I would hope that there are multiple paths between most places, and few single points of failure. (But with that said, of course, this also potentially can cause problems with area splits.)

  Johnny