<html><body><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; color: #000000"><div>A DDP device is a "DDCMP speaker on a ANF10 front end". <br></div><div><br data-mce-bogus="1"></div><div>It's basically a 576 byte card punch/reader on the front end with corresponding<br data-mce-bogus="1"></div><div>device on the T10 side. We used it on the KI to talk both DECnet-IV and IP (to <br data-mce-bogus="1"></div><div>a BSD 4.3 vaxen with a DMR-11.) It was done as a hack by Robert Hauk, who<br data-mce-bogus="1"></div><div>also put in ANF10 over Ethernet. (remmember the DECnet frontend for the DTE<br data-mce-bogus="1"></div><div>was only phase 3).<br data-mce-bogus="1"></div><div><br></div><div>Dept of useless knowledge..<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>-P<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"tommytimesharing" <tommytimesharing@gmail.com><br><b>To: </b>"hecnet" <hecnet@Update.UU.SE><br><b>Sent: </b>Sunday, January 17, 2021 5:10:08 PM<br><b>Subject: </b>Re: [HECnet] Thousands of DECnet errors on Tops-20<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><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>
<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>
<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>
<hr width="100%" size="2"><b>From</b>: "tommytimesharing"
<a href="mailto:tommytimesharing@gmail.com" target="_blank" rel="nofollow noopener noreferrer"><tommytimesharing@gmail.com></a>
<br>
<b>To</b>: "hecnet" <a href="mailto:hecnet@Update.UU.SE" target="_blank" rel="nofollow noopener noreferrer"><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>
<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><br></blockquote></div></div></body></html>