HASPASP JESJES2JES3 2392

ref:

in fact, folkore is that HASP-JES2 nodes on the internal network ... before NJE was released to customers ... still carried "TUCC" in cols. 67-70 of the source.

before NJE was released, it was being used in the corporate internal network (which was larger than arpanet-internet from just about the beginning until possibly mid-85)

the internal network was primarily based on networking code developed at science center

and effectively contained a kind of gateway architecture built into every node from the start.

this immensely buttisted in dealing with the NJE nodes. basically the NJE support used the hasp psuedo device table to define network nodes (one byte, 256 entries). a typical NJE configuration might have 60-80 defined psuedo-devices leaving possibly 170-190 entries for network node definitions. NJE also had characteristic if that either the origin or the destination nodes weren't in the local table, it trashed the traffic. Even before NJE shipped to customers, the internal network was over 255 nodes ... and you couldn't trust a NJE node to be anything other than a pure edge node ... and not to be trusted as a internal network backbone node (forwarded traffic between nodes).

eventually NJE did expand support to 999 nodes ... however that was after the internal network had exceeded 1000 nodes (which met that NJE still couldn't occupy a major backbone posbreastion) ... minor reference:

to commemorate the 1000th node event there was a clear plexiglbutt globe (about 3" diameter) with abstract representation of world network and logo about 1000 nodes. It sat in a tripod formed by three clear plexiglbutt rods (i've got one in my desk drawer).

NJE also had a shortcoming that it mixed up data attribute information and network information in the header. With the intermingling of header information ... NJE systems were notorious for bringing down MVS when trying to handle NJE data that had originated from another HASP-JES2 system that was running a different version ... and incompatible header information.

One of the solutions was to create custom gateway drivers in the primary networking implementation that compensated for NJE confusion with handling data from other, incompatible NJE systems. Basically, it became the responsibility of the gateway code to create canonical representation of NJE header information ... and then a custom, specific gateway driver would be started that corresponded to the NJE version that it directly talked to. It was the responsibility of the custom gateway driver to re-arrange the header bits to correspond to the specific NJE version (as countermeasure preventing MVS system crashes). Somewhere in this timeline there was an infamous incident of JES2 systems in San Jose causing MVS systems in Hursley to crash.

In many ways the NJE architecture was similar to the original arpanet design in that it was a homogeneous implementation (as were many other network architectures from the 60s & 70s; and the arpanet was also effectively limited to 255 nodes). The great conversion of arpanet-internet on 1-1-83 to tcp-ip ... gave it gateway functionality .. which it brought it more inline with the technolgoy of the main core of the internal network.

misc. past posts mentioning NJE

--