Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #152214 > unrolled thread
| Started by | RS Wood <rsw@therandymon.com> |
|---|---|
| First post | 2015-10-02 23:17 +0300 |
| Last post | 2015-10-05 16:46 -0500 |
| Articles | 20 on this page of 230 — 34 participants |
Back to article view | Back to alt.folklore.computers
the legacy of Seymour Cray RS Wood <rsw@therandymon.com> - 2015-10-02 23:17 +0300
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-02 13:41 -0700
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-02 17:19 -0700
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-05 16:30 -0500
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-05 17:24 -0700
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-06 16:16 -0500
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-06 12:07 -0700
Re: the legacy of Seymour Cray Al Kossow <aek@bitsavers.org> - 2015-10-06 12:12 -0700
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-06 17:18 -0700
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-07 14:23 -0500
Re: the legacy of Seymour Cray Rich <rich@example.invalid> - 2015-10-02 20:52 +0000
Re: the legacy of Seymour Cray "Joe Morris" <j.c.morris@verizon.net> - 2015-10-02 19:04 -0400
Re: the legacy of Seymour Cray philo <philo@privacy.net> - 2015-10-03 05:37 -0500
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-03 08:47 -0700
Re: the legacy of Seymour Cray wje@acm.org (Bill Evans) - 2015-10-03 08:59 -0700
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-03 09:58 -0700
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-03 12:22 -0700
Re: the legacy of Seymour Cray Al Kossow <aek@bitsavers.org> - 2015-10-02 15:36 -0700
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-05 16:16 -0500
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-02 17:47 -0700
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-03 04:55 -0700
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-03 12:39 -0700
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-03 12:56 -0700
Re: the legacy of Seymour Cray John Levine <johnl@iecc.com> - 2015-10-03 20:29 +0000
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-03 20:43 -0700
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-03 13:51 -0700
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-05 12:10 -0500
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-05 16:38 -0500
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-05 16:58 -0500
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-05 17:18 -0500
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-06 17:00 +0000
Re: fare collection hancock4@bbs.cpcn.com - 2015-10-06 11:58 -0700
Re: fare collection Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-07 01:17 +0000
Re: the legacy of Seymour Cray The New Other Guy <Newsgnus@gmail.com> - 2015-10-11 22:44 -0700
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-05 17:31 -0700
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-05 23:26 -0500
Re: the legacy of Seymour Cray The New Other Guy <Newsgnus@gmail.com> - 2015-10-06 00:54 -0700
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-06 07:44 -0700
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-06 14:59 -0500
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-06 14:47 -0700
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-06 18:03 -0500
Re: the legacy of Seymour Cray terry+googleblog@tmk.com - 2015-10-06 16:22 -0700
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-06 23:22 -0500
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-07 18:33 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-07 07:54 -0700
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-07 14:33 -0500
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-07 14:08 -0700
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-07 16:52 -0500
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-07 19:30 -0400
Re: the legacy of Seymour Cray Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-07 18:58 -0600
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-07 19:25 -0700
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-08 12:20 -0400
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-07 20:27 -0700
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-08 12:20 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-08 09:47 -0700
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-08 14:10 -0400
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-08 14:25 -0700
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-08 20:25 -0400
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-09 16:27 -0500
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-09 17:47 -0700
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-11 13:30 -0500
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-09 18:40 -0700
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-10 16:12 +0000
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-11 13:27 -0500
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-11 15:01 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-11 18:45 -0700
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-11 22:28 -0400
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-12 13:44 -0500
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-12 09:55 -0400
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-12 08:36 -0700
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-12 16:41 +0000
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-08 14:52 -0500
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-08 09:00 -0400
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-08 18:29 +0000
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-08 15:06 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-08 12:17 -0700
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-08 16:33 -0400
Re: the legacy of Seymour Cray "Joe Morris" <j.c.morris@verizon.net> - 2015-10-09 19:40 -0400
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-10 16:12 +0000
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-08 14:35 -0700
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-09 00:07 -0700
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-09 00:10 -0700
Re: the legacy of Seymour Cray "Joe Morris" <j.c.morris@verizon.net> - 2015-10-09 20:01 -0400
Re: the legacy of Seymour Cray "Joe Morris" <j.c.morris@verizon.net> - 2015-10-09 19:38 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-09 18:59 -0700
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-10 09:00 -0400
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-10 16:12 +0000
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-11 08:16 -0400
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-11 14:15 +0000
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-12 15:39 -0500
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-12 19:41 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-13 07:43 -0700
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-13 12:18 -0700
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-11 16:37 -0700
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-12 16:41 +0000
Re: the legacy of Seymour Cray Gene Wirchenko <genew@telus.net> - 2015-10-12 16:21 -0700
Re: the legacy of Seymour Cray "Joe Morris" <j.c.morris@verizon.net> - 2015-10-12 19:54 -0400
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-13 18:23 +0000
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-13 12:28 -0700
Re: the legacy of Seymour Cray Gene Wirchenko <genew@telus.net> - 2015-10-13 21:08 -0700
Re: the legacy of Seymour Cray Walter Banks <walter@bytecraft.com> - 2015-10-11 08:35 -0400
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-11 08:40 -0400
Re: the legacy of Seymour Cray Walter Banks <walter@bytecraft.com> - 2015-10-11 12:13 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-10 19:32 -0700
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-10 22:51 -0400
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-11 13:37 -0500
Re: the legacy of Seymour Cray "Joe Morris" <j.c.morris@verizon.net> - 2015-10-10 12:07 -0400
Re: the legacy of Seymour Cray scott@slp53.sl.home (Scott Lurndal) - 2015-10-09 13:23 +0000
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-08 14:37 -0500
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-08 13:16 -0700
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-08 13:32 -0700
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-08 20:11 -0400
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-09 13:57 -0500
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-09 21:46 -0500
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-09 16:47 +0000
Re: the legacy of Seymour Cray scott@slp53.sl.home (Scott Lurndal) - 2015-10-09 18:18 +0000
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-07 19:39 -0700
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-08 05:14 +0000
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-08 07:47 -0700
Re: the legacy of Seymour Cray Stephen Wolstenholme <steve@easynn.com> - 2015-10-08 16:03 +0100
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-08 15:00 -0500
Re: the legacy of Seymour Cray Morten Reistad <first@last.name.invalid> - 2015-10-08 08:39 +0200
Re: the legacy of Seymour Cray Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-08 08:57 -0600
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-08 14:57 -0500
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-08 13:30 -0700
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-09 23:36 -0500
Re: IBM disks, was the legacy of Seymour Cray John Levine <johnl@iecc.com> - 2015-10-10 05:18 +0000
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-10 09:16 -0400
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-10 11:20 -0400
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-11 13:42 -0500
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-10 18:08 -0700
Re: the legacy of Seymour Cray Alan Bowler <atbowler@thinkage.ca> - 2016-01-08 13:12 -0500
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2016-01-08 10:34 -0800
Re: the legacy of Seymour Cray Alan Bowler <atbowler@thinkage.ca> - 2016-01-13 15:39 -0500
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2016-01-14 08:03 -0500
Re: the legacy of Seymour Cray Alan Bowler <atbowler@thinkage.ca> - 2016-01-14 13:10 -0500
Re: the legacy of Seymour Cray Rich Alderson <news@alderson.users.panix.com> - 2016-01-14 14:49 -0500
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2016-01-14 15:00 -0500
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2016-01-14 14:28 -0600
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2016-01-14 19:57 -0500
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2016-01-14 22:24 -0600
Re: the legacy of Seymour Cray jmfbahciv <See.above@aol.com> - 2016-01-15 14:51 +0000
Re: the legacy of Seymour Cray Morten Reistad <first@last.name.invalid> - 2016-01-15 16:40 +0100
Re: the legacy of Seymour Cray Rich Alderson <news@alderson.users.panix.com> - 2016-01-15 14:18 -0500
Re: the legacy of Seymour Cray timcaffrey420@gmail.com - 2016-01-15 15:57 -0800
Re: the legacy of Seymour Cray Bob Eager <news0006@eager.cx> - 2016-01-15 22:22 +0000
Re: the legacy of Seymour Cray scott@slp53.sl.home (Scott Lurndal) - 2016-01-18 15:24 +0000
Re: the legacy of Seymour Cray Bob Eager <news0006@eager.cx> - 2016-01-18 16:35 +0000
Re: the legacy of Seymour Cray scott@slp53.sl.home (Scott Lurndal) - 2016-01-18 17:46 +0000
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2016-01-14 11:13 -0800
Re: the legacy of Seymour Cray scott@slp53.sl.home (Scott Lurndal) - 2016-01-08 19:57 +0000
Re: the legacy of Seymour Cray Bob Eager <news0006@eager.cx> - 2016-01-08 21:50 +0000
Re: the legacy of Seymour Cray Alan Bowler <atbowler@thinkage.ca> - 2016-01-14 13:23 -0500
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2016-01-08 14:27 -0800
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2016-01-09 13:31 -0600
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2016-01-09 17:22 -0500
Re: the legacy of Seymour Cray Alan Bowler <atbowler@thinkage.ca> - 2016-01-14 13:30 -0500
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2016-01-08 17:01 -0600
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-01-09 01:10 +0000
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2016-01-08 22:33 -0600
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-09 23:43 -0500
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-08 05:14 +0000
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-07 16:34 -0500
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-07 19:38 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-07 19:17 -0700
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-08 05:14 +0000
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-08 12:20 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-08 09:45 -0700
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-08 14:05 -0400
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-08 15:06 -0500
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-08 16:20 -0400
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-08 16:35 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-09 18:12 -0700
Re: the legacy of Seymour Cray Dan Espen <despen@verizon.net> - 2015-10-10 00:22 -0400
Re: the legacy of Seymour Cray Morten Reistad <first@last.name.invalid> - 2015-10-07 23:44 +0200
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-07 18:33 -0400
Re: the legacy of Seymour Cray Walter Bushell <proto@panix.com> - 2015-10-08 14:36 -0400
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-08 11:57 -0700
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-08 12:51 -0700
Re: the legacy of Seymour Cray Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-08 21:09 -0600
Re: the legacy of Seymour Cray terry+googleblog@tmk.com - 2015-10-09 06:12 -0700
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-08 15:12 -0500
Re: the legacy of Seymour Cray Walter Bushell <proto@panix.com> - 2015-10-08 17:47 -0400
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-09 16:32 -0500
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-08 12:12 -0700
Re: the legacy of Seymour Cray Morten Reistad <first@last.name.invalid> - 2015-10-08 21:40 +0200
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-08 16:33 -0400
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-06 17:32 -0700
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-07 01:17 +0000
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-06 23:29 -0500
Re: the legacy of Seymour Cray hancock4@bbs.cpcn.com - 2015-10-07 08:13 -0700
Re: the legacy of Seymour Cray The New Other Guy <Newsgnus@gmail.com> - 2015-10-11 22:51 -0700
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-06 23:19 -0500
Re: the legacy of Seymour Cray Al Kossow <aek@bitsavers.org> - 2015-10-06 11:44 -0700
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-06 16:24 -0500
Re: the legacy of Seymour Cray simon@twoplaces.co.uk (Simon Turner) - 2015-10-08 11:33 +0100
Re: the legacy of Seymour Cray Morten Reistad <first@last.name.invalid> - 2015-10-08 13:13 +0200
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-08 12:20 -0400
Re: the legacy of Seymour Cray simon@twoplaces.co.uk (Simon Turner) - 2015-10-09 10:32 +0100
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-08 15:42 -0500
Re: the legacy of Seymour Cray simon@twoplaces.co.uk (Simon Turner) - 2015-10-09 11:19 +0100
Re: the legacy of Seymour Cray The New Other Guy <Newsgnus@gmail.com> - 2015-10-11 22:34 -0700
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-12 23:23 -0500
Re: the legacy of Seymour Cray Peter Flass <peter_flass@yahoo.com> - 2015-10-13 10:36 -0400
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-13 11:39 -0500
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-13 18:23 +0000
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-13 10:51 -0700
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-13 18:34 +0000
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-13 14:59 -0700
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-13 17:47 -0500
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-14 03:15 +0000
Re: the legacy of Seymour Cray Stan Barr <plan.b@bluesomatic.org> - 2015-10-14 07:07 +0000
Re: the legacy of Seymour Cray Jon Elson <jmelson@wustl.edu> - 2015-10-13 17:43 -0500
Re: the legacy of Seymour Cray Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-10-14 05:39 +0000
Re: the legacy of Seymour Cray scott@slp53.sl.home (Scott Lurndal) - 2015-10-14 13:11 +0000
Re: the legacy of Seymour Cray "Joe Morris" <j.c.morris@verizon.net> - 2015-10-13 20:52 -0400
Re: the legacy of Seymour Cray Michael Black <et472@ncf.ca> - 2015-10-13 14:43 -0400
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-05 17:26 -0700
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-05 18:43 -0700
Re: the legacy of Seymour Cray Anne & Lynn Wheeler <lynn@garlic.com> - 2015-10-05 22:32 -0700
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-05 23:33 -0500
Re: the legacy of Seymour Cray Quadibloc <jsavard@ecn.ab.ca> - 2015-10-06 08:03 -0700
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-06 16:36 -0500
Re: the legacy of Seymour Cray The New Other Guy <Newsgnus@gmail.com> - 2015-10-11 22:53 -0700
Re: the legacy of Seymour Cray pechter@S20.pechter.dyndns.org (William Pechter) - 2015-10-10 15:54 +0000
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-11 13:51 -0500
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-06 16:30 -0500
Re: the legacy of Seymour Cray "Joe Morris" <j.c.morris@verizon.net> - 2015-10-06 19:44 -0400
Re: the legacy of Seymour Cray Jon Elson <elson@pico-systems.com> - 2015-10-05 12:02 -0500
Re: the legacy of Seymour Cray "Charles Richmond" <numerist@aquaporin4.com> - 2015-10-05 16:46 -0500
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-10-11 08:35 -0400 |
| Message-ID | <mvdl30$jd2$1@speranza.aioe.org> |
| In reply to | #152635 |
On 10/10/2015 12:12 PM, Charlie Gibbs wrote: > On 2015-10-10, Peter Flass <peter_flass@yahoo.com> wrote: > >> IME it's pretty hard to convert assembler to anything. I think >> Autocoder might be simpler than some, but assembler programs just >> use too many tricks that make conversion to any HLL difficult. >> I've given some thought to converting some 360 assembler code, and >> this particular code is so convoluted I haven't even had any luck >> doing it manually. > > Yup. Some people got into tricks like instruction modification, > which made a real rat's nest. > >> Converting one HLL to another would seem to be somewhat easier. > > Generally, yes, but not necessarily. I remember two of us spending > several days trying to understand a holiday pay accrual routine in a > payroll program written in RPG. It was a nightmare - full of > indicators and loops. We never did figure it out; we determined it > would be easier to get a new set of specs from the payroll department > and re-write the routine from scratch. > Embedded system assembler converts reasonably easily because essentially all the code written for embedded systems has separate instruction and data space and this limits its ability to do self modifying code. How we have done it was been to have the assembler generate a hll representation of the assembler and then use a compiler to compile the result back into the assembler of the target processor. Because the generated statements are simple the target hll compiler will generally do a good job of optimizing the result. Re targeted code often being shorter than the original. The difficult translation issues for embedded systems is I/O support which can never be directly or automatically translated. Retargeting back to the original processor is interesting. Depending how effective the original developers were with using an ISA It has often resulted in more effective or small code. w..
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2015-10-11 08:40 -0400 |
| Message-ID | <519806493.466259962.009503.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #152677 |
Walter Banks <walter@bytecraft.com> wrote: > On 10/10/2015 12:12 PM, Charlie Gibbs wrote: >> On 2015-10-10, Peter Flass <peter_flass@yahoo.com> wrote: >> >>> IME it's pretty hard to convert assembler to anything. I think >>> Autocoder might be simpler than some, but assembler programs just >>> use too many tricks that make conversion to any HLL difficult. >>> I've given some thought to converting some 360 assembler code, and >>> this particular code is so convoluted I haven't even had any luck >>> doing it manually. >> >> Yup. Some people got into tricks like instruction modification, >> which made a real rat's nest. >> >>> Converting one HLL to another would seem to be somewhat easier. >> >> Generally, yes, but not necessarily. I remember two of us spending >> several days trying to understand a holiday pay accrual routine in a >> payroll program written in RPG. It was a nightmare - full of >> indicators and loops. We never did figure it out; we determined it >> would be easier to get a new set of specs from the payroll department >> and re-write the routine from scratch. >> > Embedded system assembler converts reasonably easily because essentially > all the code written for embedded systems has separate instruction and > data space and this limits its ability to do self modifying code. > > How we have done it was been to have the assembler generate a hll > representation of the assembler and then use a compiler to compile the > result back into the assembler of the target processor. Because the > generated statements are simple the target hll compiler will generally > do a good job of optimizing the result. Re targeted code often being > shorter than the original. > > The difficult translation issues for embedded systems is I/O support > which can never be directly or automatically translated. > > Retargeting back to the original processor is interesting. Depending > how effective the original developers were with using an ISA It has > often resulted in more effective or small code. > Interesting. What do you use for the HLL representation? -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-10-11 12:13 -0400 |
| Message-ID | <mve1rc$gj4$1@speranza.aioe.org> |
| In reply to | #152678 |
On 11/10/2015 8:40 AM, Peter Flass wrote: > Walter Banks <walter@bytecraft.com> wrote: >> On 10/10/2015 12:12 PM, Charlie Gibbs wrote: >>> On 2015-10-10, Peter Flass <peter_flass@yahoo.com> wrote: >>> >>>> IME it's pretty hard to convert assembler to anything. I think >>>> Autocoder might be simpler than some, but assembler programs just >>>> use too many tricks that make conversion to any HLL difficult. >>>> I've given some thought to converting some 360 assembler code, and >>>> this particular code is so convoluted I haven't even had any luck >>>> doing it manually. >>> >>> Yup. Some people got into tricks like instruction modification, >>> which made a real rat's nest. >>> >>>> Converting one HLL to another would seem to be somewhat easier. >>> >>> Generally, yes, but not necessarily. I remember two of us spending >>> several days trying to understand a holiday pay accrual routine in a >>> payroll program written in RPG. It was a nightmare - full of >>> indicators and loops. We never did figure it out; we determined it >>> would be easier to get a new set of specs from the payroll department >>> and re-write the routine from scratch. >>> >> Embedded system assembler converts reasonably easily because essentially >> all the code written for embedded systems has separate instruction and >> data space and this limits its ability to do self modifying code. >> >> How we have done it was been to have the assembler generate a hll >> representation of the assembler and then use a compiler to compile the >> result back into the assembler of the target processor. Because the >> generated statements are simple the target hll compiler will generally >> do a good job of optimizing the result. Re targeted code often being >> shorter than the original. >> >> The difficult translation issues for embedded systems is I/O support >> which can never be directly or automatically translated. >> >> Retargeting back to the original processor is interesting. Depending >> how effective the original developers were with using an ISA It has >> often resulted in more effective or small code. >> > > Interesting. What do you use for the HLL representation? > I use a modified C compiler. The assembler is modified in a couple ways that it generates the HLL. The first is a simple translation into simple C statements, the second is a simple finite state machine that deals with condition code tracking and resolves things like the how branch tests work following various operations. For example a subtract of a number by itself in some processors leaves the carry set other the carry is clear. The C compiler changes include cosmetic changes so listings display the original assembler and not the intermediate code and ties source level debugging back to the original source. Between the assembler and the compiler it identifies asm source and I/O that cannot be translated. This part is in the compiler as a rule based expert system. The rules are defined as part of a translation header file. All in in all it is a 95% solution. The compiler support is in most of the compilers we have released in the last decade or so. We have about a half dozen modified assemblers. w..
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-10 19:32 -0700 |
| Message-ID | <097c177a-a21d-4b22-a764-ae39ec1cfc43@googlegroups.com> |
| In reply to | #152623 |
On Saturday, October 10, 2015 at 9:00:58 AM UTC-4, Peter Flass wrote: > IME it's pretty hard to convert assembler to anything. I think Autocoder > might be simpler than some, but assembler programs just use too many tricks > that make conversion to any HLL difficult. I've given some thought to > converting some 360 assembler code, and this particular code is so > convoluted I haven't even had any luck doing it manually. I think 1401 Autocoder was a lot simpler than 360 Assembler, but there still could be tricks as you say and get very hairy in COBOL, if even possible. At the same time Datamation aadvertised 1401 to COBOL converters, they advertised COBOL code generators that supposedly sped up programming. These produced equally lousy code. > Converting one HLL to another would seem to be somewhat easier. We had a 6,000 line COBOL program written for a word oriented machine that needed to be converted to IBM style. It did things like put spaces in numeric fields and test for them, and had numerous printer writes without the carriage control, among other incompatibilities. It was so messy (the large size didn't help) we abandoned the effort.
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2015-10-10 22:51 -0400 |
| Message-ID | <mvcioh$ktu$1@dont-email.me> |
| In reply to | #152666 |
hancock4@bbs.cpcn.com writes: > On Saturday, October 10, 2015 at 9:00:58 AM UTC-4, Peter Flass wrote: > > >> IME it's pretty hard to convert assembler to anything. I think Autocoder >> might be simpler than some, but assembler programs just use too many tricks >> that make conversion to any HLL difficult. I've given some thought to >> converting some 360 assembler code, and this particular code is so >> convoluted I haven't even had any luck doing it manually. > > I think 1401 Autocoder was a lot simpler than 360 Assembler, but there > still could be tricks as you say and get very hairy in COBOL, if even > possible. > > At the same time Datamation aadvertised 1401 to COBOL converters, they > advertised COBOL code generators that supposedly sped up programming. > These produced equally lousy code. I worked with a COBOL program generated from a 1401 object deck. (The source was long lost.) It was not as hard as one might think to clean it up. Using the known record layouts, fields could be identified and labels changed. The COBOL ended up looking just like any other code with a few days work. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2015-10-11 13:37 -0500 |
| Message-ID | <1O-dnaKWnPHiMYfLnZ2dnUU7-dednZ2d@giganews.com> |
| In reply to | #152668 |
Dan Espen wrote: > > I worked with a COBOL program generated from a 1401 object deck. > (The source was long lost.) > > It was not as hard as one might think to clean it up. > > Using the known record layouts, fields could be identified > and labels changed. > > The COBOL ended up looking just like any other code with > a few days work. If you KNEW exactly what the program did, will all record fields, printed output, etc. then you almost didn't NEED the source (or object code). You could check a few things in the object to make sure you are handling certain cases the same way. But, you would likely NOT "convert" the program, you would just write it cleanly, adapting to the style and features of the target language. Most programs written on the 1401 were just NOT that complex. Especially if written originally in assembler. Jon
[toc] | [prev] | [next] | [standalone]
| From | "Joe Morris" <j.c.morris@verizon.net> |
|---|---|
| Date | 2015-10-10 12:07 -0400 |
| Message-ID | <mvbd2702sn2@news7.newsguy.com> |
| In reply to | #152606 |
<hancock4@bbs.cpcn.com> wrote: > Joe Morris wrote: >> In 1967 my PPOE swapped out a 1460 for a 360/40 running MFT-1; it ran >> batch >> jobs in P1 (86KB, which supported FORTG) but had a 16K P0 that was used >> to >> handle spooling for our 7040. Controlling the spool program - especially >> responding to a runaway print job - would have been cumbersome if the >> 1052-7 >> console were used, so I wrote a utility that allowed a program to read >> the >> data and address switches on the console so, for example, the operator >> could >> kill a runaway print job by merely flipping one of the switches. > Pretty slick! ...and also a bit dangerous because it used the DIAGNOSE opcode, which behaves differently on different models. On the /40, the DIAG command set the ROSAR (Read-Only Storage Address Register) to the effective address. My memory says that the read-address-switches code was at 0x143 and read-data-switches was at 0x145, both of which exited at 0x144. Although at the time the shop's only S/360 was a /40, I wrote a macro (named ENK from the 704x/709x "Enter Keys" opcode mnemonic) with paramters that would emit code appropriate for any of the /360 line up to and including the /75. I found the info I needed to write it by reading the source listings for the FE diagnostic tools (and in the process found a bug in one of them). Joe
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2015-10-09 13:23 +0000 |
| Message-ID | <4dPRx.2564$CV7.1190@fx30.iad> |
| In reply to | #152493 |
Dan Espen <despen@verizon.net> writes: >Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes: > >> On 2015-10-08, Dan Espen <despen@verizon.net> wrote: >> >>> The 1401 had some physical switches on the console a program >>> could read for job options, (the UPSI switches). When running >>> in emulation, a JCL statement allowed you to simulate the switch >>> settings. >> >> The UPSI byte lived on natively in the various 360 operating systems, >> as well as its Univac counterparts. A bit of googling even shows it >> living in CMS. > >So, I'm thinking, surely not in z/OS. > >Nope, there it is living as an LE option and accessible in COBOL. >Even there in Micro Focus COBOL. > >Some things just refuse to die. > >I wouldn't use UPSI switches on the 1401 and it's ugly carcass is still festering. The Burroughs B3500 had a six-position application switch register. It lived on in subsequent generations as a control card. For example: EX DMPALL; SW 1 1 turned switch one on when running the DMPALL utility. <mix#>sw 1 1 would turn on the switch for the task identified by <mix#> The application would interrogate the first six digits of the application address space for the switch values. Some applications would only test the switch at startup, others would periodically poll the switch.
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <jmelson@wustl.edu> |
|---|---|
| Date | 2015-10-08 14:37 -0500 |
| Message-ID | <vLudnQ3a2qguWIvLnZ2dnUU7-f2dnZ2d@giganews.com> |
| In reply to | #152433 |
Joe Pfeiffer wrote: > Dan Espen <despen@verizon.net> writes: > I was never in an IBM shop, so this question comes from complete > ignorance: the emulated 1401 used the 360's physical console switches? > Well, you COULD do that. But, the general mode on the /30 was you flipped a front panel switch that set the machine to emulation mode (vs 360 mode), put an object card deck in the reader and hit load. The card deck would be read into memory. Then, you would put the data input cards in the reader, or put tape(s) on the drive(s) and it would take off and run. When the printer completed printing whatever it was supposed to print, you'd put the next object deck in the reader and hit load again. I seem to recall the 1401 had some sense switches on the front panel that some programs used to know when to start reading the next tape or whatever, and I suppose the 360/30 emulation provided the same capability. I saw a (real) 1401 run at my university in 1971 or so. As far as I know, we did NOT use 1401 emulation on our 360's. We DID have 7094 emulation and used it for some programs that they were loathe to convert. Higher-end 360's had the ability to run emulation under OS/360, so you didn't have to select emulation from the console switches, and you could load the 14xx/70xx programs from disk. I never did know how you debugged such code. If debugging 360 programs was difficult (mostly plowing through core dumps) I can only imagine debugging 1401 code under emulation might have been even more primitive. I do remember debugging crashes on 12-bit minis. Since there was no program exception logic, and a halt instruction was only one code out of 4096, most crashes left total chaos in memory, so post-mortem dumps were pretty useless. Ahh, the bad old days, I really don't miss that part of it! Jon
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-08 13:16 -0700 |
| Message-ID | <ce09058a-11fe-4d60-a9ab-b168b11f3f16@googlegroups.com> |
| In reply to | #152496 |
On Thursday, October 8, 2015 at 3:36:20 PM UTC-4, Jon Elson wrote: > Well, you COULD do that. But, the general mode on the /30 was you flipped a > front panel switch that set the machine to emulation mode (vs 360 mode), put > an object card deck in the reader and hit load. The card deck would be read > into memory. Then, you would put the data input cards in the reader, or put > tape(s) on the drive(s) and it would take off and run. When the printer > completed printing whatever it was supposed to print, you'd put the next > object deck in the reader and hit load again. I seem to recall the 1401 had > some sense switches on the front panel that some programs used to know when > to start reading the next tape or whatever, and I suppose the 360/30 > emulation provided the same capability. IIRC, the majority of /30's were run under DOS, not one of the smaller operating systems, like BPS, BOS, or TOS. Disk sales were very successful, surprising IBM and creating a shortage. Maybe the earliest /30's in 1965 were austere, but I think they were upgraded as time went on. (Someone correct me if I'm wrong). 360-DOS JCl was very simple. The console was left alone except for IPL. The operator would only hit the load to IPL. IIRC, the typical size of a /30 was about 32k or even 64k, not too many 16k machines. Initially they offered an 8k model, but I think this was withdrawn. Most buyers bought more memory than IBM expected. I can't help but suspect users of the smallest card-only 1401's weren't in a hurry to go to S/360 as their operation was so simple and austere that upgrading wouldn't offer much benefit. In contrast, users of more complex 1401's, with disk and 16k memory, were doing more stuff and could exploit the higher power of S/360. Indeed, one reason IBM developed the low-cost System/3 was to provide an attractive computer option for those small users. I don't believe there was any "1401 mode" on S/360. If one wanted to run an emulated program, one simply loaded and executed the emulator, and then call in the object code of the desired program (be it from card or disk). If one had multi-programming, you could run 1401 in one space, 360 in another. We did. ref: http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/360/funcChar/GA24-3231-7_360-30_funcChar.pdf (This includes I/O information, including overlapping Selector Channel with the CPU, and various timings.)
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-08 13:32 -0700 |
| Message-ID | <990b8d0e-cf9f-445d-b44d-bba8c260488c@googlegroups.com> |
| In reply to | #152505 |
On Thursday, October 8, 2015 at 4:16:51 PM UTC-4, hanc...@bbs.cpcn.com wrote: > I don't believe there was any "1401 mode" on S/360. If one wanted to run an emulated program, one simply loaded and executed the emulator, and then call in the object code of the desired program (be it from card or disk). If one had multi-programming, you could run 1401 in one space, 360 in another. We did. No, there wasn't a 1401 mode switch. "specially produced initialization deck accompanies the System/360, Model 30, equipped with the 1401 compatibility feature. This deck is used each time the system is used in 1401 compatibility mode. It is normally reproduced several time s and placed in front of any 1401 program to be run on the system."
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2015-10-08 20:11 -0400 |
| Message-ID | <mv70jh$5pv$1@dont-email.me> |
| In reply to | #152505 |
hancock4@bbs.cpcn.com writes: > I can't help but suspect users of the smallest card-only 1401's > weren't in a hurry to go to S/360 as their operation was so simple and > austere that upgrading wouldn't offer much benefit. I had a night job at Old London Foods. I would operate their card only 1.4K 1401. I ended up coding all their jobs for their new S360/20 using RPG. A very successful venture, and I got paid pretty well for the coding. There was somewhat of a hurry. Everyone realized we'd seen the end of the 1401, and something needed to be done to keep the business operating. I don't know if every card only 1401 became a /20, but the conversion made a lot of sense. > In contrast, > users of more complex 1401's, with disk and 16k memory, were doing > more stuff and could exploit the higher power of S/360. Yep, either 30 or 40. > Indeed, one reason IBM developed the low-cost System/3 was to provide > an attractive computer option for those small users. Quite a few years passed between S/360 and S/3. Wikipedia has the S/3 as 1969. Four years running a dead end system isn't good. > I don't believe there was any "1401 mode" on S/360. I don't remember one. There were hardware instructions, but no console switch that I remember. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <jmelson@wustl.edu> |
|---|---|
| Date | 2015-10-09 13:57 -0500 |
| Message-ID | <NfGdnUNMDaInkIXLnZ2dnUU7-aGdnZ2d@giganews.com> |
| In reply to | #152505 |
hancock4@bbs.cpcn.com wrote: > > I don't believe there was any "1401 mode" on S/360. If one wanted to run > an emulated program, one simply loaded and executed the emulator, and then > call in the object code of the desired program (be it from card or disk). > If one had multi-programming, you could run 1401 in one space, 360 in > another. We did. I believe the only machine that had this emulation mode was the 360/30. What you say was true for the higher models. Jon
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2015-10-09 21:46 -0500 |
| Message-ID | <Y6ednYapudaP4YXLnZ2dnUU7-QOdnZ2d@giganews.com> |
| In reply to | #152564 |
Jon Elson wrote: > hancock4@bbs.cpcn.com wrote: > > >> >> I don't believe there was any "1401 mode" on S/360. If one wanted to run >> an emulated program, one simply loaded and executed the emulator, and >> then call in the object code of the desired program (be it from card or >> disk). If one had multi-programming, you could run 1401 in one space, 360 >> in >> another. We did. > I believe the only machine that had this emulation mode was the 360/30. > What you say was true for the higher models. > Grumble! Somebody that I THOUGHT knew this told me that the /30 had a switch for selecting emulation. Looking at the operator's manual, there clearly is NO such switch, so I was told wrong. Now, on the /25, you loaded the emulator of your choice from cards or whatever into the writable control store (actually just the top of main memory). With 16 KB reserved for the emulator, it seems like it could probably hold both 360 and 1401 at the same time, but apparently you could just load the one you wanted. This is actually described in passing in one of the manuals on bitsavers. Jon
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2015-10-09 16:47 +0000 |
| Message-ID | <mv8r3f010ml@news7.newsguy.com> |
| In reply to | #152496 |
On 2015-10-08, Jon Elson <jmelson@wustl.edu> wrote: > I do remember debugging crashes on 12-bit minis. Since there was no program > exception logic, and a halt instruction was only one code out of 4096, most > crashes left total chaos in memory, so post-mortem dumps were pretty > useless. Ahh, the bad old days, I really don't miss that part of it! Ah yes... I remember that the front panel lights on my IMSAI would flicker in a particular pattern that indicated a stack loop. I didn't have to look any futher to realize that all of memory had been clobbered. -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2015-10-09 18:18 +0000 |
| Message-ID | <_xTRx.74818$Rj5.68068@fx02.iad> |
| In reply to | #152555 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes: >On 2015-10-08, Jon Elson <jmelson@wustl.edu> wrote: > >> I do remember debugging crashes on 12-bit minis. Since there was no program >> exception logic, and a halt instruction was only one code out of 4096, most >> crashes left total chaos in memory, so post-mortem dumps were pretty >> useless. Ahh, the bad old days, I really don't miss that part of it! > >Ah yes... I remember that the front panel lights on my IMSAI would flicker >in a particular pattern that indicated a stack loop. I didn't have to look >any futher to realize that all of memory had been clobbered. Burroughs medium systems customers were upset when channel activity lights were not present on the Bx900 series machines (thay had been on all prior generations). Customers had used them as surrogate activity indicators for the system. A couple customers built custom channel light arrays for their own systems.
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-07 19:39 -0700 |
| Message-ID | <60111e8e-e130-43e5-81b6-508e91d3eaaa@googlegroups.com> |
| In reply to | #152421 |
On Wednesday, October 7, 2015 at 5:50:50 PM UTC-4, Jon Elson wrote: > Oh, yes, I think the guys who just STAYED in 1401 mode were running a nearly > all-card or card and tape shop. Once you had disks on the machine, the > advantage of 360 mode just had to be a huge reason to update the system. The 1401 had disks, and emulation included emulating a 1401 disk on a 360 disk. Not as efficient as native mode, and wasted space. However, it meant 1401 programs could still run unchanged (more below). > > Indeed, many places ran 1401 code into the 1990s. > Ugh, how horrid! 1990's??? Geez, you could do whatever you wanted on a > network-connected PC by then! Even in Cobol, if you must! I can't IMAGINE > the hair-pulling hassle of trying to debug a program bug in emulated 1401 on > a 360/30 from the console switches! YIKES, what a horror movie that would > be, compared to decent debug facilities on modern OS's. The issue was the high cost of rewriting an existing system that was working. If the existing system meant the user's needs, as many did, the user would seriously question spending money to rewrite it. Remember, on Z series, there are plenty of 30-40 year old COBOL systems still in service; a _single_ large application could cost millions of dollars to rewrite. > Obviously, they weren't running 1401 emulation on a 360/30 in the 1990's. Well, not on a /30, but on whatever model IBM mainframe was in use at that time. > Yes, of course, there were huge advanges in moving up to larger machines > with serious OS support, better languages, comms, big disks, etc. but some > of that could NOT be done on the /30, due to some of its limitations. The > models /22 and /25 went up to 16-bit memory, and relieved some of these > bottlenecks. Well, obviously is an organization's needs have grown, then it would time to trade in the 360/30 for a larger machine. Many places did just that (ours went from a /30 to a /40 after two years as more applications were added to it.) That was a key design feature of S/360--allowing upgrades without rewriting code--not as common in the pre-360 era. For instance, large machines had a different addressing structure than small machines, in S/360 addressing was universal.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2015-10-08 05:14 +0000 |
| Message-ID | <mv4u3e230md@news4.newsguy.com> |
| In reply to | #152437 |
On 2015-10-08, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote: > On Wednesday, October 7, 2015 at 5:50:50 PM UTC-4, Jon Elson wrote: > >> Ugh, how horrid! 1990's??? Geez, you could do whatever you wanted on a >> network-connected PC by then! Even in Cobol, if you must! I can't IMAGINE >> the hair-pulling hassle of trying to debug a program bug in emulated 1401 on >> a 360/30 from the console switches! YIKES, what a horror movie that would >> be, compared to decent debug facilities on modern OS's. > > The issue was the high cost of rewriting an existing system that was working. > If the existing system meant the user's needs, as many did, the user would > seriously question spending money to rewrite it. This is where commercial and consumer mindsets differ. In a commercial shop (at least one which hasn't been infected by consumer thinking), "if it ain't broke, don't fix it." In the consumer environment, on the other hand, people are persuaded to throw away their apps - and even their OS - every year. The replacements all have learning curves that must be climbed, and might not even be as capable as the old systems. But the pictures sure are pretty... One of my favourite sayings: "This system is a great improvement on its successors." -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-08 07:47 -0700 |
| Message-ID | <f287e390-472d-4096-a09c-d5e07672173f@googlegroups.com> |
| In reply to | #152443 |
On Thursday, October 8, 2015 at 1:15:28 AM UTC-4, Charlie Gibbs wrote: > This is where commercial and consumer mindsets differ. In a commercial shop > (at least one which hasn't been infected by consumer thinking), "if it ain't > broke, don't fix it." In the consumer environment, on the other hand, people > are persuaded to throw away their apps - and even their OS - every year. > The replacements all have learning curves that must be climbed, and might > not even be as capable as the old systems. But the pictures sure are pretty... Well, 1401 programs could have a lifespan of up to 40 years (1960-1999). Not bad. Undoubtedly, there are some S/360 COBOL/CICS systems still in service approaching 40 years of service. There may even be some S/360 batch systems or pieces that go back even further. But the 'modern' consumer industry learned very well from Alfred Sloan's GM annual model change and planned obsolescence. Some years ago, I remember reading an article in a PC magazine questioning if waiting three years before replacing a PC was too _long_ -- and this was back when a PC was still well over a thousand bucks. I also remember people bragging that they had a new 386 compared to others 286 or even 8086, then 486, then their Pentiums. The computer industry still has its customers, even businesses, brainwashed to upgrade their operating systems, web browsers, word processor/spreadsheets, etc, every few years. Oracle puts out new versions, forcing its customers to upgrade.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Wolstenholme <steve@easynn.com> |
|---|---|
| Date | 2015-10-08 16:03 +0100 |
| Message-ID | <8o0d1b1fulq4jpecicokm0ls54rtdr8iaq@4ax.com> |
| In reply to | #152466 |
On Thu, 8 Oct 2015 07:47:38 -0700 (PDT), hancock4@bbs.cpcn.com wrote: >The computer industry still has its customers, even businesses, brainwashed to upgrade their operating systems, web browsers, word processor/spreadsheets, etc, every few years. Oracle puts out new versions, forcing its customers to upgrade. It's age related! When I was young, working on mainframes, I remember a frequent dedicated session testing and fixing all the hardware and software. Now I'm getting on a bit I don't bother to get the latest & greatest of everything. Real problems are obvious. Steve -- Neural Network Software for Windows http://www.npsnn.com
[toc] | [prev] | [next] | [standalone]
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web