10 Dec
2019
10 Dec
'19
midnight
This is a LONG time ago, but here is what I remembered when looking at
the poor man's routing code.
At the time, Columbia had started CCnet with Carnegie Mellon university
and Case Western was either online or close to it.? I believe DECnet was
still Phase II on the communications processors (DN20's) while the 20
was at Phase III (or maybe I have that backwards).? Whatever the case,
we didn't have full connectivity and one of our monitor developers came
up this hack and DEC later adopted it.? Or maybe I'm delusional.
Larry Campbell (who I had known at Marlboro) appears to have written the
DNCONN code, which is further productized then what I recall we had.
DNCONN has a database with poor man's routing, so that the user can just
type the requested node and the routing is figured out behind the
scenes.? We pretty much ditched everything when we got Phase IV.
It is not clear at what level VMS is implementing this transparency.
For Tops-20, GTJFN% can parse the full network specification
(node::dev:<directory>name.typ.gen;attributes), yet this does not result
in a JFN that can be directly OPENF%'ed (it's parse only).? So you can't
use command line interface (the EXEC) to directly copy things. ? NFT
uses JFNS% JSYS pull out the component parts to build the appropriate
network specification (viz, DCN:NODE-FAL) and then populates the DAP
ACCESS message with the rest of file specification, suitably groveled.
COMND% could easily parse multiple nodes as you've described and this
could have been put into the EXEC.? I don't remember why we didn't do
that; we were seriously into 'automatic-nice-things'.? I believe there
may have been concerns about overhead and stability.? We had had
problems with early versions of DAPLIB and the management interface
(NMLT20) was a pure horror show for quite some time; it crashed all the
time and we didn't have source to fix it.? It all certainly improved.
This is why I was surprised to find some of the problems that I did;
they popped up as soon as I got my systems onto HECnet and started doing
testing.
We also had a PDP-11/70 running RSTS, but I don't recall anything about
it doing DECnet (circa 1980-1981).
The Tops-20 anonymous implementation is another story.? There never was any.
Ours was a true hack.? On CCnet, if you wanted to host anonymous
service, you had to create a user id named 'ANON', password 'ANON',
account 'ANON'.? A full fledged id...? The reason for the user and
account restrictions was due to Carnegie Mellon; their accounting system
had been inherited from an MVS CICS application where user id's were
(and still are) limited to four characters (regular TSO ids can be
longer).? That id was then locked down elsewhere in the system.
Having completed my CSSLP and due for my CISSP, when I considered that
approach in this day and age, I was, well, pretty horrified. Different
times...
------------------------------------------------------------------------
On 12/9/19 5:14 PM, Paul Koning wrote:
Poor man's routing applies in two places. In Phase II, to allow you to talk to a
non-neighbor node (without benefit of "intercept" support). And later on, to
allow Phase III nodes to talk out of area and Phase IV nodes to talk to "hidden
area" nodes. These two were I think internal to DEC, because the internal DECnet was
too large for the architecture.
There seem to be two approaches to poor-man's routing: VMS did it in DAP without any
extra protocol machinery, simply because of the fact that VMS RMS lets you specify file
names that start with a node name. So a request for STAR::FRODO::foo.txt is handled by
STAR doing "transparent network access" to file FRODO::foo.txt.
In other applications, poor man's routing would be handled by noticing more than one
node name in the destination specification, which would tell it to connect to the PMR
(PSTHRU) object instead of the usual object. I've been trying to reverse engineer
that; unfortunately I don't seem to have any RSTS applications that call this.
Strange, because I'm fairly sure we had a "set host" client that did.
Fairly recently I saw the TOPS-10 (or -20?) PMR, but my MACRO-10 skills are terribly
rusty.
paul
> ------------------------------------------------------------------------
> On Dec 9, 2019, at 5:00 PM, Thomas DeBellis <tommytimesharing at gmail.com>
wrote:
>
> I would be surprised if there needed to be any updates to DAP to support Phase V as
Phase V doesn't change the programming API in a significant enough way (if at all) as
to require corresponding changes to DAP.
>
> As long as it can make a connection and check connection status, Etc., it seems happy
enough. It doesn't talk to the management layer at all, as far as I can tell.
>
> There is some Phase II era code, which was put in to allow a kind of "poor
man's" routing. Now I would guess that it would only be useful for a
non-adjacent node to talk to a DN200.
>