Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #212313 > unrolled thread
| Started by | Iron Spring Software <Peter_Flass@Yahoo.com> |
|---|---|
| First post | 2020-07-24 09:38 -0700 |
| Last post | 2020-07-30 20:27 +0000 |
| Articles | 20 on this page of 164 — 35 participants |
Back to article view | Back to alt.folklore.computers
DEC Iron Spring Software <Peter_Flass@Yahoo.com> - 2020-07-24 09:38 -0700
Re: DEC Mike Spencer <mds@bogus.nodomain.nowhere> - 2020-07-24 17:12 -0300
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-24 17:14 -0400
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-24 19:43 -0700
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-24 23:28 -0400
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-25 02:06 -0700
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 05:27 -0400
Re: DEC Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-25 10:58 +0100
Re: 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-07-25 17:21 +0000
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 13:54 -0400
Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 14:43 -0700
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 18:05 -0400
Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 20:27 -0400
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 21:08 -0400
Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 23:29 -0400
Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 23:30 -0400
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-26 00:06 -0400
Re: 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-05 06:06 +0000
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-07 10:19 -0400
Re: 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-07 20:01 +0000
Re: wiki software, not 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-08-07 22:45 +0000
Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-08 13:35 -0400
Re: wiki software, not 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-09 15:33 +0000
Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-09 13:16 -0400
Re: wiki software, not 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-08-09 15:00 -0400
Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-09 18:35 -0400
Re: wiki software, not 360 PCs was DEC maus <maus@dmaus.org> - 2020-08-10 23:10 +0000
Re: wiki software, not 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-09 19:18 +0000
Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-09 18:40 -0400
Re: wiki software, not 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-09 15:30 -0700
Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 18:39 -0700
Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 18:43 -0700
Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 23:32 -0400
Re: 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-07-26 21:45 +0000
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-26 18:01 -0400
Re: 360 PCs was DEC Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-27 06:38 +0100
Re: 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-07-26 01:24 +0000
Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 18:39 -0700
Re: 360 PCs was DEC Bob Eager <news0073@eager.cx> - 2020-07-26 20:18 +0000
Re: 360 PCs was DEC Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-25 19:39 +0100
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-25 12:50 -0700
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-25 02:26 -0700
Re: DEC usenet@only.tnx (Questor) - 2020-07-26 19:23 +0000
Re: DEC Thomas Koenig <tkoenig@netcologne.de> - 2020-07-26 21:05 +0000
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-26 16:23 -0700
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-26 21:24 -0400
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-27 11:42 -0700
Re: DEC archaeology John Levine <johnl@taugh.com> - 2020-07-27 02:41 +0000
Re: DEC archaeology Andy Burns <usenet@andyburns.uk> - 2020-07-27 07:37 +0100
Re: DEC archaeology Thomas Koenig <tkoenig@netcologne.de> - 2020-07-27 07:10 +0000
Re: DEC archaeology Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-27 09:03 +0100
Re: DEC archaeology Michael LeVine <mlevinespmfltr@redshift.com> - 2020-07-27 02:09 -0700
Re: DEC archaeology Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-27 11:27 +0100
Origin of Niven/Pournelle quips (was: DEC archaeology) Thomas Koenig <tkoenig@netcologne.de> - 2020-07-27 12:22 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Rich Alderson <news@alderson.users.panix.com> - 2020-07-27 20:51 -0400
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-28 06:02 +0100
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Bob Eager <news0073@eager.cx> - 2020-07-28 08:29 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-07-28 17:30 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) djheydt@kithrup.com (Dorothy J Heydt) - 2020-07-28 18:18 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Bob Eager <news0073@eager.cx> - 2020-07-28 19:57 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-28 21:32 +0100
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) djheydt@kithrup.com (Dorothy J Heydt) - 2020-07-28 21:34 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) J. Clarke <jclarke.873638@gmail.com> - 2020-07-28 18:33 -0400
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-28 20:55 +0100
Re: DEC archaeology John Levine <johnl@taugh.com> - 2020-07-27 14:53 +0000
Re: DEC archaeology drb@ihatespam.msu.edu (Dennis Boone) - 2020-07-27 11:30 -0500
Re: DEC archaeology scott@slp53.sl.home (Scott Lurndal) - 2020-07-27 16:37 +0000
Re: DEC archaeology drb@ihatespam.msu.edu (Dennis Boone) - 2020-07-28 10:24 -0500
Re: DEC archaeology scott@slp53.sl.home (Scott Lurndal) - 2020-07-28 15:59 +0000
Re: DEC archaeology Peter Flass <peter_flass@yahoo.com> - 2020-07-27 11:42 -0700
Re: DEC archaeology J. Clarke <jclarke.873638@gmail.com> - 2020-07-27 18:47 -0400
Re: DEC archaeology Quadibloc <jsavard@ecn.ab.ca> - 2020-07-27 17:43 -0700
Re: DEC usenet@only.tnx (Questor) - 2020-07-28 03:21 +0000
Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-07-28 17:30 +0000
Re: ou sont les ordinateurs d'antan, was DEC John Levine <johnl@taugh.com> - 2020-07-28 20:27 +0000
Re: ou sont les ordinateurs d'antan, was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-28 18:53 -0400
Re: ou sont les ordinateurs d'antan, was DEC Gareth Evans <headstone255@yahoo.com> - 2020-07-29 10:36 +0100
Re: ou sont les ordinateurs d'antan, was DEC Andreas Eder <a_eder_muc@web.de> - 2020-08-02 12:55 +0200
Re: ou sont les ordinateurs d'antan, was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-02 12:49 -0400
Re: ou sont les ordinateurs d'antan, was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-29 14:08 -0700
Re: ou sont les ordinateurs d'antan, was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-29 14:04 -0700
Re: DEC Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2020-07-30 03:49 -0600
Re: DEC scott@slp53.sl.home (Scott Lurndal) - 2020-07-30 14:41 +0000
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-30 10:12 -0700
Re: DEC scott@slp53.sl.home (Scott Lurndal) - 2020-07-30 18:40 +0000
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-30 12:02 -0700
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-07-31 02:38 -0700
Re: DEC large computers John Levine <johnl@taugh.com> - 2020-07-31 20:21 +0000
Re: DEC large computers Thomas Koenig <tkoenig@netcologne.de> - 2020-07-31 23:23 +0000
Re: DEC large computers J. Clarke <jclarke.873638@gmail.com> - 2020-07-31 21:13 -0400
Re: DEC large computers Thomas Koenig <tkoenig@netcologne.de> - 2020-08-01 10:39 +0000
Re: vectors, was DEC large computers John Levine <johnl@taugh.com> - 2020-08-01 02:21 +0000
Re: vectors, was DEC large computers Bob Eager <news0073@eager.cx> - 2020-08-01 11:14 +0000
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-07-31 20:30 -0700
Re: IBM models 91, 195 & CDC 7600 Dan Espen <dan1espen@gmail.com> - 2020-08-01 00:00 -0400
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:20 -0700
Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-01 07:00 -0700
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 08:18 -0700
Re: IBM models 91, 195 & CDC 7600 Dan Espen <dan1espen@gmail.com> - 2020-08-01 11:52 -0400
Re: IBM models 91, 195 & CDC 7600 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-02 21:58 +0000
Re: IBM models 91, 195 & CDC 7600 Dan Espen <dan1espen@gmail.com> - 2020-08-02 18:50 -0400
Re: IBM models 91, 195 & CDC 7600 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-03 18:23 +0000
Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-03 13:34 -0700
Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-01 00:55 -0700
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:27 -0700
Re: IBM models 91, 195 & CDC 7600 John Levine <johnl@taugh.com> - 2020-08-01 17:27 +0000
Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-01 12:11 -0700
Re: IBM models 91, 195 & CDC 7600 Bob Eager <news0073@eager.cx> - 2020-08-01 19:56 +0000
Re: IBM models 91, 195 & CDC 7600 John Levine <johnl@taugh.com> - 2020-08-01 20:18 +0000
Re: IBM models 91, 195 & CDC 7600 Bob Eager <news0073@eager.cx> - 2020-08-01 23:42 +0000
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 20:32 -0700
Re: IBM models 91, 195 & CDC 7600 Gerard Schildberger <gerard46@rrt.net> - 2020-08-02 12:58 -0700
Re: IBM models 91, 195 & CDC 7600 J. Clarke <jclarke.873638@gmail.com> - 2020-08-01 16:28 -0400
Re: IBM models 91, 195 & CDC 7600 David Lesher <wb8foz@panix.com> - 2020-08-02 20:42 +0000
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 20:27 -0700
Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-02 00:28 -0700
Re: IBM models 91, 195 & CDC 7600 Thomas Koenig <tkoenig@netcologne.de> - 2020-08-02 08:01 +0000
Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 16:47 -0700
Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 19:45 -0700
Re: IBM models 91, 195 & CDC 7600 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-08-03 21:00 -0600
Re: IBM models 91, 195 & CDC 7600 scott@slp53.sl.home (Scott Lurndal) - 2020-08-02 22:45 +0000
Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-03 07:45 -0700
Re: IBM models 91, 195 & CDC 7600 "Kerr-Mudd,John" <notsaying@127.0.0.1> - 2020-08-01 08:24 +0000
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:30 -0700
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:34 -0700
Re: DEC large computers Quadibloc <jsavard@ecn.ab.ca> - 2020-08-01 00:51 -0700
Re: DEC large computers robin.vowels@gmail.com - 2020-08-01 02:23 -0700
Jupiter alternatives [was Re: DEC] Rich Alderson <news@alderson.users.panix.com> - 2020-07-31 21:16 -0400
Re: Jupiter alternatives [was Re: DEC] Robert Swindells <rjs@fdy2.co.uk> - 2020-08-01 01:56 +0000
Re: Jupiter alternatives [was Re: DEC] Adam Sampson <ats@offog.org> - 2020-08-01 15:59 +0100
Re: Jupiter alternatives [was Re: DEC] Rich Alderson <news@alderson.users.panix.com> - 2020-08-01 22:09 -0400
Re: Jupiter alternatives [was Re: DEC] Rich Alderson <news@alderson.users.panix.com> - 2020-08-01 22:07 -0400
Re: DEC usenet@only.tnx (Questor) - 2020-08-03 00:32 +0000
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-02 23:54 -0700
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-03 07:45 -0700
Re: DEC robin.vowels@gmail.com - 2020-08-03 09:16 -0700
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 10:10 -0700
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-03 10:35 -0700
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-03 11:28 -0700
Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-03 21:26 +0000
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 16:38 -0700
Re: DEC Dan Espen <dan1espen@gmail.com> - 2020-08-03 21:44 -0400
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-03 23:55 -0700
Re: DEC Dan Espen <dan1espen@gmail.com> - 2020-08-04 08:05 -0400
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-04 08:59 -0400
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-04 06:29 -0700
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-04 07:48 -0700
Re: DEC Niklas Karlsson <anksil@yahoo.se> - 2020-08-05 04:13 +0000
Re: DEC robin.vowels@gmail.com - 2020-08-04 22:45 -0700
Re: DEC JimP <chucktheouch@gmail.com> - 2020-08-05 12:33 -0500
Re: DEC "Kerr-Mudd,John" <notsaying@127.0.0.1> - 2020-08-05 19:31 +0000
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-04 22:57 -0700
Re: DEC Bob Eager <news0073@eager.cx> - 2020-08-05 08:13 +0000
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-05 10:58 -0700
Re: DEC drb@ihatespam.msu.edu (Dennis Boone) - 2020-08-05 13:28 -0500
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-06 16:21 -0700
Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-03 18:23 +0000
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-03 11:31 -0700
Re: DEC danny burstein <dannyb@panix.com> - 2020-08-03 18:38 +0000
Re: DEC "m. thompson" <michael.99.thompson@gmail.com> - 2020-08-04 05:38 -0700
Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-04 18:54 +0000
Re: DEC usenet@only.tnx (Questor) - 2020-08-03 00:32 +0000
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-30 13:29 -0700
Re: DEC usenet@only.tnx (Questor) - 2020-07-30 20:27 +0000
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-07-29 14:04 -0700 |
| Subject | Re: ou sont les ordinateurs d'antan, was DEC |
| Message-ID | <1474939415.617667860.324517.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #212446 |
John Levine <johnl@taugh.com> wrote: > In article <5f1f99bf.596447@news.dslextreme.com>, > Questor <usenet@only.tnx> wrote: >>> Many computer companies of the era still have current models, at least in >>> name. Besides IBM z there are systems from Unisys, both former Burroughs >>> and former Sperry. >> >> Where are the mainframes from NCR, Control Data, General Electric, and RCA? >> Where are the minicomputers from Data General, Wang, and Prime? Where are the >> Apollo workstations and the Gateway PCs? > > Didn't have enough locked in banking customers, I guess. Apollo was > selling Unix clone workstatsions and were sold to H-P for over $400M > which was a lot of money at the time. H-P merged them into their real > Unix workstation line. > > NCR is a special case, sold itself to AT&T which did what big telcos > always do with acquisitions, mismanage it until it was worthless and > sell off the corpe for pennies. (Verizon is most of the way throught > that process with AOL and Yahoo.) > >> Where are Wordstar, Wordperfect, >> Lotus 1-2-3, Quattro Pro, Novell Netware, Banyan Vines... > > Wordperfect is still around, owned by Corel, popular among lawyers. I think Lotus is still around. A couple of years ago I downloaded WordPro for windows, after I got rid of my last OS/2 box. > > IBM bought Lotus to get Notes and Domino, which was a good business > for many years. They sold it to Indian firm HCL in 2019. I found 1-2-3 > a few years ago as shovelware on an IBM branded PC. > >> It's not clear to me what Compaq was expecting to get from purchasing DEC. It's >> obvious they weren't going to be making VAXes. The story I heard was that they >> wanted DEC's support network. When in turn HP bought Compaq, it was also >> extremely unlikely they would revive the VAX. Didn't/doesn't HP have their own >> line of minicomputers? Why would they have brought back the VAX? > > HP had PA-RISC which did OK and was supported until 2013. Then there > was Itanium which was an interesting idea that didn't work in > practice. > > DEC was blindsided by the rise of LSI and single-chip computers. Their > failure was pretty spectacular but really only IBM survived the micro > transition in anything like recognizable form. > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Louis Krupp <lkrupp@invalid.pssw.com.invalid> |
|---|---|
| Date | 2020-07-30 03:49 -0600 |
| Message-ID | <ZIwUG.175351$RF4.59316@fx43.iad> |
| In reply to | #212432 |
On 7/27/2020 9:21 PM, Questor wrote: > On Sun, 26 Jul 2020 16:23:41 -0700, Peter Flass <peter_flass@yahoo.com> wrote: >> Ask Barb about Palmer. There does seem to have been haste to break up the >> business and sell it for parts, none of which are still around in >> recognizable form. It's like companies bought by private equity, who have >> no interest at all in the company, or its products or intellectual capital, >> but only in, for example, in the value of the real estate it owns. > > [spits] I have no need to ask Ms. Huizenga for her under-informed and overly > biased opinion about anything. DEC was stumbling years before Palmer took the > reins. It wasn't so obvious at the time, but the seeds of its decline were > already sown. Barb had stories -- that's why it's alt.folklore.computers -- and she was entertaining. Who really cares what she was right or wrong about? Louis
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-07-30 14:41 +0000 |
| Message-ID | <L_AUG.195289$AN2.192375@fx46.iad> |
| In reply to | #212456 |
Louis Krupp <lkrupp@invalid.pssw.com.invalid> writes: >On 7/27/2020 9:21 PM, Questor wrote: >> On Sun, 26 Jul 2020 16:23:41 -0700, Peter Flass <peter_flass@yahoo.com> wrote: > >>> Ask Barb about Palmer. There does seem to have been haste to break up the >>> business and sell it for parts, none of which are still around in >>> recognizable form. It's like companies bought by private equity, who have >>> no interest at all in the company, or its products or intellectual capital, >>> but only in, for example, in the value of the real estate it owns. >> >> [spits] I have no need to ask Ms. Huizenga for her under-informed and overly >> biased opinion about anything. DEC was stumbling years before Palmer took the >> reins. It wasn't so obvious at the time, but the seeds of its decline were >> already sown. > >Barb had stories -- that's why it's alt.folklore.computers -- and she >was entertaining. Who really cares what she was right or wrong about? Historians reading this group?
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-07-30 10:12 -0700 |
| Message-ID | <1922456568.617821872.532416.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #212457 |
Scott Lurndal <scott@slp53.sl.home> wrote: > Louis Krupp <lkrupp@invalid.pssw.com.invalid> writes: >> On 7/27/2020 9:21 PM, Questor wrote: >>> On Sun, 26 Jul 2020 16:23:41 -0700, Peter Flass <peter_flass@yahoo.com> wrote: >> >>>> Ask Barb about Palmer. There does seem to have been haste to break up the >>>> business and sell it for parts, none of which are still around in >>>> recognizable form. It's like companies bought by private equity, who have >>>> no interest at all in the company, or its products or intellectual capital, >>>> but only in, for example, in the value of the real estate it owns. >>> >>> [spits] I have no need to ask Ms. Huizenga for her under-informed and overly >>> biased opinion about anything. DEC was stumbling years before Palmer took the >>> reins. It wasn't so obvious at the time, but the seeds of its decline were >>> already sown. >> >> Barb had stories -- that's why it's alt.folklore.computers -- and she >> was entertaining. Who really cares what she was right or wrong about? > > Historians reading this group? > > It’s the same with any oral history - you always have to account for the bias of the teller, but maybe the bias is the history. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-07-30 18:40 +0000 |
| Message-ID | <AuEUG.195294$AN2.162013@fx46.iad> |
| In reply to | #212458 |
Peter Flass <peter_flass@yahoo.com> writes: >Scott Lurndal <scott@slp53.sl.home> wrote: >> Louis Krupp <lkrupp@invalid.pssw.com.invalid> writes: >>> On 7/27/2020 9:21 PM, Questor wrote: >>>> On Sun, 26 Jul 2020 16:23:41 -0700, Peter Flass <peter_flass@yahoo.com> wrote: >>> >>>>> Ask Barb about Palmer. There does seem to have been haste to break up the >>>>> business and sell it for parts, none of which are still around in >>>>> recognizable form. It's like companies bought by private equity, who have >>>>> no interest at all in the company, or its products or intellectual capital, >>>>> but only in, for example, in the value of the real estate it owns. >>>> >>>> [spits] I have no need to ask Ms. Huizenga for her under-informed and overly >>>> biased opinion about anything. DEC was stumbling years before Palmer took the >>>> reins. It wasn't so obvious at the time, but the seeds of its decline were >>>> already sown. >>> >>> Barb had stories -- that's why it's alt.folklore.computers -- and she >>> was entertaining. Who really cares what she was right or wrong about? >> >> Historians reading this group? >> >> > >It’s the same with any oral history - you always have to account for the >bias of the teller, but maybe the bias is the history. Well, there is two sides to every story. There is considerable bitterness in many of the PDP-10 folks about DECs focus on the VAX; We don't hear as much from the VAX side of the house (or upper management, for that matter).
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-07-30 12:02 -0700 |
| Message-ID | <1836069261.617827817.688943.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #212459 |
Scott Lurndal <scott@slp53.sl.home> wrote: > Peter Flass <peter_flass@yahoo.com> writes: >> Scott Lurndal <scott@slp53.sl.home> wrote: >>> Louis Krupp <lkrupp@invalid.pssw.com.invalid> writes: >>>> On 7/27/2020 9:21 PM, Questor wrote: >>>>> On Sun, 26 Jul 2020 16:23:41 -0700, Peter Flass <peter_flass@yahoo.com> wrote: >>>> >>>>>> Ask Barb about Palmer. There does seem to have been haste to break up the >>>>>> business and sell it for parts, none of which are still around in >>>>>> recognizable form. It's like companies bought by private equity, who have >>>>>> no interest at all in the company, or its products or intellectual capital, >>>>>> but only in, for example, in the value of the real estate it owns. >>>>> >>>>> [spits] I have no need to ask Ms. Huizenga for her under-informed and overly >>>>> biased opinion about anything. DEC was stumbling years before Palmer took the >>>>> reins. It wasn't so obvious at the time, but the seeds of its decline were >>>>> already sown. >>>> >>>> Barb had stories -- that's why it's alt.folklore.computers -- and she >>>> was entertaining. Who really cares what she was right or wrong about? >>> >>> Historians reading this group? >>> >>> >> >> It’s the same with any oral history - you always have to account for the >> bias of the teller, but maybe the bias is the history. > > Well, there is two sides to every story. There is considerable bitterness > in many of the PDP-10 folks about DECs focus on the VAX; We don't hear as much from the > VAX side of the house (or upper management, for that matter). > > The VAX certainly had more growth potential, maybe DEC really couldn’t afford to support both the VAX and the -10, at any level of support, maybe the -10 people screwed up their next-generation design badly enough to make it much too late to market. We’ve heard all those, possibly any or all are correct. For sure most of the VAX people are still around, is there anything like Bell’s article on PDP-11 around for the VAX? It does seem like later management was brought in specifically to sell off the company in pieces. Maybe this was a last resort after everything else was tried and failed. DEC had a lot of good people and a lot of intellectual property that seems to have been liquidated for a lot less than it was worth.That sounds like the work of “vulture capitalists” who just want to make a quick buck and don’t care what happens to the company or its employees. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Terry Kennedy <terry-groups@glaver.org> |
|---|---|
| Date | 2020-07-31 02:38 -0700 |
| Message-ID | <07ce1231-6202-43d2-bfad-d21d3d304fddo@googlegroups.com> |
| In reply to | #212460 |
On Thursday, July 30, 2020 at 3:02:23 PM UTC-4, Peter Flass wrote: > > The VAX certainly had more growth potential, maybe DEC really couldn’t > afford to support both the VAX and the -10, at any level of support, maybe > the -10 people screwed up their next-generation design badly enough to make > it much too late to market. We’ve heard all those, possibly any or all are > correct. For sure most of the VAX people are still around, is there > anything like Bell’s article on PDP-11 around for the VAX? DEC had 2 LSG projects going at the same time and both foundering - the VAX-11/790 (released as the 8600) and the 36-bit Jupiter project. They apparently decided to focus on the 8600, even though it didn't meet its performance goals (but by a smaller amount than Jupiter). By the time the 8600 project got told "ship it now or else" they were very very close to meeting their original performance goal - upgrading an 8600 to an 8650 was a simple 2 board swap. The "mid-life kicker" to upgrade the 8650 (which, remember, was the original performance target for the 8600) would likely have been the 8670 but never got anywhere as a project. But DEC badly misjudged the 36-bit community's response to the Jupiter cancellation - as one university put it, "all new systems will be Unix-based because we will have a much wider choice of vendors to screw us". Meanwhile, LSG continued their tradition of building ever larger systems out of esoteric hardware that were late to market and under-performing, like the VAX 9000. The blame can't be laid solely at LSG's feet - DEC upper management refused to believe that their in-house semiconductor group could fabricate a chip (the NVAX) that outperformed the 9000. And how do you tell your customers that just bought a hugely expensive and large computer that there is another model with better performance, a much smaller form factor, and vastly reduced power consumption? IBM cut the price of the Stretch in half for both existing customers and open orders (taking a loss on each one) and discontinued it after all open orders had been fulfilled. DEC didn't have the resources to take a financial hit like that, and it would still have saddled the 9000 customers with oversized power-hungry boxes. In retrospect, DEC might have been better served by canceling Jupiter but marketing one of the 3rd party compatible 36-bit CPUs as a DEC model. This had been considered (and dismissed) when Jupiter was in the early planning stages. I guess the "we've gone this far, we may as well keep going" (AKA the sunk cost fallacy) convinced them to keep going long after they should have changed strategy.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-07-31 20:21 +0000 |
| Subject | Re: DEC large computers |
| Message-ID | <rg1uh6$1ufa$1@gal.iecc.com> |
| In reply to | #212464 |
In article <07ce1231-6202-43d2-bfad-d21d3d304fddo@googlegroups.com>, Terry Kennedy <terry-groups@glaver.org> wrote: >But DEC badly misjudged the 36-bit community's response to the Jupiter cancellation - as one university put it, "all new systems >will be Unix-based because we will have a much wider choice of vendors to screw us". It was probably still the right choice. By that time it was quite evident that 32 bit byte machines with flat byte adderssing were the future. Much though I loved the PDP-10, the extended addressing was a hack (a very clever hack but still a hack) and if people have to rewrite their programs anyway, they're going to look at other options no matter what. >In retrospect, DEC might have been better served by canceling Jupiter but marketing one of the 3rd party compatible 36-bit CPUs >as a DEC model. This had been considered (and dismissed) when Jupiter was in the early planning stages. I guess the "we've gone >this far, we may as well keep going" (AKA the sunk cost fallacy) convinced them to keep going long after they should have changed >strategy. Agreed, partly that, partly NIH. It would have been essentially zero risk for them and likely would have delayed some defections. > IBM cut the price of the Stretch in half for both existing customers >and open orders (taking a loss on each one) and discontinued it after all open orders had been fulfilled. They did it again for the 360/91, shipped the committed orders at a loss and discontinued it. They made one more try with the 195, a 91 reimplemented in faster logic with a cache adapted from the 360/85, but it was still slower than the CDC 7600 and IBM got out of the supercomputing business for good, or at least until the era when supercomputers were reinvented as a zillion normal computers connected together. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2020-07-31 23:23 +0000 |
| Subject | Re: DEC large computers |
| Message-ID | <rg2966$n19$1@newsreader4.netcologne.de> |
| In reply to | #212465 |
John Levine <johnl@taugh.com> schrieb: > They did it again for the 360/91, shipped the committed orders at a > loss and discontinued it. They made one more try with the 195, a 91 > reimplemented in faster logic with a cache adapted from the 360/85, > but it was still slower than the CDC 7600 and IBM got out of the > supercomputing business for good, or at least until the era when > supercomputers were reinvented as a zillion normal computers connected > together. They did have the 3090 vector facility feature, we had one at our university. I remember it didn't hold a candle to the Siemens/Fujutsu VP that was also there (and which I used). Personally, I never used the 3090 VF. Does anybody have comparison data for floating point performance of these machines?
[toc] | [prev] | [next] | [standalone]
| From | J. Clarke <jclarke.873638@gmail.com> |
|---|---|
| Date | 2020-07-31 21:13 -0400 |
| Subject | Re: DEC large computers |
| Message-ID | <7dg9if5lmh2jat6kmn00320ir3r5njrmrt@4ax.com> |
| In reply to | #212466 |
On Fri, 31 Jul 2020 23:23:50 -0000 (UTC), Thomas Koenig <tkoenig@netcologne.de> wrote: >John Levine <johnl@taugh.com> schrieb: > >> They did it again for the 360/91, shipped the committed orders at a >> loss and discontinued it. They made one more try with the 195, a 91 >> reimplemented in faster logic with a cache adapted from the 360/85, >> but it was still slower than the CDC 7600 and IBM got out of the >> supercomputing business for good, or at least until the era when >> supercomputers were reinvented as a zillion normal computers connected >> together. > >They did have the 3090 vector facility feature, we had one at >our university. > >I remember it didn't hold a candle to the Siemens/Fujutsu VP >that was also there (and which I used). Personally, I never >used the 3090 VF. > >Does anybody have comparison data for floating point performance >of these machines? http://www.roylongbottom.org.uk/whetstone.htm#anchorIBM
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2020-08-01 10:39 +0000 |
| Subject | Re: DEC large computers |
| Message-ID | <rg3gp6$js9$1@newsreader4.netcologne.de> |
| In reply to | #212467 |
J Clarke <jclarke.873638@gmail.com> schrieb: > On Fri, 31 Jul 2020 23:23:50 -0000 (UTC), Thomas Koenig ><tkoenig@netcologne.de> wrote: > >>John Levine <johnl@taugh.com> schrieb: >> >>> They did it again for the 360/91, shipped the committed orders at a >>> loss and discontinued it. They made one more try with the 195, a 91 >>> reimplemented in faster logic with a cache adapted from the 360/85, >>> but it was still slower than the CDC 7600 and IBM got out of the >>> supercomputing business for good, or at least until the era when >>> supercomputers were reinvented as a zillion normal computers connected >>> together. >> >>They did have the 3090 vector facility feature, we had one at >>our university. >> >>I remember it didn't hold a candle to the Siemens/Fujutsu VP >>that was also there (and which I used). Personally, I never >>used the 3090 VF. >> >>Does anybody have comparison data for floating point performance >>of these machines? > > http://www.roylongbottom.org.uk/whetstone.htm#anchorIBM So, that gives the performance of an IBM 3090 with VE as 13.8 MFlops. http://museum.ipsj.or.jp/en/computer/super/0005.html gives the maximum for the VP 400 (which I worked on) as 1142 MFlops, which I can safely assume was single precision, so around half that for maximum MFLOPS for double. This is apples to oranges, of course (theoretical speed vs. actual benchmark) but still shows that my memory was not far off - the VP was the _much_ faster machine, and IBM didn't even come close in performance to what the Japanese were doing at the time.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-08-01 02:21 +0000 |
| Subject | Re: vectors, was DEC large computers |
| Message-ID | <rg2jih$1aom$1@gal.iecc.com> |
| In reply to | #212466 |
In article <rg2966$n19$1@newsreader4.netcologne.de>, Thomas Koenig <tkoenig@netcologne.de> wrote: >> but it was still slower than the CDC 7600 and IBM got out of the >> supercomputing business for good, or at least until the era when >> supercomputers were reinvented as a zillion normal computers connected >> together. > >They did have the 3090 vector facility feature, we had one at >our university. The 390 had a similar vector facility and zSeries has a much fancier one which can handle vectors of ints, and the various float formats. I don't understand the point, since nobody buys an IBM mainframe as a compute engine but someone must want it. I presume it's mostly microcode so it's not very expensive to provide. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0073@eager.cx> |
|---|---|
| Date | 2020-08-01 11:14 +0000 |
| Subject | Re: vectors, was DEC large computers |
| Message-ID | <hol154FmsnaU19@mid.individual.net> |
| In reply to | #212470 |
On Sat, 01 Aug 2020 02:21:05 +0000, John Levine wrote: > In article <rg2966$n19$1@newsreader4.netcologne.de>, > Thomas Koenig <tkoenig@netcologne.de> wrote: >>> but it was still slower than the CDC 7600 and IBM got out of the >>> supercomputing business for good, or at least until the era when >>> supercomputers were reinvented as a zillion normal computers connected >>> together. >> >>They did have the 3090 vector facility feature, we had one at our >>university. > > The 390 had a similar vector facility and zSeries has a much fancier one > which can handle vectors of ints, and the various float formats. I don't > understand the point, since nobody buys an IBM mainframe as a compute > engine but someone must want it. > > I presume it's mostly microcode so it's not very expensive to provide. Fairly early on, the UK had this: https://en.wikipedia.org/wiki/ICL_Distributed_Array_Processor Not many were sold, but I was peripherally involved in a third party operating system that supported it. -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | robin.vowels@gmail.com |
|---|---|
| Date | 2020-07-31 20:30 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <0ffcf911-d675-4b8d-9d7b-2723e6122bdbo@googlegroups.com> |
| In reply to | #212465 |
On Saturday, August 1, 2020 at 6:22:00 AM UTC+10, John Levine wrote: > In article <0.....@googlegroups.com>, > Terry Kennedy <t......@glaver.org> wrote: > >But DEC badly misjudged the 36-bit community's response to the Jupiter cancellation - as one university put it, "all new systems > >will be Unix-based because we will have a much wider choice of vendors to screw us". > > It was probably still the right choice. By that time it was quite > evident that 32 bit byte machines with flat byte adderssing were the > future. Much though I loved the PDP-10, the extended addressing was a > hack (a very clever hack but still a hack) and if people have to > rewrite their programs anyway, they're going to look at other options > no matter what. > > >In retrospect, DEC might have been better served by canceling Jupiter but marketing one of the 3rd party compatible 36-bit CPUs > >as a DEC model. This had been considered (and dismissed) when Jupiter was in the early planning stages. I guess the "we've gone > >this far, we may as well keep going" (AKA the sunk cost fallacy) convinced them to keep going long after they should have changed > >strategy. > > Agreed, partly that, partly NIH. It would have been essentially zero > risk for them and likely would have delayed some defections. > > > IBM cut the price of the Stretch in half for both existing customers > >and open orders (taking a loss on each one) and discontinued it after all open orders had been fulfilled. > > They did it again for the 360/91, shipped the committed orders at a > loss and discontinued it. They made one more try with the 195, a 91 > reimplemented in faster logic with a cache adapted from the 360/85, > but it was still slower than the CDC 7600 and IBM got out of the > supercomputing business for good, or at least until the era when > supercomputers were reinvented as a zillion normal computers connected > together. The problems with the 7600 were lack of software, and in the fact that it did not have character-handling instructions. Plus the silly integer multiplication instruction, plus the fact that CDC had 65 characters stored in 6-bits. So, if you wanted wrong results without warning, go for the 7600. The problem with the S/360 was the pedestrian instruction set. The integer instructions lacked an instruction to increment a memory word; an instruction to generate a constant (other than LA, that did not set the condition code, and in any case, it handled only positive constants); an instruction to convert a condition code to logic 0 or 1; an MH instruction that did not set overflow; no DH instruction; instructions in the integer and floating-point repertoire to reference memory did not shift the index by 1, 2, 3, or 4 places. The latter alone would have at once decreased the size of the object code and speeded up execution.
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2020-08-01 00:00 -0400 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <rg2pdr$744$1@dont-email.me> |
| In reply to | #212471 |
robin.vowels@gmail.com writes: > On Saturday, August 1, 2020 at 6:22:00 AM UTC+10, John Levine wrote: >> In article <0.....@googlegroups.com>, >> Terry Kennedy <t......@glaver.org> wrote: >> >But DEC badly misjudged the 36-bit community's response to the >> >Jupiter cancellation - as one university put it, "all new systems >> >will be Unix-based because we will have a much wider choice of >> >vendors to screw us". >> >> It was probably still the right choice. By that time it was quite >> evident that 32 bit byte machines with flat byte adderssing were the >> future. Much though I loved the PDP-10, the extended addressing was a >> hack (a very clever hack but still a hack) and if people have to >> rewrite their programs anyway, they're going to look at other options >> no matter what. >> >> >In retrospect, DEC might have been better served by canceling >> >Jupiter but marketing one of the 3rd party compatible 36-bit CPUs as >> >a DEC model. This had been considered (and dismissed) when Jupiter >> >was in the early planning stages. I guess the "we've gone this far, >> >we may as well keep going" (AKA the sunk cost fallacy) convinced >> >them to keep going long after they should have changed strategy. >> >> Agreed, partly that, partly NIH. It would have been essentially zero >> risk for them and likely would have delayed some defections. >> >> > IBM cut the price of the Stretch in half for both existing >> >customers and open orders (taking a loss on each one) and >> >discontinued it after all open orders had been fulfilled. >> >> They did it again for the 360/91, shipped the committed orders at a >> loss and discontinued it. They made one more try with the 195, a 91 >> reimplemented in faster logic with a cache adapted from the 360/85, >> but it was still slower than the CDC 7600 and IBM got out of the >> supercomputing business for good, or at least until the era when >> supercomputers were reinvented as a zillion normal computers >> connected together. > > The problems with the 7600 were lack of software, and in the fact that > it did not have character-handling instructions. Plus the silly > integer multiplication instruction, plus the fact that CDC had 65 > characters stored in 6-bits. > > So, if you wanted wrong results without warning, go for the 7600. > > The problem with the S/360 was the pedestrian instruction set. The > integer instructions lacked an instruction to increment a memory word; > an instruction to generate a constant (other than LA, that did not set > the condition code, and in any case, it handled only positive > constants); an instruction to convert a condition code to logic 0 or > 1; an MH instruction that did not set overflow; no DH instruction; > instructions in the integer and floating-point repertoire to reference > memory did not shift the index by 1, 2, 3, or 4 places. The latter > alone would have at once decreased the size of the object code and > speeded up execution. That's a pretty good list. I can't argue with your points. I hated; L R1,COUNT LA R1,1(R1) ST R1,COUNT Unless there was a good reason to be working with binary: AP COUNT,=P'1' makes more sense. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | robin.vowels@gmail.com |
|---|---|
| Date | 2020-08-01 02:20 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <922c973a-7fcb-4c6e-9691-7996ae938db5o@googlegroups.com> |
| In reply to | #212472 |
On Saturday, August 1, 2020 at 2:01:01 PM UTC+10, Dan Espen wrote: > r......@gmail.com writes: > > > On Saturday, August 1, 2020 at 6:22:00 AM UTC+10, John Levine wrote: > >> In article <0.....@googlegroups.com>, > >> Terry Kennedy <t......@glaver.org> wrote: > >> >But DEC badly misjudged the 36-bit community's response to the > >> >Jupiter cancellation - as one university put it, "all new systems > >> >will be Unix-based because we will have a much wider choice of > >> >vendors to screw us". > >> > >> It was probably still the right choice. By that time it was quite > >> evident that 32 bit byte machines with flat byte adderssing were the > >> future. Much though I loved the PDP-10, the extended addressing was a > >> hack (a very clever hack but still a hack) and if people have to > >> rewrite their programs anyway, they're going to look at other options > >> no matter what. > >> > >> >In retrospect, DEC might have been better served by canceling > >> >Jupiter but marketing one of the 3rd party compatible 36-bit CPUs as > >> >a DEC model. This had been considered (and dismissed) when Jupiter > >> >was in the early planning stages. I guess the "we've gone this far, > >> >we may as well keep going" (AKA the sunk cost fallacy) convinced > >> >them to keep going long after they should have changed strategy. > >> > >> Agreed, partly that, partly NIH. It would have been essentially zero > >> risk for them and likely would have delayed some defections. > >> > >> > IBM cut the price of the Stretch in half for both existing > >> >customers and open orders (taking a loss on each one) and > >> >discontinued it after all open orders had been fulfilled. > >> > >> They did it again for the 360/91, shipped the committed orders at a > >> loss and discontinued it. They made one more try with the 195, a 91 > >> reimplemented in faster logic with a cache adapted from the 360/85, > >> but it was still slower than the CDC 7600 and IBM got out of the > >> supercomputing business for good, or at least until the era when > >> supercomputers were reinvented as a zillion normal computers > >> connected together. > > > > The problems with the 7600 were lack of software, and in the fact that > > it did not have character-handling instructions. Plus the silly > > integer multiplication instruction, plus the fact that CDC had 65 > > characters stored in 6-bits. > > > > So, if you wanted wrong results without warning, go for the 7600. > > > > The problem with the S/360 was the pedestrian instruction set. The > > integer instructions lacked an instruction to increment a memory word; > > an instruction to generate a constant (other than LA, that did not set > > the condition code, and in any case, it handled only positive > > constants); an instruction to convert a condition code to logic 0 or > > 1; an MH instruction that did not set overflow; no DH instruction; > > instructions in the integer and floating-point repertoire to reference > > memory did not shift the index by 1, 2, 3, or 4 places. The latter > > alone would have at once decreased the size of the object code and > > speeded up execution. > > That's a pretty good list. I can't argue with your points. > > I hated; > > L R1,COUNT LA R1,1(R1) ST R1,COUNT Yes, but better is/was LA R1,1(0,0) A R1,COUNT ST R1,COUNT because the condition code is set properly. > Unless there was a good reason to be working with binary: > > AP COUNT,=P'1' > > makes more sense. It does, in decimal, but not appropriate when indexing.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-08-01 07:00 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <317348782.617983032.989774.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #212476 |
<robin.vowels@gmail.com> wrote: > On Saturday, August 1, 2020 at 2:01:01 PM UTC+10, Dan Espen wrote: >> r......@gmail.com writes: >> >>> On Saturday, August 1, 2020 at 6:22:00 AM UTC+10, John Levine wrote: >>>> In article <0.....@googlegroups.com>, >>>> Terry Kennedy <t......@glaver.org> wrote: >>>>> But DEC badly misjudged the 36-bit community's response to the >>>>> Jupiter cancellation - as one university put it, "all new systems >>>>> will be Unix-based because we will have a much wider choice of >>>>> vendors to screw us". >>>> >>>> It was probably still the right choice. By that time it was quite >>>> evident that 32 bit byte machines with flat byte adderssing were the >>>> future. Much though I loved the PDP-10, the extended addressing was a >>>> hack (a very clever hack but still a hack) and if people have to >>>> rewrite their programs anyway, they're going to look at other options >>>> no matter what. >>>> >>>>> In retrospect, DEC might have been better served by canceling >>>>> Jupiter but marketing one of the 3rd party compatible 36-bit CPUs as >>>>> a DEC model. This had been considered (and dismissed) when Jupiter >>>>> was in the early planning stages. I guess the "we've gone this far, >>>>> we may as well keep going" (AKA the sunk cost fallacy) convinced >>>>> them to keep going long after they should have changed strategy. >>>> >>>> Agreed, partly that, partly NIH. It would have been essentially zero >>>> risk for them and likely would have delayed some defections. >>>> >>>>> IBM cut the price of the Stretch in half for both existing >>>>> customers and open orders (taking a loss on each one) and >>>>> discontinued it after all open orders had been fulfilled. >>>> >>>> They did it again for the 360/91, shipped the committed orders at a >>>> loss and discontinued it. They made one more try with the 195, a 91 >>>> reimplemented in faster logic with a cache adapted from the 360/85, >>>> but it was still slower than the CDC 7600 and IBM got out of the >>>> supercomputing business for good, or at least until the era when >>>> supercomputers were reinvented as a zillion normal computers >>>> connected together. >>> >>> The problems with the 7600 were lack of software, and in the fact that >>> it did not have character-handling instructions. Plus the silly >>> integer multiplication instruction, plus the fact that CDC had 65 >>> characters stored in 6-bits. >>> >>> So, if you wanted wrong results without warning, go for the 7600. >>> >>> The problem with the S/360 was the pedestrian instruction set. The >>> integer instructions lacked an instruction to increment a memory word; >>> an instruction to generate a constant (other than LA, that did not set >>> the condition code, and in any case, it handled only positive >>> constants); an instruction to convert a condition code to logic 0 or >>> 1; an MH instruction that did not set overflow; no DH instruction; >>> instructions in the integer and floating-point repertoire to reference >>> memory did not shift the index by 1, 2, 3, or 4 places. The latter >>> alone would have at once decreased the size of the object code and >>> speeded up execution. >> >> That's a pretty good list. I can't argue with your points. >> >> I hated; >> >> L R1,COUNT LA R1,1(R1) ST R1,COUNT > > Yes, but better is/was > LA R1,1(0,0) A R1,COUNT ST R1,COUNT > because the condition code is set properly. > >> Unless there was a good reason to be working with binary: >> >> AP COUNT,=P'1' >> >> makes more sense. > > It does, in decimal, but not appropriate when indexing. > I don’t think I found much need to increment a word in memory. For indexing the value would be kept in a register, or would have to be loaded before use anyhow. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | robin.vowels@gmail.com |
|---|---|
| Date | 2020-08-01 08:18 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <1e4a1301-dad0-445b-bc20-6c084cbc59c2o@googlegroups.com> |
| In reply to | #212483 |
On Sunday, August 2, 2020 at 12:00:54 AM UTC+10, Peter Flass wrote: > <r......@gmail.com> wrote: > > On Saturday, August 1, 2020 at 2:01:01 PM UTC+10, Dan Espen wrote: > >> r......@gmail.com writes: > >> > >>> On Saturday, August 1, 2020 at 6:22:00 AM UTC+10, John Levine wrote: > >>>> In article <0.....@googlegroups.com>, > >>>> Terry Kennedy <t......@glaver.org> wrote: > >>>>> But DEC badly misjudged the 36-bit community's response to the > >>>>> Jupiter cancellation - as one university put it, "all new systems > >>>>> will be Unix-based because we will have a much wider choice of > >>>>> vendors to screw us". > >>>> > >>>> It was probably still the right choice. By that time it was quite > >>>> evident that 32 bit byte machines with flat byte adderssing were the > >>>> future. Much though I loved the PDP-10, the extended addressing was a > >>>> hack (a very clever hack but still a hack) and if people have to > >>>> rewrite their programs anyway, they're going to look at other options > >>>> no matter what. > >>>> > >>>>> In retrospect, DEC might have been better served by canceling > >>>>> Jupiter but marketing one of the 3rd party compatible 36-bit CPUs as > >>>>> a DEC model. This had been considered (and dismissed) when Jupiter > >>>>> was in the early planning stages. I guess the "we've gone this far, > >>>>> we may as well keep going" (AKA the sunk cost fallacy) convinced > >>>>> them to keep going long after they should have changed strategy. > >>>> > >>>> Agreed, partly that, partly NIH. It would have been essentially zero > >>>> risk for them and likely would have delayed some defections. > >>>> > >>>>> IBM cut the price of the Stretch in half for both existing > >>>>> customers and open orders (taking a loss on each one) and > >>>>> discontinued it after all open orders had been fulfilled. > >>>> > >>>> They did it again for the 360/91, shipped the committed orders at a > >>>> loss and discontinued it. They made one more try with the 195, a 91 > >>>> reimplemented in faster logic with a cache adapted from the 360/85, > >>>> but it was still slower than the CDC 7600 and IBM got out of the > >>>> supercomputing business for good, or at least until the era when > >>>> supercomputers were reinvented as a zillion normal computers > >>>> connected together. > >>> > >>> The problems with the 7600 were lack of software, and in the fact that > >>> it did not have character-handling instructions. Plus the silly > >>> integer multiplication instruction, plus the fact that CDC had 65 > >>> characters stored in 6-bits. > >>> > >>> So, if you wanted wrong results without warning, go for the 7600. > >>> > >>> The problem with the S/360 was the pedestrian instruction set. The > >>> integer instructions lacked an instruction to increment a memory word; > >>> an instruction to generate a constant (other than LA, that did not set > >>> the condition code, and in any case, it handled only positive > >>> constants); an instruction to convert a condition code to logic 0 or > >>> 1; an MH instruction that did not set overflow; no DH instruction; > >>> instructions in the integer and floating-point repertoire to reference > >>> memory did not shift the index by 1, 2, 3, or 4 places. The latter > >>> alone would have at once decreased the size of the object code and > >>> speeded up execution. > >> > >> That's a pretty good list. I can't argue with your points. > >> > >> I hated; > >> > >> L R1,COUNT LA R1,1(R1) ST R1,COUNT > > > > Yes, but better is/was > > LA R1,1(0,0) A R1,COUNT ST R1,COUNT > > because the condition code is set properly. > > > >> Unless there was a good reason to be working with binary: > >> > >> AP COUNT,=P'1' > >> > >> makes more sense. > > > > It does, in decimal, but not appropriate when indexing. > I don’t think I found much need to increment a word in memory. For indexing > the value would be kept in a register, or would have to be loaded before > use anyhow. There is a limited number of registers. When tallying a number of variables (including separate elements of an array), incrementing a memory word would be very handy. Even if, for normal indexing, a variable need to be loaded for that purpose, it would still be more economical to increment memory, then load it to register for indexing (2 instructions instead of 3).
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2020-08-01 11:52 -0400 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <rg434c$pa2$1@dont-email.me> |
| In reply to | #212485 |
robin.vowels@gmail.com writes: > On Sunday, August 2, 2020 at 12:00:54 AM UTC+10, Peter Flass wrote: >> <r......@gmail.com> wrote: >> > On Saturday, August 1, 2020 at 2:01:01 PM UTC+10, Dan Espen wrote: >> >> r......@gmail.com writes: >> >> >> >>> On Saturday, August 1, 2020 at 6:22:00 AM UTC+10, John Levine wrote: >> >>>> In article <0.....@googlegroups.com>, >> >>>> Terry Kennedy <t......@glaver.org> wrote: >> >>>>> But DEC badly misjudged the 36-bit community's response to the >> >>>>> Jupiter cancellation - as one university put it, "all new >> >>>>> systems will be Unix-based because we will have a much wider >> >>>>> choice of vendors to screw us". >> >>>> >> >>>> It was probably still the right choice. By that time it was >> >>>> quite evident that 32 bit byte machines with flat byte >> >>>> adderssing were the future. Much though I loved the PDP-10, the >> >>>> extended addressing was a hack (a very clever hack but still a >> >>>> hack) and if people have to rewrite their programs anyway, >> >>>> they're going to look at other options no matter what. >> >>>> >> >>>>> In retrospect, DEC might have been better served by canceling >> >>>>> Jupiter but marketing one of the 3rd party compatible 36-bit >> >>>>> CPUs as a DEC model. This had been considered (and dismissed) >> >>>>> when Jupiter was in the early planning stages. I guess the >> >>>>> "we've gone this far, we may as well keep going" (AKA the sunk >> >>>>> cost fallacy) convinced them to keep going long after they >> >>>>> should have changed strategy. >> >>>> >> >>>> Agreed, partly that, partly NIH. It would have been essentially >> >>>> zero risk for them and likely would have delayed some >> >>>> defections. >> >>>> >> >>>>> IBM cut the price of the Stretch in half for both existing >> >>>>> customers and open orders (taking a loss on each one) and >> >>>>> discontinued it after all open orders had been fulfilled. >> >>>> >> >>>> They did it again for the 360/91, shipped the committed orders >> >>>> at a loss and discontinued it. They made one more try with the >> >>>> 195, a 91 reimplemented in faster logic with a cache adapted >> >>>> from the 360/85, but it was still slower than the CDC 7600 and >> >>>> IBM got out of the supercomputing business for good, or at least >> >>>> until the era when supercomputers were reinvented as a zillion >> >>>> normal computers connected together. >> >>> >> >>> The problems with the 7600 were lack of software, and in the fact >> >>> that it did not have character-handling instructions. Plus the >> >>> silly integer multiplication instruction, plus the fact that CDC >> >>> had 65 characters stored in 6-bits. >> >>> >> >>> So, if you wanted wrong results without warning, go for the 7600. >> >>> >> >>> The problem with the S/360 was the pedestrian instruction >> >>> set. The integer instructions lacked an instruction to increment >> >>> a memory word; an instruction to generate a constant (other than >> >>> LA, that did not set the condition code, and in any case, it >> >>> handled only positive constants); an instruction to convert a >> >>> condition code to logic 0 or 1; an MH instruction that did not >> >>> set overflow; no DH instruction; instructions in the integer and >> >>> floating-point repertoire to reference memory did not shift the >> >>> index by 1, 2, 3, or 4 places. The latter alone would have at >> >>> once decreased the size of the object code and speeded up >> >>> execution. >> >> >> >> That's a pretty good list. I can't argue with your points. >> >> >> >> I hated; >> >> >> >> L R1,COUNT LA R1,1(R1) ST R1,COUNT >> > >> > Yes, but better is/was LA R1,1(0,0) A R1,COUNT ST R1,COUNT because >> > the condition code is set properly. >> > >> >> Unless there was a good reason to be working with binary: >> >> >> >> AP COUNT,=P'1' >> >> >> >> makes more sense. >> > >> > It does, in decimal, but not appropriate when indexing. > >> I don’t think I found much need to increment a word in memory. For >> indexing the value would be kept in a register, or would have to be >> loaded before use anyhow. > > There is a limited number of registers. > > When tallying a number of variables (including separate elements of an > array), incrementing a memory word would be very handy. > > Even if, for normal indexing, a variable need to be loaded for that > purpose, it would still be more economical to increment memory, then > load it to register for indexing (2 instructions instead of 3). Seems to me, I've seen more than 1 page counter declared as binary. Because every one knows binary arithmetic is more efficient. :) I think with today's processors, that load, add, store sequence runs pretty fast. Maybe as fast as one instruction. Not to say that your point isn't valid. When we got one of the later Z machines, our Strobe performance monitor became mostly useless. It would show CPU being consumed in code that couldn't possibly be using significant CPU. IBM came in and explained with instruction look ahead and simultaneous execution it was no longer possible to isolate CPU use to instructions or even blocks of code. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2020-08-02 21:58 +0000 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <rg7cug023qp@news2.newsguy.com> |
| In reply to | #212486 |
On 2020-08-01, Dan Espen <dan1espen@gmail.com> wrote: > robin.vowels@gmail.com writes: > >> On Sunday, August 2, 2020 at 12:00:54 AM UTC+10, Peter Flass wrote: >> >>> I don’t think I found much need to increment a word in memory. For >>> indexing the value would be kept in a register, or would have to be >>> loaded before use anyhow. >> >> There is a limited number of registers. >> >> When tallying a number of variables (including separate elements of an >> array), incrementing a memory word would be very handy. >> >> Even if, for normal indexing, a variable need to be loaded for that >> purpose, it would still be more economical to increment memory, then >> load it to register for indexing (2 instructions instead of 3). Still, there are tricks for conserving registers. You can get away with using registers 15, 0, and 1 in a BXLE loop, for instance. > Seems to me, I've seen more than 1 page counter declared as binary. > Because every one knows binary arithmetic is more efficient. > > :) As opposed to the CS weenie who wrote a COBOL program full of subscript handling, and declared all the subscripts as COMP-3. -- /~\ Charlie Gibbs | Microsoft is a dictatorship. \ / <cgibbs@kltpzyxm.invalid> | Apple is a cult. X I'm really at ac.dekanfrus | Linux is anarchy. / \ if you read it the right way. | Pick your poison.
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web