[TUHS] Reaction to the 3B2 at Bell Labs

Marc Donner marc.donner at gmail.com
Sun Nov 27 09:00:38 AEST 2022

My chronology may be borked, but what I remember from that era is that IBM
was selling the AS/400 very effectively against the VAX by then and was
vacuuming up the market.  The problem was that DEC's theory of sales was to
have engineers sell to engineers, while IBM sold basement servers to chain
stores.  The chains bought these things by the bushel basket.  The HW and
OS were both weird (as seen by the computer scientists at Watson) but
remarkably reliable.  As near as I can tell, this was what ultimately put
DEC under ... I think the 3B2 was collateral damage ... I presume that AT&T
did not really have time to learn how to sell machines to the commercial
market, particularly to the folks who were buying them in numbers ending in

What I learned while watching from the sidelines is that I (and by
extension everyone on this list) was not the target audience.
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>

On Sat, Nov 26, 2022 at 4:48 PM Clem Cole <clemc at ccc.com> wrote:

> Seth, I've often said the only reason they sold any of them was that AT&T
> required you to buy one as the reference system for SVR3 - so anyone that
> wanted to port it tended to buy one 3B2 just to have it as the reference
> box.
> Rob's comment about the BELLMAC-32 was interesting.  I could never quite
> understand why AT&T wanted to create its own microprocessor and associated
> ISA and try to sell it against the other merchant microprocessors (just as
> I never could understand why HP and IBM did either - but they were already
> formally in the computer business).   Selling chips to other people to use
> for their designs is a difficult business that needs a sophisticated sales
> and marketing team.   Even if AT&T could create a technically
> competitive device and get the manufacturing cost structure in line
> with Moto or Intel so that the street price could be competitive, the
> previous sales and marketing scheme of abandoning UNIX on your doorstep was
> not going to work, and it was having a new technical sales support team to
> match Intel and Moto was just not going to happen any time soon.
> Supporting the operating companies is a different beast than supporting,
> say, a start-up trying to build a hot new device -> that company's
> product.   While I suspect Rob and Bart built their own tools for the
> redox of the Blit, Rob I ask you -- truly if you have been outside of AT&T,
> could you imagine trying to use that device? I can't.
> I've told the details of the story elsewhere, and they don't really matter
> here. But I remember being at Masscomp and finding a bug in the new FP chip
> for the 68020 - which was causing a 'stop shop' on our newest product -
> when one of the factory exercisers/diags started to fail.   We were paying
> a premium at the time and Moto's local folks did not want to listen at
> first.  Our head of HW came to me because he knew that I knew a bit about
> the application program they were using as a test from my grad school
> days.   With the end help of the Fortran compiler back-end guys in a few
> hours of debugging, I was able to isolate the chip failure.  Then I wrote a
> new 10-line Fortran example and associated assembler code, which we faxed
> to Moto.  Moto had a 'Technical Consulting Engineer' on the line from
> Austin, and indeed it was validated as a problem, and less than 12 hrs
> later their team had figured out what was going on in the chip.
> I bring this up because I just don't see AT&T has been able to react that
> way, although, in the end, we had to solve it once Moto figure out what the
> cause of the error was (a slow charge circuit was wiping out the exponent
> in R/R instructions under certain conditions - so we changed the compiler
> not generate the sequence so we should still ship).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221126/8f828987/attachment-0001.htm>

More information about the TUHS mailing list