<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>This is a LONG time ago, but here is what I remembered when
looking at the poor man's routing code.</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>It is not clear at what level VMS is implementing this
transparency.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>We also had a PDP-11/70 running RSTS, but I don't recall anything
about it doing DECnet (circa 1980-1981).<br>
</p>
<p>The Tops-20 anonymous implementation is another story. There
never was any.</p>
<p>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.</p>
<p>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...<br>
</p>
<div class="moz-cite-prefix"><br>
</div>
<blockquote type="cite"
cite="mid:DE5AB7A1-FC53-42B9-A81E-7B11AD12A7BF@comcast.net">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On 12/9/19 5:14 PM, Paul Koning wrote:
</pre>
<pre class="moz-quote-pre" wrap="">
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
<blockquote type="cite"><hr width="100%" size="2"><pre class="moz-quote-pre" wrap="">On Dec 9, 2019, at 5:00 PM, Thomas DeBellis <a class="moz-txt-link-rfc2396E" href="mailto:tommytimesharing@gmail.com"><tommytimesharing@gmail.com></a> 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.
</pre></blockquote></pre>
</blockquote>
</body>
</html>