[HECnet] DAP

[Thomas DeBellis]

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.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20191209/7578d3af/attachment-0001.html>