Where should the type information be: in tags and descriptors 432
the imps significantly increased the entry level costs for connecting to the arpanet. furthermore ... with the imps they had a homogeneous network with no requirement for the concept of internetworking of heterogeneous networks and gateways.
i've frequently butterted that was big reason that the internal network
had more nodes than the arpanet-internet from just about the start until around mid-85 (i.e. most of the internal network nodes had the equivalent of gateway and interoperability functionality ... which the apranet-internet didn't get until they converted off the imps to internetworking protocol on 1-1-83).
Where should the type information be: in tags and descriptors 433
The complaints about ODS-RMS are red herrings. The real complaint here is that the tools on a particular OS weren't designed to do what was attempted. Fundamentally...
misc. past threads:
the internal network was nearly 1000 nodes when the arpanet was around 250 nodes. reference to the 1000th node announcement
there were other internal corporate networking protocols ... primarily those run on the primary batch system .... which had evolved out of HASP networking ... some of which seemed to have originated at TUCC (at least some of the code still had "TUCC" label on some of the statemtns). this implementation (which continued well thru the JES incarnations) mapped network nodes into the HASP 255 entry psuedo device table. A typical HASP-JES node might have 60-80 local psuedo devices ... leaving possibly 170-190 entries left for network node defintions (actually less than arpanet). The HASP-JES ndoes had to be restricted to boundary-end nodes since they had implementation that trashed traffic where either the origin node or the destination node was not recognized (with approaching 1000 nodes at the time when the arpanet was only 250 nodes ... HASP-JES nodes would have trashed most of the traffic ... if the internal network was dependent on their implementation).
another failure of the internal batch-platform implementation was that it had mixed up the architecture of the header field defintiions. It was common that traffic between batch-platform nodes at different release or version levels would result in crashing one and-or both systems (networking code as well as the whole operating system). There is the infamous case of traffic originating from a San Jose batch node casuing operating systems in Hurseley (england) to crash.
the gateway capability in the primary internal network nodes was given the responsibility of taking traffic from the batch operating system network nodes and converting them to cannonical format ... and then on the links that directly talked to batch networking nodes ... translating the header format specifically for the version-release node that it was interfacing to.
Alt Folklore Computers Newsgroups