<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>The only serial lines that I saw DECnet running on were
synchronous connections. The local connections between CU's 20's
(before we got the CI's and NI's) were 56K baud synchronous lines
running on KMC11's, which we thought were pretty hot stuff
...until... Non-data center connections (our chemistry VAX, CMU
& CWR 20's) were asynchronous lines running 9.6K baud (on
DUP11's, I think).</p>
<p>The PANDA monitor's Multinet code implements serial IP (SLIP),
which it will run over an ordinary DL or DH based asynchronous
lines. I didn't immediately see anything similar for DECnet, but
it is doubtful that MRC would have put that it in; the code was
supposed to run on a 2020, which has different IO drivers. If his
2020 5.0 changes ever do surface, it may be conceivable that some
of them might be retrofitted into 7.1 (depends on what's
applicable).<br>
</p>
<p>It is now possible that I will eventually figure out what this
mysterious DDP device is. I reconfigured both 20's to have the
largest buffer possible (<font size="+1"><tt>DECNET BUFFER-SIZE
1476</tt></font> in <font size="+1"><tt>SYSTEM:7-1-CONFIG.CMD</tt></font>,
which I checked in the running monitor), rebooted <i>and</i> ...
I'm still getting the same frame too long error, viz:</p>
<blockquote>
<p><font size="+1"><tt>***********************************************</tt><tt><br>
</tt><tt>DECNET ENTRY</tt><tt><br>
</tt><tt> LOGGED ON 16-Jan-2021 01:29:38-EST MONITOR
UPTIME WAS 0 day(s) 0:16:8</tt><tt><br>
</tt><tt> DETECTED ON SYSTEM # 3691.</tt><tt><br>
</tt><tt> RECORD SEQUENCE NUMBER: 35752.</tt><tt><br>
</tt><tt>***********************************************</tt><tt><br>
</tt><tt>DECNET Event type 5.15, Receive failed</tt><tt><br>
</tt><tt>From node 2.522 (VENTI2), occurred 16-JAN-2021
01:29:11</tt><tt><br>
</tt><tt><br>
</tt><tt> Line NI-0-0</tt><tt><br>
</tt><tt><br>
</tt><tt> Failure reason = Frame too long</tt><tt><br>
</tt><tt> Ethernet header = AB 00 00 03 00 00 / AA 00 04 00
08 0A</tt><tt><br>
</tt><tt><br>
</tt><tt>***********************************************</tt><tt><br>
</tt><tt>DECNET ENTRY</tt><tt><br>
</tt><tt> LOGGED ON 16-Jan-2021 01:29:38-EST MONITOR
UPTIME WAS 0 day(s) 0:16:8</tt><tt><br>
</tt><tt> DETECTED ON SYSTEM # 3691.</tt><tt><br>
</tt><tt> RECORD SEQUENCE NUMBER: 35753.</tt><tt><br>
</tt><tt>***********************************************</tt><tt><br>
</tt><tt>DECNET Event type 5.15, Receive failed</tt><tt><br>
</tt><tt>From node 2.522 (VENTI2), occurred 16-JAN-2021
01:29:28</tt><tt><br>
</tt><tt><br>
</tt><tt> Line NI-0-0</tt><tt><br>
</tt><tt><br>
</tt><tt> Failure reason = Frame too long</tt><tt><br>
</tt><tt> Ethernet header = AB 00 00 03 00 00 / AA 00 04 00
FF 0B</tt><tt><br>
</tt><tt><br>
</tt><tt>************************************************************************</tt></font></p>
</blockquote>
<p>Darn it‼️ So now I've got some modifications to actually make to
the monitor to give some better error information (like the number
of bytes overrun, if I can extract it). So maybe I'll stumble
over whatever DDP does. It's odd; I can't think of any device
that a pack of KL's could share except something like a dual
ported disk or magnetic tape drive and that's only two KL's.<br>
</p>
<p>Meanwhile, I'll also do a <font size="+1"><tt>tcpdump</tt></font>
so I can try to correlate what Tops-20 is silently whining about
with what's coming over the bridge.</p>
<p>Finally, something to beware of if you are running the KLH10
micro-engine and have a very large file that you're backing up
(you're all running regular backups, <i>right</i>?) The amount
of disk activity will somehow prevent KLH10's front end timer from
popping so, unless you are running my changes to DTESRV, you're
going to <i>hang</i> with a <font size="+1"><tt>DTEKPA</tt></font>
<font size="+1"><tt>BUGINF</tt></font>. A quick hack is to
deposit a -1 into <font size="+1"><tt>FEDBSW</tt></font>, which
will keep the 20 from trying to reboot the front end (which KLH10
absolutely does not know how to handle). <br>
</p>
<div class="moz-cite-prefix">So the quarterly full backups worked
fine on the development machine (VENTI2) which has the patch, but
not on the production machine (TOMMYT) which does not. Pity, I
had been up over 32 weeks and was only a little short of 3,000
hours uptime.<br>
</div>
<blockquote type="cite"
cite="mid:19d3817a-3883-08c6-0773-8db9149b2c3e@softjar.se">
<hr width="100%" size="2">On 1/15/21 11:58 PM, Johnny Billquist
wrote:<br>
<br>
I saw that and wondered as well.
<br>
I was thinking maybe it could be for DDCMP devices without more
specifically defining what it would be, since DDCMP could be run
over any serial line?
<br>
<br>
Johnny
<br>
<blockquote type="cite">
<hr width="100%" size="2">On 2021-01-15 22:53, Peter Lothberg
wrote:
<br>
<br>
The 2020 has a KMC11 and up to 2 DUP11, and those are the
interfaces
<br>
the "MRC T20 DECnet thing supports.
<br>
<br>
On the list of devices/sizes you posted is a "DDP" device and I
wounder
if you knew what that is?
<br>
<br>
--P
<br>
<blockquote type="cite">
<hr width="100%" size="2"><b>From</b>: "tommytimesharing"
<a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><tommytimesharing@gmail.com></a>
<br>
<b>To</b>: "hecnet" <a class="moz-txt-link-rfc2396E" href="mailto:hecnet@Update.UU.SE"><hecnet@Update.UU.SE></a>
<br>
<b>Sent</b>: *Friday, January 15, 2021 4:24:07 PM
<br>
<b>Subject</b>: *Re: [HECnet] Thousands of DECnet errors on
Tops-20
<br>
<br>
DDP? I thought it was DUP-11.
<br>
<blockquote type="cite">
<hr width="100%" size="2"><br>
On 1/15/21 4:21 PM, Peter Lothberg wrote: <br>
<br>
Well, MRC was receiving "suggestions" from Stu Grossman on
how to do it, but if my memory does not fail me the block
size was 312, due to lack of buffer space in the already
crammed single section 512KW 2020. I'm afraid my tape and
disk-pack are in Seattle. I knew it was not 576 as it had
two DUP-11's and using it for transit failed... <br>
<br>
Quiz, do you knew what a DDP is? <br>
<br>
-P </blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>