<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 1:48 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="">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 class=""><br class=""></div></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><br class=""></div><div>The prevailing wisdom is that RSX20F is based on RSX-11D.</div><div><br class=""></div><div>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><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><br class=""></div><div> John.<br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">
</p>
<blockquote type="cite" cite="mid:F9A42C87-6D5D-48CC-86F0-83CA7A57F425@forecast.name" class="">
<hr width="100%" size="2" class="">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><br class=""></body></html>