Whoops, an IBMSPL communications endpoint was called a DN60, not a DN20.
None of that stuff ran over an Ethernet, which IBM did not sell, yet.?
You had to use KMC11's.
On 7/14/2019 1:48 PM, Thomas DeBellis wrote:
I had been wondering about the RSX DECnet packaging.
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.
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.
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.
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.
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.
I can't remember whether the DN20 would do anything past Phase III.
> ------------------------------------------------------------------------
> On 7/5/2019 7:57 PM, John Forecast wrote:
> 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.
>
> [...] 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.