24 Jan
2022
24 Jan
'22
11:36 p.m.
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:
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
On Jan 24, 2022, at 12:01 PM, Johnny Billquist
<bqt(a)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.