[ih] when did APRANET -TIPs become known as -TACs

[Jack Haverty]

Hi Steve,

Yes - that's why I said "designed".  The design intent was to look like 
a H316.   The implementation of course had bugs.   But bugs didn't 
matter if the IMP code didn't trigger them.

Our part of BBN tended to be very pragmatic.  In the ARPANET case, the 
focus was on keeping the network functioning, and using whatever 
pragmatic approach fit best.    I don't recall but it's likely that 
changing the C/30 microcode was not as easy as changing the IMP code, 
which was typically done by putting a new release into an IMP at BBN and 
then letting it propagate from IMP to IMP until it had permeated the 
network.   Changing microcode may have required a field service visit, 
but I can't remember if that was true.

Another issue which may have driven such decisions was the timing of 
conversion from Honeywell IMPs to C/30s.  That couldn't happen overnight 
and probably took months or more.   So there was lots of attention paid 
to how to deploy new releases in a methodical way that kept the network 
functioning at all times.

When the assembler was changed to fix a microcode bug, one of the 
factors influencing that decision might have been whether or not all the 
316s had been replaced by C/30s yet.  I don't recall that incident, but 
it seems that lack of object-code compatibility would have been a 
problem if there were still H316s in the network.

Running and evolving the ARPANET was a complicated engineering task.  I 
recall that one of the "IMP guys" once told me that there were about 
1000 parameters then in the IMP code, each of which had been added to 
address some particular issue that had shown up during a decade of 
network operation.  Parameters could be set appropriately for specific 
IMPs by remote action from the NOC. Lots of that kind of detail is 
probably captured in the Quarterly Reports from the ARPANET Operations 
and Maintenance contract we had with DCA -- another source for 
interested historians.

Jack


On 9/28/25 10:41, Steve Crocker wrote:
> Jack,
>
> You wrote:
>
>         The C/30 microcode was designed to make an MBB look
>         exactly like a Honeywell 316.  So the same code that had been
>         developed for the 316-based IMPs (or TIPs) would also run on a
>         C/30. Effectively, a C/30 looked exactly like a Honeywell 316
>         to the software that ran on it.
>
>
> Well, almost.
>
> I ran a program verification project for several years.  We used 
> actual code, i.e. code written by professionals without regard to 
> formal methods, for our case studies.  For our work on microcode 
> verification, we wrote formal descriptions of both the micromachine 
> and the macromachine, and then we attempted to show the microcode 
> implemented the macromachine's instructions set.
>
> The microcode implementation of the 516 instruction set on the C/30 
> was one of our cases.  We found a small set of relatively minor 
> discrepancies.  My favorite discrepancies for the C/30 were the 
> implementations of the Reset Overflow Bit and Set Overflow Bit 
> instructions.  The implementations were reversed.
>
> When we shared our results with the BBN crew, they said they had 
> discovered the microcode was backwards.  But rather than changing the 
> microcode, they had changed the assembler.  Big smile.  That's ok if 
> the code for that machine is guaranteed to be created by the modified 
> assembler.  In the pantheon of practical solutions that occur in real 
> life, I have no criticism.
>
> What I hadn't thought about until reading your note is the code for 
> the Honeywell machines and the C/30 would have been compatible at the 
> assembly language level but not at the object code level.  
> Alternatively, I have no idea if those instructions were actually used 
> in the IMP software.
>
> Steve
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250928/7b7941dc/attachment.asc>