[ih] inter IMP hackery [was Recently restored and a small ARPANET was run using simulated IMP hardware, ]

[dave walden]

I can describe the genesis.  The IMP code was originally for one host 
computer and several inter-IMP modems (that was what our contract 
specified), and I coded the IMP/Host and Host/IMP code for that in 
parallel with Bernie coding the DDT, etc. Then some host site wanted a 
second host on its IMP -- I think maybe UCLA for its IBM 360.  ARPA 
called us and asked if the IMP could handle more than one Host.  Our 
hardware guys said the Honeywell computer could support (if I remember 
correctly) up to seven interfaces which could be up to four Host 
interfaces or up to four inter-IMP modem interfaces.  We looked at the 
IMP/Host and Host/IMP code and it seemed fairly easy to make it 
reentrant, so we told ARPANET "yes".  Once the IMP would know how to 
handle multiple Hosts and given there was a bit in the header words 
between IMPs and Host to say "real" Host or "fake" Host, the 
possibilities were fairly clear.  I implemented the reentrant IMP-host 
and host-IMP code, and Bernie changed the routines he had written or was 
writing:
- TTY in/out
- DDT in/out
- parameter change packets into the IMP and trace packets out of the IMP
- into the IMP to be discarded and statistics packets out of the IMP
For the regular reports from IMPs to the Network Monitoring Center, a 
bit of code in the IMP could send packets to a real host; I don't 
remember which of the fake Hosts they looked like they were coming from 
-- stats maybe.

On 9/6/2020 7:30 PM, Bernie Cosell via Internet-history wrote:
> Early on as we were coding the IMP stuff the question arose as to what to do
> about the TTY [and how the hell were we to debug the damn thing].  We did
> several things in this regard.  First I wrote a simple DDT [about as powerful as
> the test-word switches on our PDP-1 :o)] but it allowed us to poke around in the
> dead hulk of the code of a stopped system to see what went wrong and also put
> patches in.  I believe it was originally a stand alone - the imp would crash or hit a
> diagnostic trap and they we could run the DDT and look at buffers and counters
> and pointers and such and generally try to figure out what happened.  When the
> IMP was running solidly enough [which actually happened pretty early on in its
> development],   I can't remember the genesis of the underlying idea, but  we
> thought we could route the DDT *over* the net to other IMPs and poke at *then*.
> I came up with a scheme that Will [I think] thought was way too complicated:
>
>