<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 14, 2019, at 11:55 PM, Thomas DeBellis <<a href="mailto:tommytimesharing@gmail.com" class="">tommytimesharing@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">Thanks, this isn't quite everything that I was wondering about,
but let me elaborate.</p><p class="">When a DN20 (PDP-11/34) is running embedded bi-sync to speak to
an IBM host (via a KMC), it is generically called a DN60 (the name
for packaging software being DN62 or DN65). I wonder how
marketing came up with those numbers? I'm certain it provided
significant value-add while cost effectively thinking out of the
box to <i class="">somebody</i> over there... All communications to the
KL from RSX20F, DN20's and DN60's come through DTE20's. But this
question was not about DN60's, which I won't care about until such
time as I have a Hercules emulator I feel like getting busy with.<br class="">
</p>
<div class="moz-cite-prefix">I can't remember what RSX20F had grown
out, but what I had heard was that the base was 11M as this had
the smaller footprint (at the time). That effort may have been
headed by Ron McLean. It is a true statement that DTE20 driver
development would have been done in Marlboro.<br class="">
</div>
<div class="moz-cite-prefix"><br class=""></div></div></div></blockquote>We were running pretty thin on resources (mostly developer at this time). The original schedule called for 9 months to get DECnet running on all flavors of RSX-11, we just about managed to get them done in 18 months. Didn’t Thomas Löfgren run some part of the DNxx development around that time? I had worked for Thomas in Sweden and interviewed with his development team but decided not to accept his offer.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><div class="moz-cite-prefix">
</div>
<div class="moz-cite-prefix">However, there was a pretty vast
commonality in the RSX code base. Specifically, I was wondering
about two things:</div></div></div></blockquote><div><br class=""></div>Yes and no. Application level code was usually pretty easy to get running on all flavors of RSX-11. However, the internal architecture was split into 2 classes:</div><div><br class=""></div><div>1. RSX-11D/IAS - mapped systems only</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Device drivers ran as ’tasks’ (processes) with direct access to I/O devices, system memory allocations and some system routines</div><div><br class=""></div><div>2. RSX-11M/11S - any PDP-11 system with sufficient memory + devices</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Device drivers ran as part of the ‘kernel’ serialized by the fork block mechanism</div><div><br class=""></div><div>I guess RSX-11M+ could be consider a separate class adding I/D space, supervisor mode and multi-processor support.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
<div class="moz-cite-prefix">
<ol class="">
<li class="">What is the latest Phase DECnet that 11M will run? I guess
the last release was 93?</li></ol></div></div></div></blockquote><div>Phase IV. The last release I see on <a href="http://bitsaver.org" class="">bitsavers.org</a> was 4.5 in Oct 1989</div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><div class="moz-cite-prefix"><ol class="" start="2">
<li class="">MCB; what was developed on it past your snapshot (Phase II)</li></ol></div></div></div></blockquote>The beware file for DECnet-10 version 4, January 1986 (Phase IV) indicates that MCB front ends are a requirement.<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><div class="moz-cite-prefix"><p class="">At least in Marlboro on the 36 bit line, while there was
competition, there wasn't always an intense amount of NIH. So
the DECnet transport code was originally developed in user mode
in Tops-10. After debugging, it got merged into the Tops-10
monitor. Once (or while) that was being done, the same code
code base got merged into Tops-20.<br class="">
</p>
</div>
<div class="moz-cite-prefix">The KL router code will do level 1. I
don't remember what the DN20 would do. I guess maybe Shoppa's
site might have the latest MCB.<br class="">
</div>
<div class="moz-cite-prefix"><br class=""></div></div></div></blockquote>There is a backup tape there for Tops-10. The only sources included are those needed to tailor the final system.</div><div><br class=""></div><div>I found the DECnet-20 V4.0 distribution tape on Tim Shoppa’s site and poking around in some of the files seems to indicate that the DN20 is based on the MCB code base.</div><div><br class=""></div><div> John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><div class="moz-cite-prefix">
</div>
<div class="moz-cite-prefix">Some higher level code was written in
BLISS. I have yet to chase <font size="+1" class=""><tt class="">NMLT20</tt></font>
down (the Tops-20 <tt class=""><font size="+1" class="">NICE</font></tt>
implementation).<br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">The front end (RSX20F) code have run
DECnet transport in theory, but not in practice by Tops-20 version
4. Once they shut off 'aggregating' on the DH11's to accommodate
the VT100 smooth scrolling lossage, that poor 11 didn't have time
for a blessed thing. You could really tell the difference on the
front panel between 3A (not so much blinky) and 4 (plenty
blinky!!) One site that I am aware of (CW) actually used an
additional DN20 to run RSX20F in order to put lines on it to share
the load. Pretty cool.</div>
<div class="moz-cite-prefix"><br class="">
</div>
<div class="moz-cite-prefix">They really should have fixed the ^S/^Q
padding issue for smooth scroll, though...<br class="">
</div>
<div class="moz-cite-prefix"><br class="">
</div>
<blockquote type="cite" cite="mid:5EA022D9-5FA1-4559-8C17-C488AE6ED057@forecast.name" class="">
<hr width="100%" size="2" class="">On 7/14/2019 3:16 PM, John Forecast
wrote:
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">On Jul 14, 2019, at 1:48 PM, Thomas DeBellis
<<a href="mailto:tommytimesharing@gmail.com" class="" moz-do-not-send="true">tommytimesharing@gmail.com</a>>
wrote:</div>
<div class="">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">I had been wondering about the RSX DECnet
packaging.</p><p class="">Pre-CI DECSYSTEM-20's may be modeled according
to a loosely coupled multi-processor paradigm, with the
main KL being communicated with DTE20's, the master one
having additional rights. These were connected to
either a front end communications processor (which
handled the communications, unit record equipment and I
believe the ANF10) and other networking. These were
packaged in separate cabinets as DN20's.</p><p class="">The DN20 subsystems were 11/34 - 11/40 class
machines, which might now be better thought of as
ancillary processors or even embedded systems, but
sometimes were running cut down versions of full blown
operating systems. The front end ran a version of RSX
called RSX20F and was somewhat stripped down, not having
a login.</p><p class="">A DN20 was termed a DN20 if it ran the
2780/3780/HASP communications code that IBMSPL talked
to. Since I was Columbia Galaxy nerd and knew PDP-11
assember, I also maintained that code (and worked with
our VM/MVS folks to fix a pesky bug in the multi-leaving
implementation). As I recall, this was embedded code
and precisely RSX based (but it's been at least 35 years
since I assembled any of that). I think I used a 20
based cross assembler to do it.<br class="">
</p><p class="">We did have an RSX20F pack, but I don't recall
as I ever looked at source on that. Or maybe it was on
microfiche.</p><p class="">Do you know how DECnet would have been
packaged for the DN20 and DN200 (the DECnet based RJE
station)? One assumes it would have been built off of
RSX.</p>
</div>
</div>
</blockquote>
If the DN20 used DTE20’s to communicate with the KL, I would
expect the code would have been developed out of Marlboro. We
(as in RSX DECnet development) had no PDP-10 hardware in our
labs and would have found it difficult to code and test such
software. The only IBM communication product that I remember is
RSX-2780 which ran on both 11M and 11D as standalone
applications - I believe there was some attempt to integrate it
with CEX but I don’t know if that succeeded.</div>
<div class=""><br class="">
</div>
<div class="">The prevailing wisdom is that RSX20F is based on RSX-11D.</div>
<div class=""><br class="">
</div>
<div class="">Around the end of Phase II development (late ’79, early ’80)
we provided a snapshot of our current development tree to
Marlboro which was used to develop the MCB front end. Looking at
the code on Tim Shoppa’s site it looks like this is based on
RSX-11S.</div>
<div class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><p class="">I can't remember whether the DN20 would do
anything past Phase III.<br class="">
</p>
</div>
</div>
</blockquote>
I was never involved in the IBM communications side so,
unfortunately, I can’t help there.</div>
<div class=""><br class="">
</div>
<div class=""> John.<br class="">
<blockquote type="cite" class="">
<div class="">
<div text="#000000" bgcolor="#FFFFFF" class=""><div class=""> <br class="webkit-block-placeholder"></div>
<blockquote type="cite" cite="mid:F9A42C87-6D5D-48CC-86F0-83CA7A57F425@forecast.name" class="">
<hr class="" width="100%" size="2">On 7/5/2019 7:57 PM,
John Forecast wrote:
<pre class="moz-quote-pre" wrap="">What you see in CEXBF.MAC is all there ever was for CEX. When I joined the development team in Jan ’77, an implementation of Phase II NSP was running standalone under a “Communications Executive”. The decision was made to “port” this “Communications Executive” into each of the RSX-11 Decnet implementation (11M/11S/11D and IAS) and they would all use this NSP implementation. As a side benefit we would get all the device drivers that had been implemented as well.
</pre>
<pre class="moz-quote-pre" wrap="">[...] that would be too expensive if every packet had to flow through NETACP. When a packet is queued to a process (asynchronous rather than direct call) it is queued to the NS: fork block. When NS: driver runs as a result it peeks at the request and may queue it to NETACP or process it immediately.
</pre>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div></blockquote></div><br class=""></body></html>