Was FORTRAN buggy 4320

re:

it was worse than that ... NJE grew up out of HASP networking, some amount of it had been done at TUCC. HASP had a one byte index for table of 255 psuedo (spooled) devices that it implemented local spooling. the original networking support scavenged unused entries from that table to define networking nodes. a typical HASP node might have 60-80 psuedo devices defined ... leaving a maximum of 170-190 entries for defining networking nodes. hasp-jes also would trash any traffic where either the originating node or the destination node wasn't defined in the local table. the internal network fairly quickly exceeded 255 nodes

limiting hasp-jes to anything other than a boundary node (pretty useless as an intermediate node that would trash some percent of traffic flowing through). at some point, NJE increased maximum network size to 999 ... but that was after the internal network was over 1000 nodes (again creating network operational problems if JES was used for other than purely boundary nodes).

the other problem was that NJE protocol confused the header fields ... intermingling networking stuff with purely local stuff. not only would misconfigured hasp-jes systems crash other hasp-jes systems ... but it was possible for two different systems (properly configured) at slightly different release levels (with slightly different header formats) to crash each other. there was an infamous scenario where a system in san jose was causing systems in hursely to crash.

as a result, there was a body of technology that grew up in VM networking nodes for simulating NJE. there were a whole library of NJE drivers for various versions and releases of hasp-jes. A VM simulated NJE driver would be started for the specific boundary hasp-JES that it was talking to.

incoming traffic from a boundary NJE node would be taken and effectively translated into a generalized connonical format. outgoing traffic to boundary NJE node would have header formated for the specific hasp-jes release-version. all of this was countermeasure to keep the wide variety of different hasp-jes systems around the world from crashing each other.

misc. other hasp-jes related posts

another characteristic was that the native VM drivers tended to have much higher thruput and efficiency than the NJE protocol. however, at some point (possibly for strategic corporate compatibility purposes) they stopped shipping the native VM drivers ... and only shipped NJE drivers for VM networking.

at some point I believe that bitnet-earn network was also larger than arpanet-internet

bitnet was US educational network using the vm networking technology (however, as mentioned, eventually only NJE drivers were shipping in the vm product). while the internal network and bitnet used similar technologies ... the sizes of the respective networks were totally independent.

earn was the european flavor of bitnet. for some drift, old post mentioning founding-running earn