The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Marc Donner <marc.donner@gmail.com>
To: Clem Cole <clemc@ccc.com>
Cc: tuhs@tuhs.org
Subject: [TUHS] Re: Reaction to the 3B2 at Bell Labs
Date: Sat, 26 Nov 2022 18:00:38 -0500	[thread overview]
Message-ID: <CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com> (raw)
In-Reply-To: <CAC20D2M5XskH+v0kMz3u3c9nvr0odcf0Jr9WVq0Z6+3m9uNvyw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3911 bytes --]

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
,000.

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


On Sat, Nov 26, 2022 at 4:48 PM Clem Cole <clemc@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).
> ᐧ
>

[-- Attachment #2: Type: text/html, Size: 5679 bytes --]

  reply	other threads:[~2022-11-26 23:02 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-26 18:46 [TUHS] " Seth Morabito
2022-11-26 19:18 ` [TUHS] " Larry McVoy
2022-11-26 20:04   ` Seth Morabito
2022-11-26 20:42     ` Rob Pike
2022-11-26 21:46       ` Clem Cole
2022-11-26 23:00         ` Marc Donner [this message]
2022-11-26 23:23           ` Larry McVoy
2022-11-26 23:47             ` Dan Cross
2022-11-27  0:17               ` Larry McVoy
2022-11-27  4:43                 ` Phil Budne
2022-11-27 14:51                   ` John P. Linderman
2022-11-27 15:29                     ` arnold
2022-11-27 16:11                     ` Ron Natalie
2022-11-27 16:59                       ` Warner Losh
2022-11-27 18:59                       ` arnold
2022-11-27 20:45                         ` Rob Pike
2022-11-28 18:53                     ` William Corcoran
2022-11-28 20:59                       ` Kenneth Goodwin
2022-11-28 22:33                         ` ron minnich
2022-11-28 22:43                           ` Marc Donner
2022-11-29  1:49                             ` Alan Glasser
2022-12-01  6:10                               ` Kevin Bowling
2022-12-01  8:30                                 ` Andrew Hume
2022-12-01  8:53                                   ` arnold
2022-12-01  9:19                                     ` Skip Tavakkolian
2022-12-01 12:25                                       ` Brad Spencer
2022-12-01 10:00                                     ` Andrew Hume
2022-12-01 10:17                                       ` arnold
2022-11-27 14:53                   ` Larry McVoy
2022-11-26 19:21 ` Douglas McIlroy
2022-11-29 11:33 ` alan
2022-11-30  2:50 ` Mary Ann Horton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALQ0xCCFgULgCP7_dn8tmuofCMczma=MA3PfVGEi=kAQ1Ba3pQ@mail.gmail.com' \
    --to=marc.donner@gmail.com \
    --cc=clemc@ccc.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).