25 years ago today...
Mark Crispin
cancelled Project Jupiter and killed the PDP-10.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
Pat Farrell
> At 2PM Eastern Daylight time on May 17, 1983, Ken Olsen and Bill Johnson
> cancelled Project Jupiter and killed the PDP-10.
We were told within hours, and that killed all future work at AMS on our
six DECsystem-20s. We kept them running, I stayed with them for nearly
two years, we did some minor Vax work, but it was all over but the shouting.
bob
Every year, I ask myself why do we all still care? Why do I still care?
I left the team in 81, knowing the time was running out, and knowing it
would be the end. An end of an era. XKL gave some hope, I had a few 10s
running when the TD was announced. There was a brief spark of hope. Now
there is KLH, Panda distro, Bob's emulator, and the king lives on.
bob
jmfbah
> At 2PM Eastern Daylight time on May 17, 1983, Ken Olsen and Bill Johnson
> cancelled Project Jupiter and killed the PDP-10.
Cancelling the Jupiter didn't kill the PDP-10 architecture. Not
approving the PDP-10 desktop project proposal did.
/BAH
jmfbah
> Mark Crispin wrote:
>> At 2PM Eastern Daylight time on May 17, 1983, Ken Olsen and Bill
>> Johnson cancelled Project Jupiter and killed the PDP-10.
>>
>> -- Mark --
>>
>> http://panda.com/mrc
>> Democracy is two wolves and a sheep deciding what to eat for lunch.
>> Liberty is a well-armed sheep contesting the vote.
>
> Every year, I ask myself why do we all still care? Why do I still care?
Because it killed DEC, not the PDP-10.
> I left the team in 81, knowing the time was running out, and knowing it
> would be the end. An end of an era.
Nah, not an era but the end of DEC.
> XKL gave some hope,
But they didn't get TOPS-10 up. Although most here will poohpooh that,
it is when the TOPS-10 stuff stopped that DEC stopped. The -20 was
diverging from the DEC-style at the beginning.
>I had a few 10s
> running when the TD was announced. There was a brief spark of hope. Now
> there is KLH, Panda distro, Bob's emulator, and the king lives on.
> bob
If you live long enough, you will see that Bob's work will be seen
at significant.
/BAH
Mark Crispin
> But they didn't get TOPS-10 up.
Bullshit.
A lot of people put a lot of work into getting Bottoms-10 running on
post-DEC processors (including KLH10). Most of the SC processors were
sold to CompuServe which ran their heavily-modified early 5-series
Bottoms-10 on it.
Other than CompuServe, there was no demand for Bottoms-10 back then. It
was totally, utterly, obsolete by the mid 1970s. By the 1980s most
Bottoms-10 systems had moved on to TOPS-20, VMS, UNIX, or other systems.
You keep harping on Bottoms-10 SMP, completely ignoring the fact (which
people are trying to explain to you) that it was based upon ancient
hardware design that no longer exists and will never exist again. Nobody
does SMP that way any more. Nobody ever will.
> Although most here will poohpooh that,
> it is when the TOPS-10 stuff stopped that DEC stopped. The -20 was
> diverging from the DEC-style at the beginning.
That is the same sort of inane rant that RMS gives for the demise of ITS
at MIT. Without TOPS-20, the PDP-10 would have died about the same time
as the PDP-15 and for the same reasons.
1969-1970 was a watershed period in operating systems design, marking the
birth of both Tenex (which became TOPS-20) and UNIX (VMS came several
years later). Everything before that time was obsoleted and is gone.
Pat Farrell
> Cancelling the Jupiter didn't kill the PDP-10 architecture. Not
> approving the PDP-10 desktop project proposal did.
When the customers needed bigger iron, it did. The world did not need
yet another incompatible desktop from DEC. They already had three that
were self incompatible.
--
Pat Farrell
http://www.pfarrell.com/
Pat Farrell
> At 2PM Eastern Daylight time on May 17, 1983, Ken Olsen and Bill Johnson
> cancelled Project Jupiter and killed the PDP-10.
Mark,
I can still remember your rant at Decus about Stanford never buying
another closed, proprietary computer from clueless marketoids.
Been curious for nearly 25 years, did Stanford actually do what you
suggested?
Mark Crispin
> Been curious for nearly 25 years, did Stanford actually do what you
> suggested?
I haven't been at Stanford for nearly 20 years, but as far as I know,
their primary computing platform remains open source and open
architecture.
Not that that is difficult to accomplish today. Macintosh is the closest
thing today to the sort of vendor-lockin that existed with PDP-10 and VAX.
However, Macintosh does not have nearly the grip on application
programmers (or users) that PDP-10 and VAX did. No UNIX application is
locked onto Macintosh; and X-based GUI programs aren't locked either.
The relative paucity of Macintosh-specific GUI programs attests to the
fact that many developers continue to eshew such proprietary platforms.
Most Macintosh applications programs are ports of software originally
created on Windows and/or UNIX. There are few "exclusively on Macintosh"
applications, much less "killer" Macintosh-only applications.
Even Apple's critical applications have Windows versions. Not even Steve
Jobs, nor the "ooh! shiny" effect, would have made iPod successful if
there was not a Windows version of iTunes.
Windows is a different animal. It is proprietary software, but it is not
tied to a closed hardware architecture. You can build your own x86 based
system from components and Microsoft will be happy to sell you Windows for
it. As long as you use more or less common components, Windows will even
run.
So, yes, I think that Digital killed the goose that laid the golden egg;
and that goose has not come back to life. There is no doubt that Apple
would like to have that goose alive again; they're doing their level best
to make that happen! But the sole reason for Apple to exist is to keep
Microsoft honest; and deep down inside both know it.
Mark Crispin
>> Cancelling the Jupiter didn't kill the PDP-10 architecture. Not
>> approving the PDP-10 desktop project proposal did.
> When the customers needed bigger iron, it did. The world did not need yet
> another incompatible desktop from DEC. They already had three that were self
> incompatible.
If Digital had made a desktop PDP-10, it would have had an MLP of $50K for
the CPU (with 2020 class performance) and would have required Massbus
peripherals.
Digital had no clue of the personal computer revolution, just as they had
no clue of UNIX. Take a look at their contemporary offerings: GIGI,
Rainbow, Professional. VAX 2000 was their first machine that betrayed any
hint of understanding, and it was ridiculously slow and expensive.
There was, and would have remained, a niche for PDP-10 in the server
space. It took a long while to fill that space after Digital forfeited
it.
Pat Farrell
> If Digital had made a desktop PDP-10, it would have had an MLP of $50K
> for the CPU (with 2020 class performance) and would have required
> Massbus peripherals.
I paid $5000 for a 5mb disk for a Pro-350. The RP06s for our KLs were
only $30,000 each.
Does massbus imply Three phase too?
Mark Crispin
>> If Digital had made a desktop PDP-10, it would have had an MLP of $50K for
>> the CPU (with 2020 class performance) and would have required Massbus
>> peripherals.
> I paid $5000 for a 5mb disk for a Pro-350. The RP06s for our KLs were only
> $30,000 each.
About $1000/MB for the Pro disk, and about $400/MB for the RP06.
> Does massbus imply Three phase too?
No, RM03s were 110V single phase. Like the TU77/TU78, RM05s ran on 208V
(two legs of 3-phase), or 220V single phase if you did a minor rewiring of
the power supply.
IIRC, RP06s required three phase, but didn't really need it. Again IIRC,
it was just like the RM05 in needing a 110V source for the controller and
a 208V/220V source for the disk, although it had its own integrated
controller instead of a separate unit. Three phase was just the easiest
way to do it with a single power cord.
jmfbah
> jmfbah wrote:
>> Cancelling the Jupiter didn't kill the PDP-10 architecture. Not
>> approving the PDP-10 desktop project proposal did.
>
> When the customers needed bigger iron, it did. The world did not need
> yet another incompatible desktop from DEC. They already had three that
> were self incompatible.
>
Having an SMP system that would take a footprint of a closet would
have continued sales for another 5-10 years. This would have given
VMS and its hardware enough time to mature.
/BAH
Tim Shoppa
> On Sun, 18 May 2008, Pat Farrell posted:
> > jmfbah wrote:
> >> Cancelling the Jupiter didn't kill the PDP-10 architecture. Not
> >> approving the PDP-10 desktop project proposal did.
> > When the customers needed bigger iron, it did. The world did not need yet
> > another incompatible desktop from DEC. They already had three that were self
> > incompatible.
>
> If Digital had made a desktop PDP-10, it would have had an MLP of $50K for
> the CPU (with 2020 class performance) and would have required Massbus
> peripherals.
In the very early 80's, yeah, it's not suprising that it was drawn
that way for the more senior (e.g. older) management, just to get it
approved. After all, even lesser CPU's (e.g. the VAX 11/750) pretty
much needed Massbus peripherals too IF YOU USE THE SAME MINDSET.
DEC's low-end storage mindset was spectacularly stunted but for other
desktop products - even if they began without support for it - the
lousy but cheap MFM drives soon became an option, either through DEC
or through third-party vendors.
Actually, the low-end mass storage options available in the very early
80's were pretty disappointing. If I had to throw together a design,
even for a desktop machine, in the early 80's I would've leveraged the
SMD drives too. It's a little unfortunate that this usually (but not
always) meant Massbus inside DEC. (There was at least one exception!)
> Digital had no clue of the personal computer revolution, just as they had
> no clue of UNIX. Take a look at their contemporary offerings: GIGI,
> Rainbow, Professional. VAX 2000 was their first machine that betrayed any
> hint of understanding, and it was ridiculously slow and expensive.
I was completely flabbergasted when I first saw a VS2000 on a desk,
clustered into our departmental 11/780 via nothing more than a coax
cable. It was the first time that I had seen something actually useful
going over Ethernet, and I had fully expected that to reach a cluster
you needed a cable at least as thick as a Massbus cable or two :-).
Of course for years I had had more CPU power on my desk (e.g. a KDJ11,
which would beat the pants off a 11/780 or VS2000 in benchmarking the
apps I was working on.)
Tim.
titan
> Mark Crispin wrote:
> > At 2PM Eastern Daylight time on May 17, 1983, Ken Olsen and Bill Johnson
> > cancelled Project Jupiter and killed the PDP-10.
June 8, 1983
Dear Customer:
As you may be aware, Digital has announced a change of focus in the
DEC 10/20 development
strategy. This decision provides for a further integration of DEC
10/20 computers into the
Digital information architecture and eliminates development of a
follow-on 36-bit processor.
For many years, Digital has been the leader in distributed data
processing and interactive
timesharing. As these concepts have matured, we have seen an
evolutionary trend beginning
to change our customers computing needs. Our goal as a vendor is to
meet those changing
needs with advances in technology.
One of the changes we see happening is a movement toward an
Information Architecture; that
is, the ability to easily use information at every level within an
organization, from personal computers to mainframes. Digital has
provided an early industry leadership to link
together that diverse computing community through the Digital System
Interconnect Architecture (clusters) and our networking products
(DECnet and Ethernet).
This recent decision will focus our future high-end hardware
development on our more broadly
based VAX family of products and will concentrate DEC 10/20 resources
on the integration of
current KL-based systems into this Digital Information Architecture.
Support of existing DEC 10/20 products will continue including further
development of communications capabilities, associated hardware and
software support for the TOPS-20, TOPS-10
operating systems, and our new mass storage offerings. In addition, we
are committed to
invest incremental software resources to allow DEC 10/20 users to be
gracefully integrated
into Digital's integrated computing architecture.
Computer clusters and our integrated architecture allow customers to
share their computing load among multiple processors and permit easy
addition of processors, file servers and workstations when more
computer power is required. This can be accomplished in a cost
effective manner which preserves past investments and supports new
applications.
We understand that any change in direction raises concerns. Our
committment to you is to provide the best set of products to meet your
needs in the years ahead and to protect your
current investments. We believe this program will do both. As
distributed processing moves
forward to include high end systems, local area networks, shared file
systems, and personal
computers, we will make sure DEC-10 and DEC-20 users will be
integrated into this new system
environment.
To understand and prioritize our customers needs, we are working with
the LCG SIG. The
questionnaire which is enclosed is one of the ways to make sure we
understand your requirements in a timely manner. Please help us by
responding. Thank you for your continued
support.
Sincerely,
Rose Ann Giordano
Product Group Manager
Large Computer Group
DIGITAL EQUIPMENT CORPORATION. 200 FOREST STREET MASSACHUSETTS 01752
===================================
DIGITAL I N T E R O F F I C E
M E M O R A N D U M
TO: ALL FIELD SALES PERSONNEL DATE: 6/13/83
FROM: JACK SHIELDS
FROM: ROSE ANN GIORDANO
DEPT: FIELD OPERATIONS
DEPT: LARGE COMPUTER GROUP
Ms: OG01-2/R12 DTN: 276-9890
Ms: MR2-2/8D2 DTN: 231-4049
SUBJECT: LCG INTEGRATION STRATEGY
As YOU ARE AWARE, THE CORPORATION HAS ANNOUNCED A CHANGE OF FOCUS IN
DIGITAL’S HIGH-END PRODUCT SPECTRUM.
SINCE THIS AFFECTS OUR BIGGEST AND MOST PRESTIGIOUS CUSTOMERS, IT IS
IMPORTANT THAT EVERY FIELD PERSON UNDERSTANDS HOW WE INTEND TO PROTECT
OUR CUSTOMERS’ CURRENT INVESTMENTS AND SATISFY THEIR GROWTH NEEDS WITH
DIGITAL'S FULL SPECTRUM OF PRODUCTS.
THE CHANGE IN FOCUS WAS ANNOUNCED AT US DECUS ON MAY 23RD. IT PLACES
THE EMPHASIS ON INTEGRATING - CURRENT AND FUTURE HIGH-END SYSTEMS INTO
THE DIGITAL DISTRIBUTED COMPUTING ARCHITECTURE. THIS WILL RESULT IN A
FULLY INTERCONNECTED ARCHITECTURE FROM PERSONAL COMPUTERS, THRU
DEPARTMENTAL SYSTEMS TO LARGE MAINFRAME CLASS SYSTEMS. THE COMPUTER
INTERCONNECT (CI) AND ETHERNET (NI) ANNOUNCEMENTS MADE RECENTLY BY
DIGITAL ARE THE BUILDING BLOCKS FOR THIS ARCHITECTURE.
THE DEVELOPMENT OF A FOLLOW-ON KL PROCESSOR, WHICH WAS CODE NAMED
JUPITER, HAS BEEN STOPPED. INCREMENTAL SOFTWARE INVESTMENT WILL BE
MADE TO FURTHER INTEGRATE DECSYSTEM 10/20s INTO THIS DISTRIBUTED
COMPUTING ARCHITECTURE.
ATTACHED IS THE INITIAL STRATEGY AND PROGRAM PLANS WHICH WE WILL USE
TO PROTECT THE CUSTOMERS INVESTMENT AND SATISFY THEIR GROWTH NEEDS.
IMPLEMENTATION OF LCG'S INTEGRATION STRATEGY
I. LCG'S PRODUCT DIRECTION:
ON MAY 23RD AT THE U.S. DECUS SYMPOSIUM A SHIFT IN THE LCG
PRODUCT DIRECTION WAS ANNOUNCED. THIS ANNOUNCEMENT WAS
PRECEEDED BY A BRIEFING SESSION THE PREVIOUS WEEK FOR MEMBERS
OF THE SALES FORCE.
THE PURPOSE OF THIS DOCUMENT IS TO INSURE THAT YOU ARE FULLY
INFORMED OF THE NEW INTEGRATION STRATEGY; HOW IT EFFECTS THE
DECSYSTEM 10/20 CUSTOMER COMMUNITY AND SUPPORT PLANS TO HELP
YOU IN THE CUSTOMER ENVIRONMENT.
THE NEW PRODUCT DIRECTION CAN BE SUMMARIZED BY THE FOLLOWING
POINTS:
- THERE WILL BE NO FOLLOW-ON PROCESSOR,TO THE CURRENT KL
CPU OF THE DECsystem-10 AND DECSYSTEM-20 FAMILY.
- THERE WILL BE A MAJOR FOCUS ON THE DECsystem-10 AND
DECSYSTEM-20 PRODUCTS THAT ALLOW INTEGRATION INTO
DIGITAL'S DISTRIBUTED COMPUTING ARCHITECTURE. THESE
INCLUDE:
- COMPUTER INTERCONNECT (CI)
- MASS STORAGE SUBSYSTEMS (HSC-50, RA81, RA60, ETC.)
- COMMON FILE SYSTEM ~ TOP-20 - (CFS-20)
- NETWORK INTERCONNECT (NI)
- NI ASSOCIATED CONCENTRATORS, SERVERS, ETC.
- ENHANCED SOFTWARE INTEGRATION TOOLS
- THE DECsystem~10 AND DECSYSTEM-20 SYSTEMS WILL CONTINUE
TO BE ENHANCED IN THE AREAS OF:
- OPERATING SYSTEMS
- LAYERED PRODUCTS (LANGUAGES, ETC.)
- COMMUNICATION PRODUCTS
- STATE-OF~THE-ART PERIHERALS
COMPANY CONFIDENTIAL
6/13/82 PAGE 1
II. RECOMMENDED FIELD ACTIONS:
- REVIEW ANNOUNCEMENT WITH SALES MANAGEMENT/AccoUNT TEAM.
- PRIORITIZE LCG ACCOUNTS.
- MAKE CUSTOMER AWARE OF ANNOUNCEMENT
- EMPHASIZE NEW DIRECTION/STRATEGY OF INTEGRATION (SECTION
V/VI)
-
LISTEN TO CUSTOMER CONCERNS
- SCHEDULE FOLLOW UP "WORKING” MEETING TO REVIEW SPECIFIC,
ACCOUNT NEEDS/SOLUTIONS
- SCHEDULE DISTRICT/GEOGRAPHIC SUPPORT TEAMS TO VISIT
ACCOUNTS
- CONTINUE PLANNING PROCESS WITH ACCOUNT TO ENSURE DEC
REMAINS AS A PLANNING PARTNER
- OBTAIN CUSTOMER INPUT AS TO WHAT SOFTWARE COMPATABILITY
TOOL ARE NEEDED TO IMPLEMENT INTEGRATION STRATEGY
- UTILIZE AVAILABLE RESOURCES (SALES MANAGEMENT, MANAGEMENT
CENTER, PRODUCT GROUP, SUPPORT TEAMS)
- REDRAFT ACCOUNT PLAN TO IMPLEMENT INTEGRATION STRATEGY
III. POTENTIAL CUSTOMER REACTIONS:
- MANY CUSTOMERS WILL NOT BE ADVERSLY EFFECTED
- SOME CUSTOMERS WILL HAVE STRONG NEGATIVE REACTIONS
ALLOW CUSTOMER TO VENT FRUSTRATION
ABOVE ALL, LISTEN AND DETERMINE TRUE NEEDS
AFTER INITIAL REACTION MOST CUSTOMERS ARE WILLING
TO EXPLORE MEANINGFUL DIGITAL SOLUTIONS
- SOME CUSTOMER WILL WELCOME THE INTEGRATION INTO DEC's
“MAINSTREAM" (ADVANTAGES OF MORE AGRESSIVE PRICE PERFORMANCE)
COMPANY CONFIDENTIAL
6/13/82 PAGE 2
IV. SUPPORT STRATEGIES:
SUPPORT FOR LCG CUSTOMERS WILL BE PROVIDED IN SEVERAL FORMS
FROM DIGITAL CORPORATE AND FIELD RESOURCES. THESE SUPPORT
PROGRAMS ARE:
DISTRICT/GEOGRAPHIC CUSTOMER SUPPORT TEAMS
- DISTRICT/GEOGRAPHIC CUSTOMER SUPPORT TEAMS WILL MEET
- WITH' A MINIMUM OF THE TOP 100 LCG CUSTOMERS TO ASSIST
IN PLANNING THE INTEGRATION STRATEGY.
- THE DISTRICT/GEOGRAPHIC SUPPORT TEAMS WILL CONSIST OF
VAX/VMS EXPERTISE, LCG EXPERTISE, NETWORKS EXPERTISE, THE ACCOUNT
MANAGER AND WILL BE HEADED BY AN EXPERIENCED TEAM LEADER.
- THE SUPPORT TEAMS WILL DO AN ON-SITE APPLICATIONS AUDIT OF THE
CHOSEN ACCOUNTS. FROM THAT AUDIT A REVISED ACCOUNT PLAN WILL BE
DEVELOPED. AREA
MANAGEMENT CENTERS WILL REVIEW AND APPROVE THE
ACCOUNT PLANS AND PROVIDE SUPPORT FOR THE REQUIRED
BUSINESS ISSUES. THE PLAN WILL THEN BE PRESENTED TO
THE CUSTOMER WITH FOLLOW THROUGH TO BE PROVIDED BY
THE ACCOUNT MANAGER AND SUPPORT TEAM.
- THE DISTRICT/GEOGRAPHIC SUPPORT TEAM WILL ALSO BE SUPPORTED BY
SOFTWARE SERVICES INCLUDING THE
ORPORATE OPERATIONS GROUP (COG),AND BY SOFTWARE
ENGINEERING, WHO WILL PROVIDE TECHNICAL LIASON FOR
NEW PRODUCTS.
- EACH SUPPORT TEAM WILL BE ABLE TO SUPPORT APPROXIMATELY TWO
CUSTOMERS PER MONTH; THEREFORE
DISTRICTS/GEOGRAPHIES WITH LARGE CONCENTRATIONS OF
LCG CUSTOMERS WILL HAVE MORE THAN ONE SUPPORT TEAM.
- MANAGEMENT CENTERS/AREAS
- THE MANAGEMENT CENTERS/AREAS WILL BE THE FOCAL POINT FOR LCG
CUSTOMERS SUPPORT. THEY WILL COORDINATE ALL RESOURCES REVIEW ALL
ACCOUNT PLANS
AND PROVIDE THE NECESSARY BUSINESS SUPPORT ON AN
ACCOUNT BY ACCOUNT BASIS.
COMPANY CONFIDENTIAL
6/13/82 PAGE 3.
- LCG MARKETING GROUP
THE LCG MARKETING GROUP, WILL PROVIDE SUPPORT BY:
- PRIORITIZING THE TOP 100 ACCOUNTS WITH THE US AREA MANAGEMENT
CENTERS;
- RECOMMEND BUSINESS STRATEGY BY ACCOUNT TO THE US AREA
MANAGEMENT CENTERS;
- PROVIDE THE “INTEGRATION STRATEGY” TO THE MANAGEMENT CENTERS,
AREAS, FIELD AND DEVELOP SUPPORTING PRESENTATION MATERIALS;
- DEVELOP THE THIRD PARTY SOFTWARE APPLICATION INTEGRATION
STRATEGY;
- PROVIDE PRODUCT AND MARKET REQUIREMENTS TO ENGINEERING;
- PROVIDE AND DRIVE SUPPORT PLANS WITH SERVICE GROUPS (FIELD
SERVICE, EDUCATIONAL SERVICES, SOFTWARE SERVICES);
- PROVIDE BACKUP TECHNICAL EXPERTISE IN SUPPORT OF
DISTRICT/GEOGRAPHIC SUPPORT TEAMS;
- ASSIST MANAGEMENT CENTERS AND AREAS IN SUPPORT OF LCG’s
LARGEST ACCOUNTS.
- DECUS
- IN ADDITION TO THE DIGITAL SUPPORT PROGRAMS ABOVE, THE DECUS
ORGANIZATION, THROUGH THE LARGE SYSTEM SIG, AND WITH LCG
PRODUCT GROUP INVOLVEMENT, HAS - DEVELOPED A QUESTIONAIRE WHICH-
WILL BE SENT TO ALL LARGE SYSTEMS CUSTOMERS WHO ARE' MEMBERS
OF DECUS. THE GOAL OF THE QUESTIONAIRE IS TO IDENTIFY KEY
CUSTOMER CONCERNS AS A RESULT OF THE CHANGE IN DIGITAL'S HIGH
END STRATEGY AND TO HELP DIGITAL PRIORITIZE THOSE CONCERNS
AND BEGIN TO IDENTIFY SOLUTIONS FOR THEM. ALSO, THIS WILL
PROVIDE THE KEY MECHANISM FOR PRIORITIZING THE INTEGRATION
TOOLS.
V. DIGITAL'S STRATEGY: DISTRIBUTED SYSTEM ARCHITECTURE
THE INCREASED USE OF COMPUTING THROUGHOUT ALL LEVELS IN LARGE
ORGANIZATIONS, AS EVIDENCED BY PERSONAL COMPUTERS, COUPLED WITH THE
ADVENT OF LOCAL AREA NETWORKS CLEARLY SIGNALS A NEW DIRECTION FOR
COMPUTING. DIGITAL RECOGNIZES THIS NEW DIRECTION AND HAS A PRODUCT
STRATEGY IN PLACE TO MEET THE EVOLVING NEEDS OF ITS CUSTOMERS.
THIS STRATEGY ANTICIPATES THE NEEDS FOR A BROAD RANGE OF PROCESSING
POWER FROM DESK~TOP TO MAINFRAMES~ AVAILABLE CONVENIENTLY TO USERS
THRU AN INTEGRATED INFORMATION NETWORK. THE INFORMATION NETWORK
CONSISTS OF INTERCONNECTS BETWEEN SYSTEMS AND USERS, LOCALLY AND LONG
HAUL.
COMPANY CONFIDENTIAL
6/13/82 PAGE 4
A KEY ELEMENT OF DIGITAL'S STRATEGY IS THAT IT SUPPORTS CURRENT
APPLICATIONS AS WELL AS ALLOWING CUSTOMERS TO EXTEND THESE AND NEW
APPLICATIONS INTO AN INFORMATION NETWORK. THIS CAPABILITY IS UNIQUE IN
THE INDUSTRY AND REPRESENTS A SUBSTANTIAL ADVANTAGE OVER
COMPETITION.
CUSTOMERS WILL BE IMPLEMENTING THIS DISTRIBUTED INFORMATION
ARCHITECTURE OVER A RELATIVELY LONG TIME PERIOD AND WILL DO SO IN
DISCRETE STEPS. DIGITAL WILL BE RELEASING A SERIES OF PRODUCTS OVER
TIME WHICH WILL SUPPORT CUSTOMERS IN THE IMPLEMENTATION. THE ATTACHED
“OVERIEW OF DIGITAL’S PRODUCT PLAN AND SYSTEMS ARCHITECTURE” PROVIDES
AN OUTLINE OF THIS PLAN.
VI. RECOMMENDED STRATEGY FOR LCG ACCOUNTS:
THE LCG STRATEGY IS TO HAVE OUR LCG CUSTOMERS CONTINUE TO GROW WITH
DIGITAL. THE ABILITY TO MEET THE CUSTOMERS GROWTH NEEDS IN THE SHORT
TERM WHILE ALLOWING HIM TO SLOWLY INTEGRATE HIS USERS ON ARCHITECTURE
THAT WILL GO FROM PC'S TO LARGE MAINFRAMES IS UNIQUE IN THE INDUSTRY.
WITH THIS GRACEFUL INTEGRATION STRATEGY, OUT GOAL IS TO PROTECT THE
CUSTOMERS INVESTMENT BY MINIMIZING DISRUPTION OF THE USERS.
THE CUSTOMER HAS BEEN SUCCESSFUL BY USING DEC-10/20 PRODUCTS. HE CAN
CONTINUE THIS SUCCESS IN HIS OWN CORPORATION BY GROWING WITH DIGITAL,
USING THIS STRATEGY TO ACQUIRE MORE PROCESSING POWER, PROTECT THE
SOFTWARE INVESTMENT AND HAVING AVAILABLE THE BROADEST RANGE OF
PRODUCTS
IN THE INDUSTRY. FOR THE SALES FORCE, THIS WILL MEAN INCREMENTAL SALES
OF DEC-10/20, VAX'S AND PC'S FOR THE COMING YEAR.
LCG STRATEGY
o TOPS-10/20 SYSTEMS WILL CONTINUE TO BE GOOD
SOLUTIONS FOR THE MAJORITY OF CUSTOMERS. THESE
SYSTEMS ARE THE BEST AT WHAT' THEY DO AND WILL
CONTINUE TO BE SO FOR YEARS TO COME. GROWTH OF
CURRENT APPLICATIONS SHOULD BE MET WITH DEC-10/20s USING THE NEW
CFS-20 (COMMON FILE SYSTEM), HSC AND RA81.
O VAXs AND PCS SHOULD BE ADDED AS NEW APPLICATIONS ARE BROUGHT UP. IN
THIS MANNER, NEW APPLICATIONS
WILL BE BROUGHT UP UNDER THE 32 BIT ARCHITECTURE
WITH MINIMAL DISRUPTION OF USERS. IN ADDITION
USERS WITH VAXS AND 10/20s WILL BE ABLE TO
INTERCHANGE DATA VIA DECNET.
COMPANY CONFIDENTIAL
6/13/82 PAGE 5.
o VAX CLOSELY INTEGRATED WITH DEC-10/20s WILL ALLOW A MODULAR APPROACH
TO EXPANSION. IN ADDITION, CUSTOMERS WILL BENEFIT BY HAVING MORE
APPLICATIONS
PACKAGES, QUICKER INTEGRATION OF PCS, ACCESS TO
THE OFFICE SYSTEMS, AND AN ABILITY TO BRING
ETHERNET QUICKLY AND GRACEFULLY INTO THEIR
ENVIRONMENT.
o TOPS-10 TO TOPS-20 MIGRATION SHOULD BE LOOKED AT ON A CASE BY CASE
BASIS. WITH THE NEW STRATEGY
HOWEVER, INTEGRATING TOPS-10 WITH VMS POSITIONS
THE CUSTOMER TO TAKE, ADVANTAGE OF THE FOLLOW ON
HIGH-END SYSTEMS SOONER.
o THE FASTEST GROWING CUSTOMERS, OR CUSTOMERS WITH MULTIPLE DEC-10/20s
SHOULD BE WORKED AS INDIVIDUAL ACCOUNTS. THE FACT THAT THE FOLLOW ON
VAX WILL BE
OUT MUCH SOONER THAN JUPITER WAS PROPOSED, CAN BE
AN ADVANTAGE TO THIS CUSTOMER. GROWTH SHOULD BE
MET INCREMENTALLY WITH DEC-10/20 WHILE VAXS ARE USED TO PREPARE THE
ACCOUNTS FOR THE FOLLOW ON
HIGH-END SYSTEMS.
COMPANY CONFIDENTIAL
6/13/82 PAGE 6
Mark Crispin
> I was completely flabbergasted when I first saw a VS2000 on a desk,
> clustered into our departmental 11/780 via nothing more than a coax
> cable. It was the first time that I had seen something actually useful
> going over Ethernet, and I had fully expected that to reach a cluster
> you needed a cable at least as thick as a Massbus cable or two :-).
I think that you need to insert the words "from Digital" in that sentence
somewhere, e.g., "anything useful from Digital going over Ethernet".
VS2000 was indeed revolutionary -- for Digital. For those of us who had
been using Ethernet workstations for a decade prior, it was rather late to
the party.
> Of course for years I had had more CPU power on my desk (e.g. a KDJ11,
> which would beat the pants off a 11/780 or VS2000 in benchmarking the
> apps I was working on.)
Indeed. IIRC, AT&T's UNIX PC was slower (I have both a UNIX PC and a
VS2000 in my zoo, but neither have worked in many years), but not by much.
The other thing that I remember about the VS2000, although this was
actually an Ultrix software issue, is that there was a license file that
had to be installed that identified how many Internet servers you could
run. The normal license basically meant that you couldn't TELNET or rsh
in. Of course, nothing (technical, anyway) stopped you from stealing a
license file from an Ultrix timesharing system.
But this was an example of where Digital's mindset was at the time; slow
hardware and crippled software.
Morten Reistad
No. I speak from the other side.
From the customers, academic, public and private.
We ran from DEC. We had our eyes shut for a little while, but
we woke up 25 years ago today, when the may 17th news percolated
over here. We never allowed single vendor lockin ever again.
We were strongly reinforced by the performance of the VAX.
A PPOE even went so far as to have a totally separate hardware
and software implementation of their core systems.
-- mrr
Pat Farrell
> Having an SMP system that would take a footprint of a closet would
> have continued sales for another 5-10 years. This would have given
> VMS and its hardware enough time to mature.
Sorry, not for us. We needed something three times faster than a KL in
1980. We only kept at it because we were promised it in 82, then 83.
Space was not a major issue. We could even ignore the insane
wastefulness of the power supply. By the time the Jupiter was killed, we
needed something six or more times faster than a KL.
What we were told by folks that I trusted, was that the Jupiter was not
making its performance numbers, and would be lucky to be twice as fast
as a KL. At that point, we were cooked, even if the Jupiter was real,
and priced less than a KL, the business model didn't work.
For all of our systems, the RP06 and RP07s took more space than the CPU
and all the front ends.
We tried to sell Vaxen, and IBM solutions for timesharing, including
VM/CMS, but 83 was really the end of timesharing as a business.
Mark Crispin
> No. I speak from the other side.
> From the customers, academic, public and private.
Which is the only side that counts.
> We ran from DEC. We had our eyes shut for a little while, but
> we woke up 25 years ago today, when the may 17th news percolated
> over here. We never allowed single vendor lockin ever again.
> We were strongly reinforced by the performance of the VAX.
Same here.
Mark Crispin
> Sorry, not for us. We needed something three times faster than a KL in 1980.
> We only kept at it because we were promised it in 82, then 83.
And by the price/performance curves of the time should have been at least
5x faster.
> Space was not a major issue. We could even ignore the insane wastefulness of
> the power supply. By the time the Jupiter was killed, we needed something six
> or more times faster than a KL.
Yup.
> What we were told by folks that I trusted, was that the Jupiter was not
> making its performance numbers, and would be lucky to be twice as fast as a
> KL.
I heard that, at best, it was 3x KL speed but usually didn't make that.
> At that point, we were cooked, even if the Jupiter was real, and priced
> less than a KL, the business model didn't work.
Lots of other customers concluded the same. SMP was not the answer. We
didn't need more users, we needed faster results.
SMP fixes load, not turnaround.
glen herrmannsfeldt
(snip)
> 1969-1970 was a watershed period in operating systems design, marking
> the birth of both Tenex (which became TOPS-20) and UNIX (VMS came
> several years later). Everything before that time was obsoleted and is
> gone.
OS/360 --> OS/VS2 --> MVS --> OS/390 --> z/OS
but in the end it isn't that much different.
-- glen
jmfbah
That's why I said that it didn't kill the PDP-10; it killed DEC.
It came near to this when TOPS-10 was announced as dead in 1978.
That should have been your first wakeup call.
/BAH
jmfbah
> jmfbah wrote:
>> Having an SMP system that would take a footprint of a closet would
>> have continued sales for another 5-10 years. This would have given
>> VMS and its hardware enough time to mature.
>
> Sorry, not for us. We needed something three times faster than a KL in
> 1980.
Sigh! You could have had that speed IFF the -20 had not cancelled
the multi-port internal memory hardware project.
> We only kept at it because we were promised it in 82, then 83.
As Morten, summarized five months ago, DEC's CPU architects had
hit their [mutter] Law. (Moore's?) It was up to software
to provide that increased "speed" until the hardware guys figured
out how to make an Alpha. Getting rid of Bell helped.
>
> Space was not a major issue. We could even ignore the insane
> wastefulness of the power supply.
I said footprint. It was an issue. Maybe you didn't care, but
more and more of our other customers did because they had to
provide services to more and more users. Just the paper storage
was getting to be a problem even in 1970.
>By the time the Jupiter was killed, we
> needed something six or more times faster than a KL.
>
> What we were told by folks that I trusted, was that the Jupiter was not
> making its performance numbers, and would be lucky to be twice as fast
> as a KL. At that point, we were cooked, even if the Jupiter was real,
> and priced less than a KL, the business model didn't work.
>
> For all of our systems, the RP06 and RP07s took more space than the CPU
> and all the front ends.
Exactly. Footprint was a serious problem.
>
> We tried to sell Vaxen, and IBM solutions for timesharing,
None of which had the timesharing philosophy.
> including
> VM/CMS, but 83 was really the end of timesharing as a business.
>
Not really.
/BAH
jmfbah
> On Mon, 19 May 2008, Pat Farrell posted:
>> Sorry, not for us. We needed something three times faster than a KL in
>> 1980. We only kept at it because we were promised it in 82, then 83.
>
> And by the price/performance curves of the time should have been at
> least 5x faster.
>
>> Space was not a major issue. We could even ignore the insane
>> wastefulness of the power supply. By the time the Jupiter was killed,
>> we needed something six or more times faster than a KL.
>
> Yup.
>
>> What we were told by folks that I trusted, was that the Jupiter was
>> not making its performance numbers, and would be lucky to be twice as
>> fast as a KL.
>
> I heard that, at best, it was 3x KL speed but usually didn't make that.
>
>> At that point, we were cooked, even if the Jupiter was real, and
>> priced less than a KL, the business model didn't work.
>
> Lots of other customers concluded the same. SMP was not the answer. We
> didn't need more users, we needed faster results.
>
> SMP fixes load, not turnaround.
You've never used it. Turnaound was very good.
/BAH
jmfbah
not the OS business. Hindsight is a wonderful thing and it's the
only sight Crispin has.
/BAH
Sarr J. Blumson
:
: We tried to sell Vaxen, and IBM solutions for timesharing, including
As a _business_ time sharing was done in 1983 because desktops machines
were already killing it. It took ADP another year to figure it out and
go into "stop new development and milk it until it's dry" mode, but
no alternative mainframe solution would have changed that.
--
--------
Sarr Blumson sarr.b...@alum.dartmouth.org
http://www-personal.umich.edu/~sarr/
Mark Crispin
>> SMP fixes load, not turnaround.
> You've never used it. Turnaound was very good.
Bullshit.
SMP provides multiprocessing. It does not make the individual processors
run any faster.
The same amount of real time is expended in a MACRO compilation on a
single-CPU system as on an SMP system.
You still don't get it, do you? The KL10 was a slug by the late 1970s.
We needed a faster CPU. We already were throwing additional CPUs to
reduce load, but that did NOTHING, NOTHING!!, to fix turnaround.
John Everett
wrote:
>At 2PM Eastern Daylight time on May 17, 1983, Ken Olsen and Bill Johnson
>cancelled Project Jupiter and killed the PDP-10.
>
As someone who spent part of my formative years in the TOPS-10 Monitor
Group, then many years in the DECSystem-10 timesharing business; in
retrospect it's an architecture that deserved to die.
--
jeverett3<AT>sbcglobal<DOT>net (John V. Everett)
Pat Farrell
> Pat Farrell wrote:
>> Sorry, not for us. We needed something three times faster than a KL in
>> 1980.
>
> Sigh! You could have had that speed IFF the -20 had not cancelled
> the multi-port internal memory hardware project.
No, we needed faster, not support for more folks.
This is a fundamental difference.
> As Morten, summarized five months ago, DEC's CPU architects had
> hit their [mutter] Law. (Moore's?) It was up to software
> to provide that increased "speed" until the hardware guys figured
> out how to make an Alpha.
Funny, Intel and AMD make CPUs that are thousands of times faster than a
KL. Perhaps their engineers are better than DECs?
In the KL timeframe, big iron did not follow Moore's law. But with a KL
being a '75 product, Moore's law would have a KM at twice as fast in '77
nad a KN at twice again (four KL) in 79. And a KO at twice again (8 KL)
in 81.
If we had gotten half that improvement, the world would have been different.
Now you gonna make the claim that the Aphpa was a huge win for DEC and
the world?
Pat Farrell
> Pat Farrell <pfar...@pfarrell.com> wrote:
> : We tried to sell Vaxen, and IBM solutions for timesharing, including
> : VM/CMS, but 83 was really the end of timesharing as a business.
>
> As a _business_ time sharing was done in 1983 because desktops machines
> were already killing it. It took ADP another year to figure it out and
> go into "stop new development and milk it until it's dry" mode, but
> no alternative mainframe solution would have changed that.
I disagree. an 83 vintage desktop was not a solution to large systems
needing 100 simultaneous users working on one problem. Even in the late
80s, with Netware, it was really a world where 100 users doing each
their own thing, not working on one problem.
In the late 70s, ADP tried to make an alternative mainframe, the OnSite,
work, with far more success than I expected. But it didn't address the
problem space that AMS and our customers worked in.
Early 90s vintage client server systems, using Gupta or Powerbuilder
talking to Oracle, were attempting to solve the same general domain
problems. But Windows 3.0 was not a suitable platform for most
production work. It took OS/2 or NT to make it work.
kkt
> Sarr J. Blumson wrote:
> > Pat Farrell <pfar...@pfarrell.com> wrote:
> > : We tried to sell Vaxen, and IBM solutions for timesharing, including
> > : VM/CMS, but 83 was really the end of timesharing as a business.
> >
> > As a _business_ time sharing was done in 1983 because desktops machines
> > were already killing it. It took ADP another year to figure it out and
> > go into "stop new development and milk it until it's dry" mode, but
> > no alternative mainframe solution would have changed that.
>
> I disagree. an 83 vintage desktop was not a solution to large systems
> needing 100 simultaneous users working on one problem.
1983 desktops weren't even a solution to medium-sized single-user
problems. Users were always hitting walls, and not because of trying
to forecast the weather or break RSA.
-- Patrick
glen herrmannsfeldt
(snip)
> In the KL timeframe, big iron did not follow Moore's law. But with a KL
> being a '75 product, Moore's law would have a KM at twice as fast in '77
> nad a KN at twice again (four KL) in 79. And a KO at twice again (8 KL)
> in 81.
I wonder if there was a rule against naming a CPU after KO.
Also, what about the KB through KH, KJ, and KK?
-- glen
Eric Smith
> If Digital had made a desktop PDP-10, it would have had an MLP of $50K
> for the CPU (with 2020 class performance) and would have required
> Massbus peripherals.
If they had introduced it between 1982 and 1989, it almost certainly would
have had a floppy drive and an RD5x series winchester drive. They did seem
to have that much figured out.
There probably would have been an expensive CI option, rather than
Massbus adapters. By that time the medium-to-high-end storage plan was
to share disk and tape on an HSC50.
> Digital had no clue of the personal computer revolution,
They had lots of clues about it, arguably too many. What they didn't
have was a coherent plan. Instead of a whole lot of different
attempts at building personal computers, resulting in a plethora of
incompatible products, they needed the executive management to
actually choose a specific direction. Even if management chose
poorly, it would have been better than not choosing.
Eric Smith
> In the KL timeframe, big iron did not follow Moore's law. But with a
> KL being a '75 product, Moore's law would have a KM at twice as fast
> in '77 nad a KN at twice again (four KL) in 79. And a KO at twice
> again (8 KL) in 81.
Moore's Law doesn't say anything (directly) about processor speed. Moore
said that the number of transistors per chip "for minimum cost" doubled
every two years. Wikipedia claims that someone else at Intel concluded
based on Moore's law that this resulted in a doubling of performance every
18 months. Both curves are a measures of chips, and were not claimed
to apply to systems.
For what it's worth, the KM10 was introduced in 1968, as were the KE10,
KP10, KT10, and KT10A. If you bought a KM10 back then and tried to get it
to execute PDP-10 instructions, you'd still be waiting.
Eric Smith
> I wonder if there was a rule against naming a CPU after KO.
One of the designations of the Minnow was KO10. Another was KT20.
> Also, what about the KB through KH, KJ, and KK?
KE10 was the byte instruction "option" for the KA10. (The KE prefix
in general was used for instruction set extensions.)
Jupiter was designated KC10, and there was a design spec for a
midrange CPU designated KD10.
Pat Farrell
> Jupiter was designated KC10, and there was a design spec for a
> midrange CPU designated KD10.
Do you think it really would have been a 10? or perhaps 20 only? I guess
that the big TOPS-10 shops would insist on a -10 version.
I know that CompuServ had something like 26 systems, we only had six.
And I'm sure ADP had a bunch, they had six or so in Waltham when I
worked there, and bunches more in Ann Arbor.
Pat Farrell
> Moore's Law doesn't say anything (directly) about processor speed. Moore
> said that the number of transistors per chip "for minimum cost" doubled
> every two years.
Technically correct.
Density has a lot to do with speed.
Speed of light being a foot a nanosecond, et al.
> For what it's worth, the KM10 was introduced in 1968, as were the KE10,
> KP10, KT10, and KT10A. If you bought a KM10 back then and tried to get it
> to execute PDP-10 instructions, you'd still be waiting.
I'm just making names up. as someone mentioned the Jupitor was a KC10.
Was a KM10 some sort of core memory thing? The first KL that AMS bought
had core memory, and First Data had a KA with the world's longest
memory. John will remember better than me, it was nearly 200 KW, lots
and lots of racks
Bill Pechter
KB was the 11 line.
Bill
--
--
Be comforted that in the face of all erridity and disallusionment, and
despite the changing fortunes of time, there is always a big future in
computer maintainance. --Deteriorata (pechter-at-gmail-dot-com)
jmfbah
> On Sat, 17 May 2008 09:34:02 -0700, Mark Crispin <m...@Washington.EDU>
> wrote:
>
>> At 2PM Eastern Daylight time on May 17, 1983, Ken Olsen and Bill Johnson
>> cancelled Project Jupiter and killed the PDP-10.
>>
>
> As someone who spent part of my formative years in the TOPS-10 Monitor
> Group, then many years in the DECSystem-10 timesharing business; in
> retrospect it's an architecture that deserved to die.
>
>
Would an Alpha-flavored architecture have been a good replacement
back then?
/BAH
Sarr J. Blumson
: Sarr J. Blumson wrote:
: > Pat Farrell <pfar...@pfarrell.com> wrote:
: > : We tried to sell Vaxen, and IBM solutions for timesharing, including
: > : VM/CMS, but 83 was really the end of timesharing as a business.
: >
: > As a _business_ time sharing was done in 1983 because desktops machines
: > were already killing it. It took ADP another year to figure it out and
: > go into "stop new development and milk it until it's dry" mode, but
: > no alternative mainframe solution would have changed that.
: I disagree. an 83 vintage desktop was not a solution to large systems
: needing 100 simultaneous users working on one problem. Even in the late
: 80s, with Netware, it was really a world where 100 users doing each
: their own thing, not working on one problem.
We may just have a terminology problem then. From my somewhat ADP centric
(but not entirely; this is a description of what the VM/370 systems I used
other places were doing) point of view "time-sharing" was 100 users doing
their own thing. 100 users doing the same thing wasn't a business ADP was
in. Nor AFAIK were Tymshare and CompuServe. I'm not in a position to know
whether DEC had any real penetration in the 100 users working on one
problem world.
: In the late 70s, ADP tried to make an alternative mainframe, the OnSite,
: work, with far more success than I expected. But it didn't address the
: problem space that AMS and our customers worked in.
The OnSite was a 2020 running TOPS-10, and was targeted at "departmental"
computing. Which is why it was sold as "you buy an OnSite." And that was
a market that was killed by desktop machines; I spent the second half of
the 80s helping Northern Telecom fail with a "time sharing" solution in
that market, too.
jmfbah
> Pat Farrell <pfar...@pfarrell.com> wrote:
> : Sarr J. Blumson wrote:
> : > Pat Farrell <pfar...@pfarrell.com> wrote:
> : > : We tried to sell Vaxen, and IBM solutions for timesharing, including
> : > : VM/CMS, but 83 was really the end of timesharing as a business.
> : >
> : > As a _business_ time sharing was done in 1983 because desktops machines
> : > were already killing it. It took ADP another year to figure it out and
> : > go into "stop new development and milk it until it's dry" mode, but
> : > no alternative mainframe solution would have changed that.
>
> : I disagree. an 83 vintage desktop was not a solution to large systems
> : needing 100 simultaneous users working on one problem. Even in the late
> : 80s, with Netware, it was really a world where 100 users doing each
> : their own thing, not working on one problem.
>
> We may just have a terminology problem then. From my somewhat ADP centric
> (but not entirely; this is a description of what the VM/370 systems I used
> other places were doing) point of view "time-sharing" was 100 users doing
> their own thing. 100 users doing the same thing wasn't a business ADP was
> in. Nor AFAIK were Tymshare and CompuServe. I'm not in a position to know
> whether DEC had any real penetration in the 100 users working on one
> problem world.
There may have been a couple done by the Computer Special Systems group.
The research university computer sites usually did their own stuff. We
provided the hardware and enough software to give them a higher starting
point than if they had to begin with bare iron. Most of this kind
of thing was done on minis. They used the -10 to do their software
developement before doing the serious runs on the mini. The science
types did this a lot.
>
> : In the late 70s, ADP tried to make an alternative mainframe, the OnSite,
> : work, with far more success than I expected. But it didn't address the
> : problem space that AMS and our customers worked in.
>
> The OnSite was a 2020 running TOPS-10, and was targeted at "departmental"
> computing. Which is why it was sold as "you buy an OnSite." And that was
> a market that was killed by desktop machines; I spent the second half of
> the 80s helping Northern Telecom fail with a "time sharing" solution in
> that market, too.
>
Distributed computing solutions was a marketing buzz word at that time.
So everybody did it. Then those distributed systems started to need
operations' support like backups and restores and new updates. It
became a huge headache to manage a herd of desktops. Then those
desktops became remote terminals again.
/BAH
Morten Reistad
John Everett <jeve...@sbcglobal.DEFEAT.UCE.BOTS.net> wrote:
>On Sat, 17 May 2008 09:34:02 -0700, Mark Crispin <m...@Washington.EDU>
>wrote:
>
>>At 2PM Eastern Daylight time on May 17, 1983, Ken Olsen and Bill Johnson
>>cancelled Project Jupiter and killed the PDP-10.
>>
>
>As someone who spent part of my formative years in the TOPS-10 Monitor
>Group, then many years in the DECSystem-10 timesharing business; in
>retrospect it's an architecture that deserved to die.
I don't mind the demise of the pdp10 that much. What I _do_ mind
was the way tops20, tenex and ITX were left stranded.
And, no, I don't mind Tops10. Already by 1978 Prime could do a better
job of basic timesharing.. They _did_ have the 850 as well, and it
could become a 950 as well (three cpus; except it was never officially
sold as such.) But almost everyone buying 850s broke up the MP, and
used them together with ringnet instead.
What I _really_ don't miss are the days of expensive, power hungry
hardware with an attitude.
-- mrr
Pat Farrell
> Pat Farrell <pfar...@pfarrell.com> wrote:
> : I disagree. an 83 vintage desktop was not a solution to large systems
> : needing 100 simultaneous users working on one problem. Even in the late
> : 80s, with Netware, it was really a world where 100 users doing each
> : their own thing, not working on one problem.
>
> We may just have a terminology problem then. From my somewhat ADP centric
> (but not entirely; this is a description of what the VM/370 systems I used
> other places were doing) point of view "time-sharing" was 100 users doing
> their own thing. 100 users doing the same thing wasn't a business ADP was
> in. Nor AFAIK were Tymshare and CompuServe. I'm not in a position to know
> whether DEC had any real penetration in the 100 users working on one
> problem world.
When I was at First Data, later ADP, we were in the 100 users each doing
their own thing. I expect that was most of what Tymshare and CompuServ
did as well.
AMS started there, but AMS was really a consulting company. We got first
into the IBM batch business because the consulting was spending a lot of
money on program development, CICS, batch, etc. So the business was
solving business problems using a computer, not selling timesharing
cycles. In 1977, AMS bought its first KL running TOPS-20. While we
started doing small solutions, say for four folks at one company, we
quickly moved into larger systems. The expertise at AMS was in business
analysis, designing a solution, and implementing it. While we would sell
timesharing as you speak, that wasn't were the leverage was.
We made the serious money solving hard problems for businesses and
Federal agencies. In most cases, AMS folks wrote the code, and the
business or Federal folks were users. They did not write any code, they
were pure Users.
We did all of the timesheet accounting, staff management and assignment
for the US General Accounting Office. We implemented and ran a near real
time purchase order system for a huge wholesaler.
There would typically be three kinds of program running in user space:
1) code AMS developed
2) System 1022
3) cats and dogs like editors and compilers to make #1
In normal cases, our competitors were not Tymshare or CompuServ, they
were EDS or Lockhead.
The competition typically used CICS to build their systems. Because
Tops-20 was such a great development world, we could build the same
system in 10% to 20% of the effort, time and cost.
Rich Alderson
> Eric Smith wrote:
>> Jupiter was designated KC10, and there was a design spec for a
>> midrange CPU designated KD10.
> Do you think it really would have been a 10? or perhaps 20 only? I guess
> that the big TOPS-10 shops would insist on a -10 version.
The processors in DEC-20s are KL10 and KS10. That's a PDP-10 ISP, not an OS
designation.
In point of fact, although it was early on designated a 2090, the final
marketing literature, shortly before the cancellation made it all moot, was
"DECSYSTEM-4050" (based on the cover of some marketing binders I've seen).
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
Eric Smith
> Density has a lot to do with speed.
> Speed of light being a foot a nanosecond, et al.
Yes, but transistor performance doesn't scale as a linear function of
size, so Moore's law predicting that you get twice as many transistors
every so many months doesn't mean that you get twice the processor
performance.
> Was a KM10 some sort of core memory thing?
No. If you didn't have a KM10, you used core memory instead. But AFAIK
all KA10 processors came with a KM10.
Eric Smith
> Jupiter was designated KC10, and there was a design spec for a
> midrange CPU designated KD10.
Pat Farrell wrote:
> Do you think it really would have been a 10? or perhaps 20 only?
Well, there was no such thing as a PDP-20, so I don't see any reason
why they wouldn't have stuck with the KC10 and KD10 designations.
> I guess that the big TOPS-10 shops would insist on a -10 version.
You can paint the box orange (or terra cotta, or "hinese red, or whatever
the heck you want to call it) and run TOPS-20 on it, but it's still
a PDP-10.
It seems likely that the various PDP-10 processors under development
would have been offered in both DECsystem-10 and DECSYSTEM-20
configurations.
Eric Smith
> Also, what about the KB through KH, KJ, and KK?
Bill Pechter wrote:
> KB was the 11 line.
No, KB11 was *some* models of PDP-11 CPUs, specifically the 11/45 and
models derived from its design.
Others PDP-11 processors had different second letters and suffixes.
If there had been a KB10, it most certainly would NOT have been a
PDP-11. Though it's possible that there might have been a PDP-11
inside it, as there was with the KL10.
Pat Farrell
> You can paint the box orange (or terra cotta, or "hinese red, or whatever
> the heck you want to call it) and run TOPS-20 on it, but it's still
> a PDP-10.
As Smokey Yunick said about car engines, a motor doesn't know what logo
is on the valve cover. Fords and Chevys go fast with the same tricks.
I always thought of 20s as orange, but I think nese red was the offciial
name.
Mark Crispin
> I always thought of 20s as orange, but I think nese red was the offciial
> name.
It was a test question in the first 36-bit Trivial Bowl.
The DECSYSTEM-20 color was Terra-Cotta, as evidenced by what was printed
on the paint cans.
Johnny Billquist
> In article <15qdnWBWb6X6gq7V...@comcast.com>,
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Pat Farrell wrote:
>> (snip)
>>
>>> In the KL timeframe, big iron did not follow Moore's law. But with a KL
>>> being a '75 product, Moore's law would have a KM at twice as fast in '77
>>> nad a KN at twice again (four KL) in 79. And a KO at twice again (8 KL)
>>> in 81.
>> I wonder if there was a rule against naming a CPU after KO.
>>
>> Also, what about the KB through KH, KJ, and KK?
>>
>> -- glen
>>
>
> KB was the 11 line.
I wonder if it's that easy?
KB11 was definitely a PDP-11. But wasn't the CPU of the 11/20 called KA11? Or
was that a KB11-A?
The KB11-B was in the 11/45/50/55 and KB11-C in the 11/70.
Hmm. KK was atleast the designation of the CPU in the PDP-8/e, by the way.
KK8-E, unless my memory fails me.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
glen herrmannsfeldt
> Pat Farrell wrote about Moore's law.
>>Density has a lot to do with speed.
>>Speed of light being a foot a nanosecond, et al.
> Yes, but transistor performance doesn't scale as a linear function of
> size, so Moore's law predicting that you get twice as many transistors
> every so many months doesn't mean that you get twice the processor
> performance.
There are at least a few different scaling laws for transistors.
For MOS, the correct scaling law also reduces the gate oxide
thickness, which also reduces the maximum gate voltage.
In many cases that wasn't desired, so the transistors were
reduced in area but without reducing the gate oxide.
Also, around 0.35 micron things got more interesting
for the metalization (interconnect) layers. While
R/length increases and C/length decreases, at about
0.35 micron or less it is required to change from a
lumped model to a distributed R and C model.
-- glen
jmfbah
> In article <pto5349aaodci669m...@4ax.com>,
> John Everett <jeve...@sbcglobal.DEFEAT.UCE.BOTS.net> wrote:
>> On Sat, 17 May 2008 09:34:02 -0700, Mark Crispin <m...@Washington.EDU>
>> wrote:
>>
>>> At 2PM Eastern Daylight time on May 17, 1983, Ken Olsen and Bill Johnson
>>> cancelled Project Jupiter and killed the PDP-10.
>>>
>> As someone who spent part of my formative years in the TOPS-10 Monitor
>> Group, then many years in the DECSystem-10 timesharing business; in
>> retrospect it's an architecture that deserved to die.
>
> I don't mind the demise of the pdp10 that much. What I _do_ mind
> was the way tops20, tenex and ITX were left stranded.
Yes, among other OSes.
>
> And, no, I don't mind Tops10. Already by 1978 Prime could do a better
> job of basic timesharing.. They _did_ have the 850 as well, and it
> could become a 950 as well (three cpus; except it was never officially
> sold as such.) But almost everyone buying 850s broke up the MP, and
> used them together with ringnet instead.
>
> What I _really_ don't miss are the days of expensive, power hungry
> hardware with an attitude.
That's why hardware was a guy thing :-).
/BAH
jmfbah
Whether TOPS-10 was developed for the system would depend on what
the customers wanted. It was never up to the TOPS-10 development
group, no matter how loud Crispin screams otherwise.
/BAH
Eric Smith
> KB11 was definitely a PDP-11. But wasn't the CPU of the 11/20 called
> KA11? Or was that a KB11-A?
>
> The KB11-B was in the 11/45/50/55 and KB11-C in the 11/70.
K-prefix PDP-11 processors:
KA11 PDP-11/20, PDP-11/10 OEM [*], PDP-11/15 OEM
KB11-A PDP-11/45 (early)
KB11-B PDP-11/70 (early)
KB11-C PDP-11/70 (late) (synchronous FPP interface)
KB11-Cm PDP-11/70 (very late) - based on KB11-E
KB11-D PDP-11/45 (late), PDP-11/55 (synchronous FPP interface based on KB11-C)
KB11-E PDP-11/74
KD11-A PDP-11/40
KD11-B PDP-11/05, PDP-11/10 (OEM)
KD11-D PDP-11/04
KD11-E PDP-11/34
KD11-EA PDP-11/34A
KD11-F PDP-11/03 (quad, LSI-11)
KD11-H PDP-11/03 (quad, LSI-11)
KD11-HA PDP-11/03 (dual, LSI-11/2)
KD11-J PDP-11/03 (dual, LSI-11/2)
KD11-K PDP-11/60
KD11-Q PDP-11/03 (dual, LSI-11/2)
KDF11-AA PDP-11/23 with MMU, no FPP
KDF11-AB PDP-11/23 with MMU, with FPP
KDF11-AC PDP-11/23 no MMU, no FPP
KDF11-BA PDP-11/23+
KDF11-CA Pro 325/350
KDF11-UA PDP-11/24
KDJ11-A PDP-11/73
KDJ11-B PDP-11/83, PDP-11/84
KDJ11-CA Pro 380
KDJ11-DA PDP-11/53
KDJ11-DB PDP-11/53
KDJ11-DD PDP-11/53
KDJ11-EA PDP-11/93, PDP-11/94 (2 MByte)
KDJ11-EB PDP-11/93, PDP-11/94 (4 MByte)
KDJ11-PB DECserver 500
KDJ11-SD DECserver 550
KD11-Z PDP-11/44
KXT11-AA SBC-11/21
KXT11-AB SBC-11/21+
KXT11-CA M8377 peripheral processor
K-prefix PDP-11 processor options:
KE11-A EAE
KE11-B EAE
KE11-E EIS for PDP-11/40
KE11-F FIS for PDP-11/40
KE44-A CIS for PDP-11/44
KE74-A CIS for PDP-11/74
KEF11-AA FPP for PDP-11/23, PDP-11/24
KEF11-BB CIS for PDP-11/23, PDP-11/24
KEV11 EIS/FIS for PDP-11/03
KF11 four-level priority interrupt for PDP-11/20
KG11-A CRC/LRC arithmetic element
KJ11-A stack limit for PDP-11/40
KK11-A cache for PDP-11/34A
KK11-B cache for PDP-11/44
KL11 console SLU (early, replaced by DL11-x)
KM11 maintenance panel
KP11-A power fail/restart
KT11-D memory management for PDP-11/40
KT24 Unibus map for PDP-11/24
KTF11 MMU for PDP-11/23, PDP-11/24
KTJ11-B Unibus adapter for PDP-11/84, PDP-11/94
KU116 WCS for PDP-11/60
KUV11-AA WCS for PDP-11/03
KW11-L line time clock, various models
KY11-A programmer's front penel, PDP-11/20
KY11-D front panel for PDP-11/40
KY11-LA turnkey front panel, PDP-11/04 and PDP-11/05
KY11-LB programmer's front panel, PDP-11/04 and PDP-11/05
[*] Documents suggest that the OEM version of the PDP-11/20 was to be
designated PDP-11/10, but it is unknown whether any shipped to customers
with that designation
jmfbah
So the first K in the parts list meant "CPU".
/BAH
Eric Smith
> So the first K in the parts list meant "CPU".
Nearly always.
Just as an initial "M" was almost always main memory, an initial "R"
was almost always a disk or drum, etc.
jmfbah
Nearly? The parts naming assignments didn't have exceptions AFAIK. I
never did learn the formulas; it was on my list of things to learn
about the company after finishing up the -10 to VMS migrations.
/BAH
bob
series, the KL series (console terminal connection mechanisms) and some
times the switch panel mechanism or memory extension and timeshare
controller.
Dick Best was the keeper of the list, one could negotiate both
designators and module numbers in some cases.
.b
jmfbah
Do you know who he negotiated with? I never had any sense about how
any of that part of the biz worked. I do know that the product managers
had something to do with it and I suspected SDC has some involvement
but I never knew if they had any control over naming things.
I did get the practice started of having "spec reviews" of the BOMs
before we shipped (rather than after). Not only did we ensure
that the BOMs were correct, but all departments got an education
in that mess. It may not have been a mess but it sure looked like
to somebody who could code machines.
/BAH
Carl Appellof
"Eric Smith" <er...@brouhaha.com> wrote in message
news:m3k5hoq...@donnybrook.brouhaha.com...
> Mark Crispin <m...@Washington.EDU> writes:
>> Digital had no clue of the personal computer revolution,
>
> They had lots of clues about it, arguably too many. What they didn't
> have was a coherent plan. Instead of a whole lot of different
> attempts at building personal computers, resulting in a plethora of
> incompatible products, they needed the executive management to
> actually choose a specific direction. Even if management chose
> poorly, it would have been better than not choosing.
Ah yes. I was a pretty new DEC employee when I saw the announcement of 3,
count 'em THREE "personal" computers all on the same day:
Rainbow
DECmate II (number may be wrong)
Pro 350
All incompatible with each other, not to mention the rest of the world.
Probably the result of DEC's fabled "matrix management" and different lines
of business.
Carl
Mark Crispin
> Rainbow
> DECmate II (number may be wrong)
> Pro 350
> All incompatible with each other, not to mention the rest of the world.
There was an even greater flaw to these products, something that Digital
never grasped.
All of these products were aimed at the business user. The Rainbow might
have been a home user product, but it suffered both from overpricing and
startling omissions as a home product.
Digital, and many of its competitors in the business user market, had no
intention of being in the home market. Similarly, Atari, Commodore, etc.
in the home market had no intention of being in the business market.
They were idiots, and paid the price for their idiocy.
What the market needed -- even begged to receive -- was a scalable
hardware and software architecture that, depending upon configuration and
options, would be suited both (at the low end) for the home market and
(at the high end) for the business market.
Microsoft and the IBM PC clone makers got it.
To a somewhat lesser extent, Apple got it too.
Digital did not get it at all; and no amount of effort to educate them
worked.
Mike Ross
>1969-1970 was a watershed period in operating systems design, marking the
>birth of both Tenex (which became TOPS-20) and UNIX (VMS came several
>years later). Everything before that time was obsoleted and is gone.
Can't let you get away with that, Mark.
OS/360... still with us
VM... still with us
ACP/TPF... still with us (every time you swipe your Visa card..)
The universe doesn't begin and end with DEC. Or even Digital...
Mike
--
http://www.corestore.org
'As I walk along these shores
I am the history within'
Pat Farrell
> Rainbow
> DECmate II (number may be wrong)
> Pro 350
The Pro ran a bastardized version of RSX-11, without Decnet
The DECmate was claimed to run one of the world's most popular word
processing program, it was a PDP-8. Why DEC thought the world needed a
brand new PDP-8 in 82/83 in beyond my brain.
The rainbow, while grossly over priced, and crippled to being
non-graphical, was just too weird. CPM and PC-DOS, not terrible, but
completely without any attempt at hardware compatibility with the only
standard, the IBM XT. It took special version of even standard software.
What drove them to think vendors would build custom versions for weird
Digital hardware when they could just buy an IBM PC is truly startling.
Three "personal computers" with three different CPUs, three different
operating systems.
Stunning incompetence.
Johnny Billquist
> Carl Appellof wrote:
>> Rainbow
>> DECmate II (number may be wrong)
>> Pro 350
>
> The Pro ran a bastardized version of RSX-11, without Decnet
Well, the Pro ran a bastardized version of RSX-11. True. But it did run DECnet.
You even had ethernet on it. Which were all good things.
However, the bastardization didn't stop with a sick version of RSX. For being a
PDP-11, it was a very bastardized version of a PDP-11 as well.
DEC really struggeled to make sure that no software that played with hardware on
a PDP-11 would work fine on a Pro. That was a good killer.
> The DECmate was claimed to run one of the world's most popular word
> processing program, it was a PDP-8. Why DEC thought the world needed a
> brand new PDP-8 in 82/83 in beyond my brain.
I believe the DECmate was fairly successful for a while. However, dedicated word
processors were definitely not the way of the future.
So it was totally the wrong mindset.
> The rainbow, while grossly over priced, and crippled to being
> non-graphical, was just too weird. CPM and PC-DOS, not terrible, but
> completely without any attempt at hardware compatibility with the only
> standard, the IBM XT. It took special version of even standard software.
> What drove them to think vendors would build custom versions for weird
> Digital hardware when they could just buy an IBM PC is truly startling.
Yes. The incompatibilities with the IBM PC was a real problem for the Rainbow.
DEC didn't understand the software-as-comodity idea.
> Three "personal computers" with three different CPUs, three different
> operating systems.
>
> Stunning incompetence.
Stunning wrong ideas on where things were going, I'd say.
And it should atlest been a little bit obvious that some of the things DEC did
was in the wrong direction. The DECmate should not have been done. Writing a
word processing package for one of the other machines wouldn't have cost as
much. But they were still trying to lock customers in.
jmfbah
You should have heard the screams of our comm types at that time.
Any one of these guys could have taken any of those three and
actually turn it into something useful.
/BAH
jmfbah
> Pat Farrell skrev:
>> Carl Appellof wrote:
>>> Rainbow
>>> DECmate II (number may be wrong)
>>> Pro 350
>>
>> The Pro ran a bastardized version of RSX-11, without Decnet
>
> Well, the Pro ran a bastardized version of RSX-11. True. But it did run
> DECnet.
That was the main problem with the Pro; it had too much DECnet.
> You even had ethernet on it. Which were all good things.
Yes but it shouldn't have had full-blown DECnet if it was really
supposed to be a single user system.
> However, the bastardization didn't stop with a sick version of RSX. For
> being a PDP-11, it was a very bastardized version of a PDP-11 as well.
> DEC really struggeled to make sure that no software that played with
> hardware on a PDP-11 would work fine on a Pro. That was a good killer.
That one sounds like another NIH that afflicted every RSX development
attempt.
>
>> The DECmate was claimed to run one of the world's most popular word
>> processing program, it was a PDP-8. Why DEC thought the world needed a
>> brand new PDP-8 in 82/83 in beyond my brain.
Sigh! Wang.
> Yes. The incompatibilities with the IBM PC was a real problem for the
> Rainbow.
> DEC didn't understand the software-as-comodity idea.
Bell was trying his damnedest to turn DEC back into a hardware company.
He never understood that software was as important to sell this
hardware. It was impossible for him to accept that software might
be more important than the hardware.
>
>> Three "personal computers" with three different CPUs, three different
>> operating systems.
>>
>> Stunning incompetence.
Do you think those development groups talked to each other?
>
> Stunning wrong ideas on where things were going, I'd say.
> And it should atlest been a little bit obvious that some of the things
> DEC did was in the wrong direction. The DECmate should not have been
> done. Writing a word processing package for one of the other machines
> wouldn't have cost as much. But they were still trying to lock customers
> in.
The DECmate was to compete with Wang. At that time, Wang hadn't hit
its support saturation point yet.
/BAH
Johnny Billquist
> Johnny Billquist wrote:
>> Pat Farrell skrev:
>>> Carl Appellof wrote:
>>>> Rainbow
>>>> DECmate II (number may be wrong)
>>>> Pro 350
>>>
>>> The Pro ran a bastardized version of RSX-11, without Decnet
>>
>> Well, the Pro ran a bastardized version of RSX-11. True. But it did
>> run DECnet.
>
> That was the main problem with the Pro; it had too much DECnet.
Huh? What are you talking about?
>> You even had ethernet on it. Which were all good things.
>
> Yes but it shouldn't have had full-blown DECnet if it was really
> supposed to be a single user system.
I think we've already hashed through this, Barb. But I'll repeat it again, for
you (and anyone elses benifit, who might not have catched it the first time).
DECnet comes basically in two flavours. Endnode and routing node. Endnodes are
stripped down to the basic functionality that are required to even exist on a
DECnet network, and thus is definitely not what anyone could consider "full
blown". They have almost no idea of how to do anything except talk to the
closest router, which they must have a direct connection to, and how do handle
actual connections between tasks (ie. higher level protocols). A routing node on
the other hand keep information about a lot of things, and perform routing
lookups, tables, and updates both of itself, and of other routing nodes. I would
suspect this is what you call a "full-blown" DECnet.
Now, DECnet on the PRO is endnode only. (Sheesh, where do people get all their
bogus information from???)
And P/OS was about as much single-user as Windows XP (make of that what you want).
>> However, the bastardization didn't stop with a sick version of RSX.
>> For being a PDP-11, it was a very bastardized version of a PDP-11 as
>> well.
>> DEC really struggeled to make sure that no software that played with
>> hardware on a PDP-11 would work fine on a Pro. That was a good killer.
>
> That one sounds like another NIH that afflicted every RSX development
> attempt.
Excuse me? Didn't you read what I wrote? This was a paragraph about the
*hardware*. What do RSX have to do with that??
You seem to be so fond of bashing RSX that you can't wait to take another cheap
shot at it, even when there actually aren't any to take.
>>> The DECmate was claimed to run one of the world's most popular word
>>> processing program, it was a PDP-8. Why DEC thought the world needed
>>> a brand new PDP-8 in 82/83 in beyond my brain.
>
> Sigh! Wang.
Probably true. They wanted to get at Wang with the DECmate. Sounds likely...
Stupid idea, though.
>> Yes. The incompatibilities with the IBM PC was a real problem for the
>> Rainbow.
>> DEC didn't understand the software-as-comodity idea.
>
> Bell was trying his damnedest to turn DEC back into a hardware company.
> He never understood that software was as important to sell this
> hardware. It was impossible for him to accept that software might
> be more important than the hardware.
Quit the Bell bashing, please. I'm just about fed up with it, and it don't
really hold water that well.
You are after all talking about the man who put a lot of focus on the network as
the computer, and that everything should be accessible from anywhere, running
the same software everywhere and so on. Very software-centric I'd say.
That you have some personal peeve with him is hardly interesting or relevant here.
>>> Three "personal computers" with three different CPUs, three different
>>> operating systems.
>>>
>>> Stunning incompetence.
>
> Do you think those development groups talked to each other?
Of course they didn't.
>> Stunning wrong ideas on where things were going, I'd say.
>> And it should atlest been a little bit obvious that some of the things
>> DEC did was in the wrong direction. The DECmate should not have been
>> done. Writing a word processing package for one of the other machines
>> wouldn't have cost as much. But they were still trying to lock
>> customers in.
>
> The DECmate was to compete with Wang. At that time, Wang hadn't hit
> its support saturation point yet.
It was still pretty obvious already that any machine could act as a word
processor. Wang was living on because they had a large installed base. But it
was just a question of time.
jmfbah
Right.
>
> Now, DECnet on the PRO is endnode only. (Sheesh, where do people get all
> their bogus information from???)
I had to certify the PDP-10 DECnet implementations against it. Routing
was one of the things we had to pass. You guys talk about bloat on
PeeCees. A pro was so bloated with DECnet, I didn't see how anybody
could get any work done on one of those.
>
> And P/OS was about as much single-user as Windows XP (make of that what
> you want).
From a user's POV, it sucked.
>
>>> However, the bastardization didn't stop with a sick version of RSX.
>>> For being a PDP-11, it was a very bastardized version of a PDP-11 as
>>> well.
>>> DEC really struggeled to make sure that no software that played with
>>> hardware on a PDP-11 would work fine on a Pro. That was a good killer.
>>
>> That one sounds like another NIH that afflicted every RSX development
>> attempt.
>
> Excuse me? Didn't you read what I wrote? This was a paragraph about the
> *hardware*.
And the one before that was software.
> What do RSX have to do with that??
>
> You seem to be so fond of bashing RSX that you can't wait to take
> another cheap shot at it, even when there actually aren't any to take.
RSX was a fine OS for certain things. When I bash, I bash the mental
analness of some people.
>
>>>> The DECmate was claimed to run one of the world's most popular word
>>>> processing program, it was a PDP-8. Why DEC thought the world needed
>>>> a brand new PDP-8 in 82/83 in beyond my brain.
>>
>> Sigh! Wang.
>
> Probably true. They wanted to get at Wang with the DECmate. Sounds
> likely... Stupid idea, though.
Not at that time. Think about it. The fever of the biz during those
few years was distributed processing. Every manufacturer was trying
to figure out what that meant.
>
>>> Yes. The incompatibilities with the IBM PC was a real problem for the
>>> Rainbow.
>>> DEC didn't understand the software-as-comodity idea.
>>
>> Bell was trying his damnedest to turn DEC back into a hardware company.
>> He never understood that software was as important to sell this
>> hardware. It was impossible for him to accept that software might
>> be more important than the hardware.
>
> Quit the Bell bashing, please. I'm just about fed up with it, and it
> don't really hold water that well.
I'm not bashing. I'm telling you what happened and why it happened.
> You are after all talking about the man who put a lot of focus on the
> network as the computer, and that everything should be accessible from
> anywhere, running the same software everywhere and so on. Very
> software-centric I'd say.
>
> That you have some personal peeve with him is hardly interesting or
> relevant here.
You weren't there. You didn't clean up his messes.
>
>>>> Three "personal computers" with three different CPUs, three
>>>> different operating systems.
>>>>
>>>> Stunning incompetence.
>>
>> Do you think those development groups talked to each other?
>
> Of course they didn't.
Then you should understand why and how those three messes happened.
>
>>> Stunning wrong ideas on where things were going, I'd say.
>>> And it should atlest been a little bit obvious that some of the
>>> things DEC did was in the wrong direction. The DECmate should not
>>> have been done. Writing a word processing package for one of the
>>> other machines wouldn't have cost as much. But they were still trying
>>> to lock customers in.
>>
>> The DECmate was to compete with Wang. At that time, Wang hadn't hit
>> its support saturation point yet.
>
> It was still pretty obvious already that any machine could act as a word
> processor.
Again, the computing biz was trying to figure out how to implement and
manage distributed processing. Word processing was one of the tasks
that could be "distributed" to its own system. IBM was going through
the same throes. This was also at a time when the economy and interest
rates were horrible. The US biz had not recovered from the oil embargo
of the early 70s and was also whammied by Carter's administrative
fiascos. And the S&Ls were starting to drain life blood but nobody
noticed yet.
Not any machine could do dedicated word processing on a TTY screen
yet. Most software was still hard-copy oriented.
/BAH
Pat Farrell
> Well, the Pro ran a bastardized version of RSX-11. True. But it did run
> DECnet.
> You even had ethernet on it. Which were all good things.
Well, ok, Of course, TOPS-20 didn't have Ethernet Decnet
> DEC didn't understand the software-as-comodity idea.
Yes.
> But they were still trying to lock customers in.
As was IBM with their later PS/2 and the myth that OS/2 required a PS/2
Pat Farrell
> Do you think those development groups talked to each other?
Let me guess, do I get three chances?
Guess 1) No, never.
Pat Farrell
> It was still pretty obvious already that any machine could act as a word
> processor. Wang was living on because they had a large installed base.
> But it was just a question of time.
Wang had a thriving business with their multi-user WP system into the
late 80s. I worked with them in 1990, they knew it was over and were
trying anything to get out of the trap. But they too had a corporate
mindset against change.
Mark Crispin
> Well, ok, Of course, TOPS-20 didn't have Ethernet Decnet
Huh?
Tell that to the people who did DECnet over Ethernet on TOPS-20. It
didn't happen until release 6, but it did happen.
Mark Crispin
> was just too weird.
I agree. Rainbow could have been the start of a successful PC strategy,
but it was self-doomed from the onset.
On top of all the other reasons to bash Rainbow, there was one
particularly stunning market blunder that I saw at once. With a name like
Rainbow, you would not expect the standard graphics to be monochrome.
IMHO, Digital might have pulled it off if color was standard and there was
sufficient video RAM to avoid GIGI's wierdnesses. Those of you who have a
GIGI know what I'm talking about.
The psychology of the market is such that you can sell overpriced products
if there are sufficient dainties that can be used to justify it.
> Stunning incompetence.
Absolutely.
Mark Crispin
> Quit the Bell bashing, please. I'm just about fed up with it, and it don't
> really hold water that well.
> You are after all talking about the man who put a lot of focus on the network
> as the computer, and that everything should be accessible from anywhere,
> running the same software everywhere and so on. Very software-centric I'd
> say.
I agree with Johnny.
Gordon Bell made many decisions that were highly unpopular with many of
us; and many of us disagree with those decisions to this day.
Nonetheless, the man has a clue. I've read many of his writings, and I've
had the privilege of talking with him at length on multiple occasions.
His views are not at all unreasonable, and the decisions that he made make
sense in that context.
Arguably, Digital's later failures were a result of failing to follow
through on Bell's vision. Nothing will kill a company faster than
chaos and lack of direction. Bell was long gone by that time.
Bell did not kill the PDP-10. LCG did. LCG had a very narrow window of
opportunity, and missed it spectacularly.
No, Barb, I do not blame the continuation of the -10 for LCG's failures.
The continuation of the -10 was a symptom of the disease, not the disease
itself.
Johnny Billquist
> Johnny Billquist wrote:
>> jmfbah skrev:
>>> Johnny Billquist wrote:
>>>> You even had ethernet on it. Which were all good things.
>>>
>>> Yes but it shouldn't have had full-blown DECnet if it was really
>>> supposed to be a single user system.
>>
>> I think we've already hashed through this, Barb. But I'll repeat it
>> again, for you (and anyone elses benifit, who might not have catched
>> it the first time).
>>
>> DECnet comes basically in two flavours. Endnode and routing node.
>> Endnodes are stripped down to the basic functionality that are
>> required to even exist on a DECnet network, and thus is definitely not
>> what anyone could consider "full blown". They have almost no idea of
>> how to do anything except talk to the closest router, which they must
>> have a direct connection to, and how do handle actual connections
>> between tasks (ie. higher level protocols). A routing node on the
>> other hand keep information about a lot of things, and perform routing
>> lookups, tables, and updates both of itself, and of other routing
>> nodes. I would suspect this is what you call a "full-blown" DECnet.
>
> Right.
Thank god we agree on that.
>> Now, DECnet on the PRO is endnode only. (Sheesh, where do people get
>> all their bogus information from???)
>
> I had to certify the PDP-10 DECnet implementations against it. Routing
> was one of the things we had to pass. You guys talk about bloat on
> PeeCees. A pro was so bloated with DECnet, I didn't see how anybody
> could get any work done on one of those.
You might have had to do routine. The PRO definitely didn't. The PRO still can't
act as a routing node, and I have the latest (last) release here running on a
PRO-380 right now, and the documentation.
If you think that the PRO can act as a router, you have been dreaming on your job.
It don't even make any sense to have it act as a router since it only can have
one ethernet interface. Not much point in routing between ethernet and the same
ethernet.
Later versions of PRO/DECnet can also use the serial port for decnet over DDCMP,
but that wasn't until V3, which was at a time when the PDP-10 line had already
been cancelled.
Oh, and when you run a recent version you can have both ethernet and the serial
line used by DECnet, but then only one of them is active. The other is a hot
standby.
>> And P/OS was about as much single-user as Windows XP (make of that
>> what you want).
>
> From a user's POV, it sucked.
So does Windows XP. :-)
See, they are very similar.
>>>> However, the bastardization didn't stop with a sick version of RSX.
>>>> For being a PDP-11, it was a very bastardized version of a PDP-11 as
>>>> well.
>>>> DEC really struggeled to make sure that no software that played with
>>>> hardware on a PDP-11 would work fine on a Pro. That was a good killer.
>>>
>>> That one sounds like another NIH that afflicted every RSX development
>>> attempt.
>>
>> Excuse me? Didn't you read what I wrote? This was a paragraph about
>> the *hardware*.
>
> And the one before that was software.
Yes. So if you wanted to comment on the software, make the comment on the software.
What were your gripe with the software then? Specifically, what was the problem
that in any way was related to RSX? The fact that P/OS sucks have much less to
do with RSX than the idea that they wanted to make something "user friendly",
while at the same time making customers pay to get even close to a usable system
(having any kind of command line environment as a separate add-on product).
P/OS is basically RSX-11M-PLUS, but with some parts stripped away, and some
other parts added on. The parts they stripped away were some very useful parts,
and the stuff they added were either adaptations to the hardware, which was
neccesitated by the perverted hardware, or some extra features they needed for
their user-friendly ideas.
>> You seem to be so fond of bashing RSX that you can't wait to take
>> another cheap shot at it, even when there actually aren't any to take.
>
> RSX was a fine OS for certain things. When I bash, I bash the mental
> analness of some people.
When called for, I have no problem with that. Mental analness is never good.
>>>>> The DECmate was claimed to run one of the world's most popular word
>>>>> processing program, it was a PDP-8. Why DEC thought the world
>>>>> needed a brand new PDP-8 in 82/83 in beyond my brain.
>>>
>>> Sigh! Wang.
>>
>> Probably true. They wanted to get at Wang with the DECmate. Sounds
>> likely... Stupid idea, though.
>
> Not at that time. Think about it. The fever of the biz during those
> few years was distributed processing. Every manufacturer was trying
> to figure out what that meant.
I was very sceptical to Wangs business idea from the first day I heard of it.
Maybe it was because I didn't know and understand enough back then, but then
again, time proved me right. They were at a dead end.
>>>> Yes. The incompatibilities with the IBM PC was a real problem for
>>>> the Rainbow.
>>>> DEC didn't understand the software-as-comodity idea.
>>>
>>> Bell was trying his damnedest to turn DEC back into a hardware company.
>>> He never understood that software was as important to sell this
>>> hardware. It was impossible for him to accept that software might
>>> be more important than the hardware.
>>
>> Quit the Bell bashing, please. I'm just about fed up with it, and it
>> don't really hold water that well.
>
> I'm not bashing. I'm telling you what happened and why it happened.
Sorry. I no longer care to listen when you start claiming you're telling
absolute truths about things at DEC. It's been too many times when your claims
have been bogus.
>> You are after all talking about the man who put a lot of focus on the
>> network as the computer, and that everything should be accessible from
>> anywhere, running the same software everywhere and so on. Very
>> software-centric I'd say.
>>
>> That you have some personal peeve with him is hardly interesting or
>> relevant here.
>
> You weren't there. You didn't clean up his messes.
I believe he was still there after you quit. Or did you stay around playing with
anything else after T10?
> Not any machine could do dedicated word processing on a TTY screen
> yet. Most software was still hard-copy oriented.
Give me a break. We're talking about the early 80s here. Everyone but IBM had
stopped using punched cards.
Most software wasn't hard-copy oriented any more. The home computer revolution
wasn't a revolution any longer, but instead a growing business. DEC had already
introduced the VT100. Heck, they had even introduced the VT200.
Hard-copy? No, that was five years earlier. By the early 80s, we had DECnet
phase IV, word processing existed in one form or other on most platforms, and
electronic mail was no longer a novelty.
Eric Smith
> Bell did not kill the PDP-10. LCG did. LCG had a very narrow window
> of opportunity, and missed it spectacularly.
From the hardware point of view, the Jupiter memos on Bitsavers show that
it was a complete fiasco, and that without a doubt killing Jupiter was the
correct decision. Had Jupiter been introduced as designed, it would not
have sold, as it would have been significantly more expensive than a KL10
with very little performance benefit. Without a new high-end processor,
the PDP-10 was clearly doomed, and in 1983 it was probably too late to
start a new high-end processor design from scratch.
The bigger question is how they arrived at that point. My guess is
that all of the hardware engineers that might have had a clue as to
how to build a high-performance PDP-10 had already moved on to greener
pastures, either within DEC or at other companies, and that by the
time they started the Jupiter project, they only had relatively
inexperienced engineers on staff to work on it. They spent too much
time resting on their KL10 laurels.
I wonder what would have happened had they started work in the
1978-1980 timeframe on building a PDP-10 processor chip (or perhaps a
chip set)? Starting at that time probably would have resulted in a
processor with performance a little better than a KA10, which might
not have been too interesting as a uniprocessor (except perhaps as a
cost reduction for a KS10-like system), but might have worked as an
SMP processor for TOPS-10, and in clusters for TOPS-20.
Pat Farrell
>> Well, ok, Of course, TOPS-20 didn't have Ethernet Decnet
>
> Huh?
> Tell that to the people who did DECnet over Ethernet on TOPS-20. It
> didn't happen until release 6, but it did happen.
And when was that? Let me revise and extend my remarks. Tops-20 Decnet
was crippled past the point where it could solve the problems that the
lack of a much faster processor could solve.
We worked on developing distributed systems with Pro-350/380 to offload
minor crap from the KL to make it live longer.
DecNet Phase 3 was the great solution. By the time it came out, it was
too late.
Pat Farrell
> with very little performance benefit. Without a new high-end processor,
> the PDP-10 was clearly doomed, and in 1983 it was probably too late to
> start a new high-end processor design from scratch.
>
> The bigger question is how they arrived at that point. My guess is
> that all of the hardware engineers that might have had a clue as to
> how to build a high-performance PDP-10 had already moved on to greener
> pastures, either within DEC or at other companies, and that by the
> time they started the Jupiter project, they only had relatively
> inexperienced engineers on staff to work on it. They spent too much
> time resting on their KL10 laurels.
I think this is the key. KLs from 75 needed to be replaced in 78. Not
83. And in 78, a modest performance improvement (as long as it also
improved the cost and power needs) would have helped fund the effort in
81 to make something much, much faster than the Jupitor.
Mike Ross
Point of order: is there, somewhere, a benchmark performance (and
price/performance) comparison of KI, KL, KS etc. vs. clones (SC, TOAD etc.)?
I'm just wondering if the clone makers managed to do something that DEC
evidently couldn't do... I scarcely know anything about the clones so don't
really even know how to frame the question.
Mark Crispin
> From the hardware point of view, the Jupiter memos on Bitsavers show that
> it was a complete fiasco, and that without a doubt killing Jupiter was the
> correct decision.
My sources on the inside tell me that both Jupiter and Venus (which
eventually saw the light of day as the VAX 8600) were in deep trouble, and
Alan Kotok was finally brought in to take charge. Supposedly, he reported
that he could save one, but not both; and asked which one he was to save.
> Had Jupiter been introduced as designed, it would not
> have sold, as it would have been significantly more expensive than a KL10
> with very little performance benefit.
Yup.
> The bigger question is how they arrived at that point. My guess is
> that all of the hardware engineers that might have had a clue as to
> how to build a high-performance PDP-10 had already moved on to greener
> pastures, either within DEC or at other companies, and that by the
> time they started the Jupiter project, they only had relatively
> inexperienced engineers on staff to work on it.
That is part of the equation. The lack of adult supervision was another.
> I wonder what would have happened had they started work in the
> 1978-1980 timeframe on building a PDP-10 processor chip (or perhaps a
> chip set)?
Well, there was Minnow... ;-)
Mark Crispin
> Point of order: is there, somewhere, a benchmark performance (and
> price/performance) comparison of KI, KL, KS etc. vs. clones (SC, TOAD etc.)?
I have the following Dhrystones:
KS 425
KL 2065 1946
TOAD-1 3163
I don't have numbers for Foonly or SC. I *think* that the later Foonly
machines (F2, F2, F3, F4) were between KS and KL speed; and that the SC-30
was slightly slower than a TOAD-1 and the SC-40 was slightly faster. In
other words, the clone makers did not build speed demons with the
exception of Foonly's single F1.
By comparison, my klh10-based TOPS-20 system (Lingling), built in 2001
using commodity hardware, is 31847.
Here are some other DEC processors:
VAX 2000 1379
PMAX 34883
Alpha 142857
Alpha 4/233 488997
bob
> bob wrote:
>> jmfbah wrote:
>>> Eric Smith wrote:
>>>> jmfbah wrote:
>>>>> So the first K in the parts list meant "CPU".
>>>>
>>>> Nearly always.
>>>>
>>>> Just as an initial "M" was almost always main memory, an initial "R"
>>>> was almost always a disk or drum, etc.
>>>
>>> Nearly? The parts naming assignments didn't have exceptions AFAIK. I
>>> never did learn the formulas; it was on my list of things to learn
>>> about the company after finishing up the -10 to VMS migrations.
>>>
>>> /BAH
>> K was = as barb said = almost always CPU some exceptions were the KG
>> series, the KL series (console terminal connection mechanisms) and
>> some times the switch panel mechanism or memory extension and
>> timeshare controller.
>> Dick Best was the keeper of the list, one could negotiate both
>> designators and module numbers in some cases.
>> .b
>
> Do you know who he negotiated with? I never had any sense about how
> any of that part of the biz worked. I do know that the product managers
> had something to do with it and I suspected SDC has some involvement
> but I never knew if they had any control over naming things.
>
sometimes we went to Dick with a projected name - sometimes driven
by the marketing folks, sometimes by the design team, sometimes by the
phase of the moon (or some twisted reason).
On occaision, things did not go as planned, and a different name was
picked, assigned, or negotiated. Generally, when there was a team
involved - including SDC = things were easy. When it was a bootleg
project, it sometimes ran into problmes.
> I did get the practice started of having "spec reviews" of the BOMs
> before we shipped (rather than after). Not only did we ensure
> that the BOMs were correct, but all departments got an education
> in that mess. It may not have been a mess but it sure looked like
> to somebody who could code machines.
>
> /BAH
bob
> On Fri, 6 Jun 2008, Johnny Billquist posted:
>> Quit the Bell bashing, please. I'm just about fed up with it, and it
>> don't really hold water that well.
>> You are after all talking about the man who put a lot of focus on the
>> network as the computer, and that everything should be accessible from
>> anywhere, running the same software everywhere and so on. Very
>> software-centric I'd say.
>
> I agree with Johnny.
>
> Gordon Bell made many decisions that were highly unpopular with many of
> us; and many of us disagree with those decisions to this day.
products. BUT those opinions have to be based on something more than
emotion.
>
> Nonetheless, the man has a clue. I've read many of his writings, and
> I've had the privilege of talking with him at length on multiple
> occasions. His views are not at all unreasonable, and the decisions that
> he made make sense in that context.
>
CG is a brilliant guy, I did agree with some of his approaches, did not
agree with others, but I have to agree that his decisions made sense in
the context of his vision. But I believe, and in my professional opinion,
his vision was limited to a product line - I am talking 70s here, after
he returned from CMU. His penchant for what we called the purple plague,
be it 11 or vax, was a detriment to the company. Again, this is my
opinion. I believe the facts bear me out, and his influence on Cutler
and others shaped the 80s, and the rest of the story. I am not bashing
vax or vms or 11s, just still smarting from resources being pulled to
bolster that product line set to the detriment of the company.
Constructive friction can lead to synergy.
> Arguably, Digital's later failures were a result of failing to follow
> through on Bell's vision. Nothing will kill a company faster than chaos
> and lack of direction. Bell was long gone by that time.
>
Mark, we disagree on the issue of CGs vision. Ever since the meeting
with Mario Shafner (spelling?) I have referred to him as CG. As I said
above his vision was focused on a product line. A single product line
means niche market, and that is where the company was going.
> Bell did not kill the PDP-10. LCG did. LCG had a very narrow window of
> opportunity, and missed it spectacularly.
>
Ah, we disagree on this point too, CG was culpable in slowing down the
delivery of product. I can not recall how many meetings we had to attend
to brief the consulting engineer cadre on what we were doing, iirc, more
than 3 times a week - prep, research, and presentation of data
distracted from time on target for designing systems. Arguing about nits
and crap destroyed concentration. yes, by 81 the writing was on the
wall, the 10 would be stopped by the purple plague mentality. yes,
alpha was a ray of hope and potential. The user perceptions of VMS
> No, Barb, I do not blame the continuation of the -10 for LCG's failures.
> The continuation of the -10 was a symptom of the disease, not the
> disease itself.
In this instance we agree, I saw the single focus on the vax family as
a symptom of the malaise - along with the change in culture with the
ingest of marketing and management folks from companies that had gone
bellyup. My point is this is a complex issue - with many contributing
factors - and not all tied to the failure to market and take advantage
of the marketplace. DEC was a pretty good engineering company. Digital
was not a bad software company.
bob
Johnny Billquist
> Mark Crispin wrote:
>> Arguably, Digital's later failures were a result of failing to follow
>> through on Bell's vision. Nothing will kill a company faster than
>> chaos and lack of direction. Bell was long gone by that time.
>>
> Mark, we disagree on the issue of CGs vision. Ever since the meeting
> with Mario Shafner (spelling?) I have referred to him as CG. As I said
> above his vision was focused on a product line. A single product line
> means niche market, and that is where the company was going.
Arguably, Microsoft have a single product line (when we talk OS) and they more
or less have achieved monopoly. So I'm not sure I can agree that a single
product line means a niche market.
Just trying to keep the pot boiling. :-)
jmfbah
Oh, sorry. I'm asking about part numbers, not names. I know how
namings were done.
/BAH
jmfbah
It even happened on TOPS-10.
/BAH
jmfbah
> On Fri, 6 Jun 2008, Johnny Billquist posted:
>> Quit the Bell bashing, please. I'm just about fed up with it, and it
>> don't really hold water that well.
>> You are after all talking about the man who put a lot of focus on the
>> network as the computer, and that everything should be accessible from
>> anywhere, running the same software everywhere and so on. Very
>> software-centric I'd say.
>
> I agree with Johnny.
>
> Gordon Bell made many decisions that were highly unpopular with many of
> us; and many of us disagree with those decisions to this day.
You weren't the one who cleaned up the messes he made when he opened
his mouth.
>
> Nonetheless, the man has a clue. I've read many of his writings, and
> I've had the privilege of talking with him at length on multiple
> occasions. His views are not at all unreasonable, and the decisions that
> he made make sense in that context.
You only know about the ones that made it outside corporate walls.
>
> Arguably, Digital's later failures were a result of failing to follow
> through on Bell's vision. Nothing will kill a company faster than chaos
> and lack of direction. Bell was long gone by that time.
>
> Bell did not kill the PDP-10.
You weren't there.
> LCG did. LCG had a very narrow window of
> opportunity, and missed it spectacularly.
You don't know what you are talking about.
>
> No, Barb, I do not blame the continuation of the -10 for LCG's failures.
> The continuation of the -10 was a symptom of the disease, not the
> disease itself.
Your contention that the -20 could replace all PDP-10 installations is
flat out wrong. TOPS-10 would have gone away when it was first
announced in 1978(?) DECUS. The bottom line was we had customers
who could not, and would not, move to -20s because -20s sucked w.r.t.
general timesharing to large numbers of users.
Even TOPS-20 developers couldn't stand it.
/BAH
jmfbah
Nope. Not dreaming. I had to certify many times. PRO including the
routing piece. I don't know why--it made no sense to me.
>
> It don't even make any sense to have it act as a router since it only
> can have one ethernet interface. Not much point in routing between
> ethernet and the same ethernet.
Huh?
> Later versions of PRO/DECnet can also use the serial port for decnet
> over DDCMP, but that wasn't until V3, which was at a time when the
> PDP-10 line had already been cancelled.
Honey, the hardware was cancelled, not the software. DECnet Phase IV
was done after Jupiter's cancellation. Doing DECnet made sense
because it would have helped the migration plan from PDP-nn's to VAXes.
> Oh, and when you run a recent version you can have both ethernet and the
> serial line used by DECnet, but then only one of them is active. The
> other is a hot standby.
>
>>> And P/OS was about as much single-user as Windows XP (make of that
>>> what you want).
>>
>> From a user's POV, it sucked.
>
> So does Windows XP. :-)
Of course :-) Like minds think alike.
> See, they are very similar.
>
>>>>> However, the bastardization didn't stop with a sick version of RSX.
>>>>> For being a PDP-11, it was a very bastardized version of a PDP-11
>>>>> as well.
>>>>> DEC really struggeled to make sure that no software that played
>>>>> with hardware on a PDP-11 would work fine on a Pro. That was a good
>>>>> killer.
>>>>
>>>> That one sounds like another NIH that afflicted every RSX development
>>>> attempt.
>>>
>>> Excuse me? Didn't you read what I wrote? This was a paragraph about
>>> the *hardware*.
>>
>> And the one before that was software.
>
> Yes. So if you wanted to comment on the software, make the comment on
> the software.
>
> What were your gripe with the software then? Specifically, what was the
> problem that in any way was related to RSX? The fact that P/OS sucks
> have much less to do with RSX than the idea that they wanted to make
> something "user friendly", while at the same time making customers pay
> to get even close to a usable system (having any kind of command line
> environment as a separate add-on product).
The problem is that the developers picked the "biggest" RSX. That
system couldn't handle it. You might as well have swapped on a
card punch.
>
> P/OS is basically RSX-11M-PLUS, but with some parts stripped away, and
> some other parts added on. The parts they stripped away were some very
> useful parts, and the stuff they added were either adaptations to the
> hardware, which was neccesitated by the perverted hardware, or some
> extra features they needed for their user-friendly ideas.
Some small computer thinkers wouldn't know user-friendly if it bit
it them on the ass.
>
>>> You seem to be so fond of bashing RSX that you can't wait to take
>>> another cheap shot at it, even when there actually aren't any to take.
>>
>> RSX was a fine OS for certain things. When I bash, I bash the mental
>> analness of some people.
>
> When called for, I have no problem with that. Mental analness is never
> good.
>
>>>>>> The DECmate was claimed to run one of the world's most popular
>>>>>> word processing program, it was a PDP-8. Why DEC thought the world
>>>>>> needed a brand new PDP-8 in 82/83 in beyond my brain.
>>>>
>>>> Sigh! Wang.
>>>
>>> Probably true. They wanted to get at Wang with the DECmate. Sounds
>>> likely... Stupid idea, though.
>>
>> Not at that time. Think about it. The fever of the biz during those
>> few years was distributed processing. Every manufacturer was trying
>> to figure out what that meant.
>
> I was very sceptical to Wangs business idea from the first day I heard
> of it. Maybe it was because I didn't know and understand enough back
> then, but then again, time proved me right. They were at a dead end.
That's not what killed Wang. Wang ended up having to support every
copy of every product they ever shipped...all of them. New versions
never replaced older versions.
>
>>>>> Yes. The incompatibilities with the IBM PC was a real problem for
>>>>> the Rainbow.
>>>>> DEC didn't understand the software-as-comodity idea.
>>>>
>>>> Bell was trying his damnedest to turn DEC back into a hardware company.
>>>> He never understood that software was as important to sell this
>>>> hardware. It was impossible for him to accept that software might
>>>> be more important than the hardware.
>>>
>>> Quit the Bell bashing, please. I'm just about fed up with it, and it
>>> don't really hold water that well.
>>
>> I'm not bashing. I'm telling you what happened and why it happened.
>
> Sorry. I no longer care to listen when you start claiming you're telling
> absolute truths about things at DEC. It's been too many times when your
> claims have been bogus.
Based on what? Mark's ramblings? Work I had to do but was never
officially documented because that would have lost sales?
>
>>> You are after all talking about the man who put a lot of focus on the
>>> network as the computer, and that everything should be accessible
>>> from anywhere, running the same software everywhere and so on. Very
>>> software-centric I'd say.
>>>
>>> That you have some personal peeve with him is hardly interesting or
>>> relevant here.
>>
>> You weren't there. You didn't clean up his messes.
>
> I believe he was still there after you quit.
I didn't quit.
>Or did you stay around
> playing with anything else after T10?
It wasn't just me who cleaned up messes. Your idea of when the
PDP-10 business stopped is a decade too early.
>
>> Not any machine could do dedicated word processing on a TTY screen
>> yet. Most software was still hard-copy oriented.
>
> Give me a break. We're talking about the early 80s here.
Yes.
>Everyone but
> IBM had stopped using punched cards.
I'm not talking cards; I'm talking hardcopy TTYs.
> Most software wasn't hard-copy oriented any more. The home computer
> revolution wasn't a revolution any longer, but instead a growing
> business. DEC had already introduced the VT100. Heck, they had even
> introduced the VT200.
In 1982? DEC was still developing new models of hard-copy TTYs.
> Hard-copy? No, that was five years earlier. By the early 80s, we had
> DECnet phase IV,
No. Not in 82. Phase IV was a couple years later. In 82 we were still
waiting for the final signoff on Phase IV.
> word processing existed in one form or other on most
> platforms, and electronic mail was no longer a novelty.
Not in DEC. We were still in engineering and education sales and
trying to expand. Hence, the attempt at trying to make a word
processing system.
/BAH
bob
> bob skrev:
>> Mark Crispin wrote:
>>> Arguably, Digital's later failures were a result of failing to follow
>>> through on Bell's vision. Nothing will kill a company faster than
>>> chaos and lack of direction. Bell was long gone by that time.
>>>
>> Mark, we disagree on the issue of CGs vision. Ever since the meeting
>> with Mario Shafner (spelling?) I have referred to him as CG. As I said
>> above his vision was focused on a product line. A single product line
>> means niche market, and that is where the company was going.
>
> Arguably, Microsoft have a single product line (when we talk OS) and
> they more or less have achieved monopoly. So I'm not sure I can agree
> that a single product line means a niche market.
>
> Just trying to keep the pot boiling. :-)
>
> Johnny
>
Hey Johnny,
thanks for your work on saving various bits of 11 and pro stuff!
and all the work on NetBSD Vax.... still have my uVIIs running it.
Keep stirring, it gets the information, opinion, facts, and fiction
floating out there!!
8-)
bob
Mark Crispin
> Mark, we disagree on the issue of CGs vision.
Perhaps not. I don't think that he made the right choices, or even had
the right vision. But at Digital never really implemented his vision, we
can only speculate.
Bell was right on one point: Digital had lots of passed-prime products
that for one reason or another refused to die. It got to the point that
the only way to slay the beast was to massacre everything that was not in
the core strategy.
> I can not recall how many meetings we had to attend
> to brief the consulting engineer cadre on what we were doing, iirc, more
> than 3 times a week - prep, research, and presentation of data distracted
> from time on target for designing systems. Arguing about nits
> and crap destroyed concentration.
This, too, is not a cause but a symptom: a symptom of an organization
which is heading towards its abolition. It's nothing as direct as
"deliberate destruction by excessive meetings." Rather, it is more and
more management being brought in to bring the situation under control; and
being managers, they call more meetings and by doing so make the situation
worse.
A related symptom -- one which Barb seems totally unwilling and unable to
understand -- is keeping development alive for a product which has passed
its prime. Sure, the numbers still look good at that point; but when they
turn (and they will turn) it will be sudden and vicious.
It was a mistake not to EOL TOPS-10 in 1977-78 as planned. Barb's
arguments basically boil down to "you need to keep the shitty old OS
around to get decent performance on the shitty old CPU." The fallacy of
that argument is that the result is still shit.
Had there been a decent KL10 follow-on processor in 1978-79, and a
follow-on to that one in 1983, TOPS-20 probably would have made it into
the early 1990s (even after the PDP-10 was slain in 1983, the last gasps
of weren't until then) before UNIX killed it off.
Mark Crispin
> Arguably, Microsoft have a single product line (when we talk OS) and they
> more or less have achieved monopoly. So I'm not sure I can agree that a
> single product line means a niche market.
The genius in Microsoft's strategy is that (for the most part) they stayed
out of the hardware business; and even when they are in the hardware
business their software is ecumenical about the competition's hardware.
This gave the customers what they wanted: the power to fire a hardware
vendor at any time without having to undertake a migration strategy. A
Wintel box is a Wintel box; it doesn't really matter all that much who
made the box.
Microsoft is brilliant in its pricing. They give enough away for free (or
low cost) to rope the customers in (not to mention their academic
pricing), and reserve the hefty fees for the products where the customers
don't have much of a choice (Exchange, Office, and Visual Studio being
obvious examples).
Mark Crispin
>> Tell that to the people who did DECnet over Ethernet on TOPS-20. It didn't
>> happen until release 6, but it did happen.
Yes. I know.
I spent quite some time on that product. That is how I came to acquire
s/n 4664.
Specifically, although I don't know if it ever saw the light of day to
customers, I got Phase IV DECnet running on the KS under TOPS-20. It
never got as far as Ethernet though; my stuff used the KMC-11/DUP-11. I
don't know how long that system stayed up after I left, but a KS in
Colorado Springs ran it on Digital's corporate network.
I'm not sure if TOPS-10 ever got Phase IV on the KS. I had TOPS-10
sources (7.03 IIRC) to use for comparison, but IIRC it didn't build with
Phase IV on the KS.
The developers tried to make KS support possible in the DECnet code on the
-10 side, and to use common code on both the -10 and the -20 (although
forking happened anyway). This all saved me incredible amounts of time;
and most of my work ended up being in upgrading KDPSRV from Phase II to
Phase IV.
Nonetheless, there were several little things that I still had to fix
before it would actually run in TOPS-20 on the KS. There was no sign of
any of these fixes in the TOPS-10 KS sources. Some of the bugs were bugs
even on a KL, but for various reasons would not cause a crash whereas they
did on a KS.
Mark Crispin
> flat out wrong. TOPS-10 would have gone away when it was first announced in
> 1978(?) DECUS. The bottom line was we had customers
> who could not, and would not, move to -20s because -20s sucked w.r.t.
> general timesharing to large numbers of users.
They had to move anyway 5 years later.
> Even TOPS-20 developers couldn't stand it.
That has nothing to do with TOPS-20, which any sane person recognizes as a
far superior development environment to TOPS-10.
KL10 s/n 2102 was one of the worst processors that Digital ever built (OK,
2101 was worse). They couldn't sell it to a customer, so they forced the
TOPS-20 developers to use it. It had old crappy peripherals and utterly
inadequate memory. It wasn't until after the massacre that the remnants
of TOPS-20 development were given decent CPUs to use.
I (and just about every other customer who saw it) was appalled to see how
miserable 2102 was especially when there were better systems (e.g., 2136)
on hand. Yes, I know; 2136 served a different purpose. I'm not saying
that 2136 should have been used; I'm saying that 2102 should have been
scrapped years before it was.
bob
> On Sat, 7 Jun 2008, bob posted:
>> Mark, we disagree on the issue of CGs vision.
>
> Perhaps not. I don't think that he made the right choices, or even had
> the right vision. But at Digital never really implemented his vision,
> we can only speculate.
>
> Bell was right on one point: Digital had lots of passed-prime products
> that for one reason or another refused to die. It got to the point that
> the only way to slay the beast was to massacre everything that was not
> in the core strategy.
>
>> I can not recall how many meetings we had to attend
>> to brief the consulting engineer cadre on what we were doing, iirc, more
>> than 3 times a week - prep, research, and presentation of data
>> distracted from time on target for designing systems. Arguing about nits
>> and crap destroyed concentration.
>
> This, too, is not a cause but a symptom: a symptom of an organization
> which is heading towards its abolition. It's nothing as direct as
> "deliberate destruction by excessive meetings." Rather, it is more and
> more management being brought in to bring the situation under control;
> and being managers, they call more meetings and by doing so make the
> situation worse.
>
but I still call it plague. Maybe my view is colored by the way we would
compete internally to deliver what we thought was best product - and
yes, I think we kept things around way past their prime. We have talked
in the news group about decisions that made folks look at alternatives
systems and suppliers - including the closing of the architecture.
> A related symptom -- one which Barb seems totally unwilling and unable
> to understand -- is keeping development alive for a product which has
> passed its prime. Sure, the numbers still look good at that point; but
> when they turn (and they will turn) it will be sudden and vicious.
>
products - one particular customer found out the manufacturing capacity,
and ordered that many units. Did this for 2 or 3 years beyond when the
machine would have ended.
> It was a mistake not to EOL TOPS-10 in 1977-78 as planned. Barb's
> arguments basically boil down to "you need to keep the shitty old OS
> around to get decent performance on the shitty old CPU." The fallacy of
> that argument is that the result is still shit.
>
No one ever accused me of having taste - good or bad - so ... The
inherent differences, really more than nuances, between Tops 10 and 20
sort of made for dedicated followings. Business decisions to EOL
it would have resulted in some changes for sure.
> Had there been a decent KL10 follow-on processor in 1978-79, and a
> follow-on to that one in 1983, TOPS-20 probably would have made it into
> the early 1990s (even after the PDP-10 was slain in 1983, the last gasps
> of weren't until then) before UNIX killed it off.
>
DEC, Jan of 69, and asked why they weren't working with ECL - causing
some stir - the secret KL project was underway.
Yes, you know as well as I do and probably better, the need for a new
machine, more than a midlife kicker, more than a repackage, but
resources were going to vax, for good reason, and then to venus. The
technology was there to deliver, but the commitment and the drive were not.
/bob
Mark Crispin
> but I still call it plague. Maybe my view is colored by the way we would
> compete internally to deliver what we thought was best product - and yes, I
> think we kept things around way past their prime. We have talked in the news
> group about decisions that made folks look at alternatives systems and
> suppliers - including the closing of the architecture.
Plague is not a bad word; but to be fair we have to recognize that the
great solutions of 10 years ago are not necessarily the solutions of
today.
Put another way: a sign of wisdom is the recognition that the time has
come to retire as an undefeated champion.
Internal competition is good, to a degree; but not when it becomes more
focused on proving your own team right (and the other team wrong) instead
of building the best product line for the company.
> The inherent
> differences, really more than nuances, between Tops 10 and 20
> sort of made for dedicated followings. Business decisions to EOL
> it would have resulted in some changes for sure.
True, but consider this. The fact that the TOPS-20, like most modern
operating systems, a user application instead of built into the kernel (as
in TOPS-10) meant that DCL could have been ported to the -20. In fact,
bash, csh, and other UNIX shells were ported to the -20.
Imagine the possibility if DCL had been ported to the -20; not necessarily
to replace EXEC but as a choice of shells (the way people normally do on
UNIX).
> Yes, you know as well as I do and probably better, the need for a new
> machine, more than a midlife kicker, more than a repackage, but resources
> were going to vax, for good reason, and then to venus. The technology was
> there to deliver, but the commitment and the drive were not.
Yup, and sadly LCG was fighting the wrong battles for the wrong reasons.
Pat Farrell
> The genius in Microsoft's strategy is that (for the most part) they
> stayed out of the hardware business; and even when they are in the
> hardware business their software is ecumenical about the competition's
> hardware.
A lot of their hardware was to feed the software. The MS mouse was
wonderfully engineered. You didn't need a MS computer, any computer
worked. They wanted folks to have great mice to use Windows.
Worked too.
> Microsoft is brilliant in its pricing.
>[snip]
> customers don't have much of a choice (Exchange, Office, and Visual
> Studio being obvious examples).
For sure. Even before that. In 1990, IBM's OS/2 development kit cost
nearly $5000 per seat. Windows C/C++ 6 and later Visual C++ were a few
hundred bucks. If you were smart and wanted to hack some simple
programs, maybe shareware, you would do it for Windows, not OS/2.
Pat Farrell
> Even TOPS-20 developers couldn't stand it.
This one, while probably true, is a red herring.
Dec's developers worked in Macro (nearly always) or Bliss. And I can
believe that for this, TOPS-10 was a win.
But for large shared applications, TOPS-20 was a giant win. That is what
we sold. We did not sell lots of users each doing their own thing, some
in Fortran, some in Algol, some in Basic. We had 60 users running two
or three applications at a time.
Different business model, completely.
The IBM heads said we should have been doing it all under MVS, and if we
had been having 500 users, they would have been 100% correct. But then
development would have been five to ten times more expensive.
Mark Crispin
> jmfbah wrote:
>> Even TOPS-20 developers couldn't stand it.
> This one, while probably true, is a red herring.
It's a red herring for completely different reasons.
The TOPS-20 developers were forced to use a system with inadequate memory
that was the second most unreliable KL10 ever built. It wasn't until the
mid 1980s that that machine was finally replaced.
> Dec's developers worked in Macro (nearly always) or Bliss. And I can believe
> that for this, TOPS-10 was a win.
Not true. TOPS-10 was a huge loss for MACRO development compared to
any other PDP-10 operating system (Tenex, TOPS-20, ITS).
On TOPS-10, you couldn't debug a program unless you had the foresight to
link it with DDT first. If your program crashed and DDT wasn't loaded,
all you could do were E and D commands, or perhaps take a core dump.
On Tenex and TOPS-20, you could merge DDT into the program's address space
*after* the program crashed. Or, even better, you could split DDT in a
separate process between EXEC and the program. Either way, you were up
and going in the debugger.
Even better, the program could merge DDT into itself. Most of my programs
had a DDT command that did just that, and then PUSHJ'd to DDT (so R$G
would get you back).
Nobody lunk programs with DDT on any system other than TOPS-10. It wasn't
necessary. DDT.REL was only needed for TOPS-10.
In ITS, DDT was the shell, so it was always a separate process. On
TOPS-20, DDT was in the high pages on the KS and model A KLs and section
37 on model B KLs.
Mark Crispin
for the kernel hackers.
MDDT was a system call (JSYS) that let you DDT the monitor while
timesharing was still running! Now, TOPS-10 had a version of FILDDT that
would let you patch the running monitor; but MDDT was so much better.
Besides patching, you could call routines, all of which would run at UUO
level in your own process.
You could, if you were careful, even put in breakpoints in the monitor and
single-step through code, all while timesharing was running and the other
users were happily doing their thing.
Of course, MDDT was a highly dangerous tool, for wizards only; but it was
incredibly useful. It eliminated much of the need for EDDT; I would say
that my monitor DDTing was about 80% MDDT, 19% EDDT, and less than 1%
FILDDT.
Barb wouldn't know anything about MDDT; and I'll wager that she didn't do
much monitor work on TOPS-10 either.
Pat Farrell
> The TOPS-20 developers were forced to use a system with inadequate
> memory that was the second most unreliable KL10 ever built. It wasn't
> until the mid 1980s that that machine was finally replaced.
Didn't know that. By the mid 80s, who cared?
> On TOPS-10, you couldn't debug a program unless you had the foresight to
> link it with DDT first. If your program crashed and DDT wasn't loaded,
> all you could do were E and D commands, or perhaps take a core dump.
Wow, I had not remembered that. I used DDT forever. And it was so cool
on a 20, just type the command, it got merged in, and away you went.
There are times I miss DDT even today. (not that I have any clue what
the machine level stuff is on a dual core Intel cpu)
When I read Brooks' No Silver Bullet, DDT is the tool that came to mind
as a monster win for productivity.
Raid and Six12 and whatever the fortran high level language debuggers
were not nearly as wonderful. Of course, the memories are worn on this.