15 Jul
2019
15 Jul
'19
5:55 a.m.
Thanks, this isn't quite everything that I was wondering about, but let
me elaborate.
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 /somebody/ 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.
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.
However, there was a pretty vast commonality in the RSX code base.?
Specifically, I was wondering about two things:
1. What is the latest Phase DECnet that 11M will run?? I guess the last
release was 93?
2. MCB; what was developed on it past your snapshot (Phase II).
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.
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.
Some higher level code was written in BLISS.? I have yet to chase NMLT20
down (the Tops-20 NICE implementation).
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.
They really should have fixed the ^S/^Q padding issue for smooth scroll,
though...
------------------------------------------------------------------------
On 7/14/2019 3:16 PM, John Forecast wrote:
On Jul 14, 2019, at 1:48 PM, Thomas DeBellis
<tommytimesharing at gmail.com <mailto:tommytimesharing at gmail.com>>
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.
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.
The prevailing wisdom is that RSX20F is based on RSX-11D.
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.
I can't remember whether the DN20 would do anything past Phase III.
I was never involved in the IBM communications side so, unfortunately,
I can?t help there.
? John.
>
>> ------------------------------------------------------------------------
>> 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.