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 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | Jon Elson <jmelson@wustl.edu> |
|---|---|
| Date | 2015-10-08 15:00 -0500 |
| Message-ID | <tL-dne6Oku1hV4vLnZ2dnUU7-YnOydjZ@giganews.com> |
| In reply to | #152443 |
Charlie Gibbs wrote: > On 2015-10-08, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> 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." Hey, I understand. I just replaced a Windows 95 system that ran my laser photoplotter, because I knew it was eventually going to die. I didn't want the replacement to be a mad scramble when I neede to get stuff done. It was not simple, as the ond hardware required an ISA DMA card, and Win 95 to let the user-mode software get the the card and the DMA controller. I replaced it with a Beagle Bone running Linux. Jon
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2015-10-08 08:39 +0200 |
| Message-ID | <kmfhec-eml.ln1@sambook.reistad.name> |
| In reply to | #152437 |
In article <60111e8e-e130-43e5-81b6-508e91d3eaaa@googlegroups.com>, <hancock4@bbs.cpcn.com> wrote: >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. The transaction system for national interbanking money handling in .no still use the ~1975 core made by IDA, expanded and maintained, for a few more months. They got the rewrite going into production on the third attempt this summer, and the two are running in parallell for another year after that; with the new system feeding the old, and the results compared for correctness. These systems grew transaction links over networks to more than 100 different systems, initially as tapes but running spooled batches over comms links for the last 30 years. They all need to be kept in production. We see direct benefits from this already, The daily batch runs that updated banking across banks became 4 times a day two years ago, and now they are run every 15 minutes. >> 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. For the IDA systems that worked with at least 5 different hardware generations. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-10-08 08:57 -0600 |
| Message-ID | <1bfv1lxvam.fsf@pfeifferfamily.net> |
| In reply to | #152449 |
Morten Reistad <first@last.name.invalid> writes: > > We see direct benefits from this already, The daily batch runs that > updated banking across banks became 4 times a day two years ago, and now > they are run every 15 minutes. I remember many years ago when a friend of mine wanted to buy a used car, the seller wanted cash, it was a Saturday, and his daily ATM withdrawal limit wasn't high enough. We drove around to all the nearby bank branches and used the ATMs to get enough cash for the car... wouldn't work today! -- "Erwin, have you seen the cat?" -- Mrs. Shrödinger
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <jmelson@wustl.edu> |
|---|---|
| Date | 2015-10-08 14:57 -0500 |
| Message-ID | <tL-dne-Oku3TV4vLnZ2dnUU7-YnOydjZ@giganews.com> |
| In reply to | #152437 |
hancock4@bbs.cpcn.com wrote: > 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. > Yes, of course, there are some VERY large legacy software systems, and until regulatory change, corporate buyouts or something REQUIRES them to change, I can understand the resistance. But, I doubt there are any of these HUGE packages that were run in 1401 emulation. Jon
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2015-10-08 13:30 -0700 |
| Message-ID | <b388bb50-979c-402a-a241-98d8263ed835@googlegroups.com> |
| In reply to | #152501 |
On Thursday, October 8, 2015 at 3:56:00 PM UTC-4, Jon Elson wrote: > Yes, of course, there are some VERY large legacy software systems, and until > regulatory change, corporate buyouts or something REQUIRES them to change, I > can understand the resistance. But, I doubt there are any of these HUGE > packages that were run in 1401 emulation. When S/360 came out, customers were returning their 1401's to IBM. They still had some useful life in them, so IBM found other customers for them, offered for a low price. Our hospital was such a customer, and ran a full suite of 1401 programs to run the hospital. Eventually, the hardware of the 1401 gave out, and a 360 was required. But the applications marched on. Eventually the 360 was retired nad a 43xx was obtained, and the 1401 applications marched on. Over time, systems were gradually converted to 360 or replaced by 360 packages. But it took many years to do so.
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2015-10-09 23:36 -0500 |
| Message-ID | <dqudnSNME4JOCIXLnZ2dnUU7-bGdnZ2d@giganews.com> |
| In reply to | #152437 |
hancock4@bbs.cpcn.com wrote: > > 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). Well, that brings up another area. Having 360 files (datasets) all contiguous certainly did help efficiency. But, the downside is that this forces you to pre-allocate files by tracks and cylinders. In many cases you didn't know the exact size a file would need to be, so you allocated more space than you actually needed. So, every decision led to another decision. First, the idea was to make disks look like tapes without the need to search past the whole tape to get to a specific record. So, they had variable record size on the disk. This means that you can't have every record on the disk be interchangeable, so you can't format the whole disk with the same record size and then allocate files to free records as needed, and extend a file record by record as it grows. This (mostly) eliminates the file fragmentation issue and makes reads and writes more efficient, but ends up wasting a lot of space on those very expensive disks (I'm talking about back in the 60's). And, of course, IBM did eventually change over to fixed blocks size disks. I will say that the way IBM did disk I/O was WAY more efficient than any other system I was familiar with at the time. Records were read off the disk (or tape) directly into the user's buffer, not copied several times during record unpacking from an OS buffer to the user's buffer. Jon
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@iecc.com> |
|---|---|
| Date | 2015-10-10 05:18 +0000 |
| Subject | Re: IBM disks, was the legacy of Seymour Cray |
| Message-ID | <mva733$9kd$1@miucha.iecc.com> |
| In reply to | #152614 |
>I will say that the way IBM did disk I/O was WAY more efficient than any >other system I was familiar with at the time. Records were read off the >disk (or tape) directly into the user's buffer, not copied several times >during record unpacking from an OS buffer to the user's buffer. TOPS-10 generally did disk I/O directly in and out of buffers in user space. There was a UUO (system call) to set up a buffer ring, and then you used IN our OUT UUOs to wait for the next input buffer to be full or release an output buffer.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2015-10-10 09:16 -0400 |
| Message-ID | <608889922.466174530.647137.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #152614 |
Jon Elson <elson@pico-systems.com> wrote: > hancock4@bbs.cpcn.com wrote: > > >> >> 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). > Well, that brings up another area. Having 360 files (datasets) all > contiguous certainly did help efficiency. But, the downside is that this > forces you to pre-allocate files by tracks and cylinders. In many cases you > didn't know the exact size a file would need to be, so you allocated more > space than you actually needed. DOS. Most DOS sysprogs would have charts on their walls showing the current allocations for all their disk packs. > > So, every decision led to another decision. First, the idea was to make > disks look like tapes So that's the reason! I have often wondered why they did this. It's interesting that the underlying disks seem to have been sectorized anyhow, as far as I can tell from the Bitsavers manuals on the 2311, etc. without the need to search past the whole tape to get > to a specific record. So, they had variable record size on the disk. This > means that you can't have every record on the disk be interchangeable, so > you can't format the whole disk with the same record size and then allocate > files to free records as needed, and extend a file record by record as it > grows. > > This (mostly) eliminates the file fragmentation issue and makes reads and > writes more efficient, but ends up wasting a lot of space on those very > expensive disks (I'm talking about back in the 60's). > > And, of course, IBM did eventually change over to fixed blocks size disks. > > > I will say that the way IBM did disk I/O was WAY more efficient than any > other system I was familiar with at the time. Records were read off the > disk (or tape) directly into the user's buffer, not copied several times > during record unpacking from an OS buffer to the user's buffer. > It eliminates a lot of buffer shuffling for variable length records - each buffer would hold a complete block and no extra data. I've written code on other systems where you get to the point that the tail end of a buffer usually contains part of the next record, so you have to move that, do another disk read, and read the rest. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2015-10-10 11:20 -0400 |
| Message-ID | <mvba82$ioq$1@dont-email.me> |
| In reply to | #152624 |
Peter Flass <peter_flass@yahoo.com> writes: > Jon Elson <elson@pico-systems.com> wrote: >> hancock4@bbs.cpcn.com wrote: >> >> >>> >>> 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). >> Well, that brings up another area. Having 360 files (datasets) all >> contiguous certainly did help efficiency. But, the downside is that this >> forces you to pre-allocate files by tracks and cylinders. In many cases you >> didn't know the exact size a file would need to be, so you allocated more >> space than you actually needed. > > DOS. Most DOS sysprogs would have charts on their walls showing the > current allocations for all their disk packs. > >> >> So, every decision led to another decision. First, the idea was to make >> disks look like tapes > > So that's the reason! I have often wondered why they did this. It's > interesting that the underlying disks seem to have been sectorized anyhow, > as far as I can tell from the Bitsavers manuals on the 2311, etc. Not sure what you are reading, but the 1311 was sectorized, the 2311, 2314, 3330 are not. As Lynn often writes, z/OS to this day does not support FBA (sectorized disk) even though all modern hardware is FBA underneath. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2015-10-11 13:42 -0500 |
| Message-ID | <1O-dnd2WnPEUMIfLnZ2dnUU7-dednZ2d@giganews.com> |
| In reply to | #152624 |
Peter Flass wrote: > So that's the reason! I have often wondered why they did this. It's > interesting that the underlying disks seem to have been sectorized anyhow, > as far as I can tell from the Bitsavers manuals on the 2311, etc. > Well, they had "sectors" or records, as IBM called them, but they were variable size, truly, in the hardware. You could write one single record that filled 95% of a disk track. You needed room for a track descriptor record at the beginning of every track, that told what was on there. Then, the rest of the track was yours to break up as you wanted. Jon
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2015-10-10 18:08 -0700 |
| Message-ID | <87pp0m1ab8.fsf@lhwserver.localdomain> |
| In reply to | #152614 |
Jon Elson <elson@pico-systems.com> writes: > I will say that the way IBM did disk I/O was WAY more efficient than any > other system I was familiar with at the time. Records were read off the > disk (or tape) directly into the user's buffer, not copied several times > during record unpacking from an OS buffer to the user's buffer. IBM allowed channel programs to be built by application library ... and read/written directly into application address space ... either directly in application buffers or in buffers managed in application space managed by library code running in application space. However, original 360 design point was very limited real storage ... so trade-off was to do lots of stuff with index on disks and multi-track search (trading off real storage for index versus i/o channel for sequential index search) ... aka CKD dasd. However, by mid-70s this trade-off started to flip ... significant increase in real storage and i/o capacity was becoming major bottleneck. VTOC was disk volume directory of files. Multi-track search would serially scan VTOC for file entry to be opened/used ... VTOC entry contained file location on disk (and other misc. information). VTOC scan could involve serveral disk revolutions ... tieing up disk, controller and channel (not being able to use for any other purpose). The other major use was for "PDS" libraries ... nearly all executables and several other uses. A standard PDS library could involve a 2-3 cylinder directory. A multi-track search would sequentially scan all tracks until desired PDS member entry was found. I've periodically mention getting called into datacenter for large national retailer that was experiencing significant performance degradation with their store online transaction system under heavy load. They had several 370/168-3 and large shared CKD 3330 DASD pool dedicated to running store online transactions under MVS . All the national experts had been called in before resorting to calling me. I was brought into class room where all the tables were covered with foot high stacks of performance reports. After about 30 mins I started to notice correlation that the aggregate I/O activity across all the 168-3 processors for a specific volume was peaking at 7 I/Os per second at peak load ... which was a little unusual since 3330 was nominal considered to have throughput of 30-40 I/Os per second. It turned out that 3330 contained the PDS online transaction library for all 168 systems and all stores. It had 3cyl PDS library directory ... and each transaction required reading the library directory to find the transaction and then load it. On the avg. PDS search is 1.5 cylinders ... or for 3330 that is one multi-track search of 19cylenders taking 19 revolutions at 3600RPM taking .317seconds elapsed time ... followed by multi-track search of 9.5 cylinders taking 9.5 revolutions or .158 seconds ... each transaction requires avg. of .475 seconds just to find the location of the transaction executable to be loaded (during which time the device, controller and channel is busy and can't be used for anything else). The actual load takes around .03 seconds ... but with the PDS lookup time, the whole complex was limited to a maximum of two transactions per second ... across all systems and for all stores in the country. The resolution was to split the online executable library into three different parts (so avg. PDS lookup is around 9.5 tracks instead of 28.5 tracks) .... and then replicate the library so there is unique copy for each 168-3 system. That up the transaction (load) rate to 10-15 transaction per system and 40-60 per second for the whole complex. The IBM disk division did fixed-block (FBA) disks starting in the late 70s (3310 & 3370) ... but I was told by the MVS people that even if I provided them with fully tested & integrated MVS FBA support, I would still need an incremental $26M profit (for documentation and education) ... basically $200M-$300M new disk sales ... they then qualified it by saying customers were buying disks as fast as they could be made ... and if there was FBA support, customers would just switch from buying CKD disks to same amount of FBA disks. However, part of FBA support includes moving off the enormously expensive mid-60s multi-track search design. As an aside, no real CKD devices have been made for decades, being simulated on industry standard fixed-block disks. Some past posts http://www.garlic.com/~lynn/submain.html#dasd Aother problem is that channel program use "real addresses" but with os/360 move to MVS ... the application library building channel programs is now running in virtual address space and all the resulting channel programs are built with virtual addresses. Standard OS/360 & MVS convention passes the address of the channel program in EXCP/SVC0 supervisor call. With OS/360 move to virtual address, the EXCP process now has to build a copy of the passed channel program substituting real addresses for the virtual addresses. This turns out to be the same exact process that (virtual machine) CP67 had to do for running guest operating systems in virtual address space. It turns out the person doing the OS/360 initial prototype move to virtual memory, borrowed the CP67 "CCWTRANS" routine and crafted into the side of EXCP processing. past posts mentioning (CP67) CCWTRANS: http://www.garlic.com/~lynn/2000.html#68 Mainframe operating systems http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love? http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...] http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline? http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline? http://www.garlic.com/~lynn/2001l.html#36 History http://www.garlic.com/~lynn/2002c.html#39 VAX, M68K complex instructions (was Re: Did Intel Bite Off More Than It Can Chew?) http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware http://www.garlic.com/~lynn/2002j.html#70 hone acronym (cross post) http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems http://www.garlic.com/~lynn/2002n.html#62 PLX http://www.garlic.com/~lynn/2003b.html#0 Disk drives as commodities. Was Re: Yamhill http://www.garlic.com/~lynn/2003g.html#13 Page Table - per OS/Process http://www.garlic.com/~lynn/2003k.html#27 Microkernels are not "all or nothing". Re: Multics Concepts For http://www.garlic.com/~lynn/2004.html#18 virtual-machine theory http://www.garlic.com/~lynn/2004c.html#59 real multi-tasking, multi-programming http://www.garlic.com/~lynn/2004d.html#0 IBM 360 memory http://www.garlic.com/~lynn/2004g.html#50 Chained I/O's http://www.garlic.com/~lynn/2004m.html#16 computer industry scenairo before the invention of the PC? http://www.garlic.com/~lynn/2004n.html#26 PCIe as a chip-to-chip interconnect http://www.garlic.com/~lynn/2004n.html#54 CKD Disks? http://www.garlic.com/~lynn/2004o.html#57 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005b.html#23 360 DIAGNOSE http://www.garlic.com/~lynn/2005b.html#49 The mid-seventies SHARE survey http://www.garlic.com/~lynn/2005b.html#50 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005f.html#47 Moving assembler programs above the line http://www.garlic.com/~lynn/2005p.html#18 address space http://www.garlic.com/~lynn/2005q.html#41 Instruction Set Enhancement Idea http://www.garlic.com/~lynn/2005s.html#25 MVCIN instruction http://www.garlic.com/~lynn/2005t.html#7 2nd level install - duplicate volsers http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory? http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory? http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion - DISAPPOINTMENT http://www.garlic.com/~lynn/2006i.html#33 virtual memory http://www.garlic.com/~lynn/2006j.html#5 virtual memory http://www.garlic.com/~lynn/2006j.html#27 virtual memory http://www.garlic.com/~lynn/2006o.html#27 oops http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF http://www.garlic.com/~lynn/2007e.html#19 Cycles per ASM instruction http://www.garlic.com/~lynn/2007e.html#27 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007e.html#46 FBA rant http://www.garlic.com/~lynn/2007f.html#0 FBA rant http://www.garlic.com/~lynn/2007f.html#6 IBM S/360 series operating systems history http://www.garlic.com/~lynn/2007f.html#33 Historical curiosity question http://www.garlic.com/~lynn/2007f.html#34 Historical curiosity question http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation http://www.garlic.com/~lynn/2007n.html#35 IBM obsoleting mainframe hardware http://www.garlic.com/~lynn/2007o.html#41 Virtual Storage implementation http://www.garlic.com/~lynn/2007p.html#69 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007p.html#70 GETMAIN/FREEMAIN and virtual storage backing up http://www.garlic.com/~lynn/2007p.html#72 A question for the Wheelers - Diagnose instruction http://www.garlic.com/~lynn/2007s.html#2 Real storage usage - a quick question http://www.garlic.com/~lynn/2007s.html#41 Age of IBM VM http://www.garlic.com/~lynn/2007u.html#83 IBM mainframe history, was Floating-point myths http://www.garlic.com/~lynn/2008g.html#45 authoritative IEFBR14 reference http://www.garlic.com/~lynn/2008i.html#68 EXCP access methos http://www.garlic.com/~lynn/2008i.html#69 EXCP access methos http://www.garlic.com/~lynn/2008m.html#7 Future architectures http://www.garlic.com/~lynn/2008o.html#50 Old XDS Sigma stuff http://www.garlic.com/~lynn/2008q.html#31 TOPS-10 http://www.garlic.com/~lynn/2008s.html#56 Computer History Museum http://www.garlic.com/~lynn/2009c.html#59 Why do IBMers think disks are 'Direct Access'? http://www.garlic.com/~lynn/2009h.html#73 Operating Systems for Virtual Machines http://www.garlic.com/~lynn/2009k.html#52 Hercules; more information requested http://www.garlic.com/~lynn/2009n.html#61 Evolution of Floating Point http://www.garlic.com/~lynn/2009r.html#52 360 programs on a z/10 http://www.garlic.com/~lynn/2010.html#42 Happy DEC-10 Day http://www.garlic.com/~lynn/2010d.html#60 LPARs: More or Less? http://www.garlic.com/~lynn/2010f.html#18 What was the historical price of a P/390? http://www.garlic.com/~lynn/2010h.html#21 QUIKCELL Doc http://www.garlic.com/~lynn/2010l.html#45 PROP instead of POPS, PoO, et al http://www.garlic.com/~lynn/2010q.html#9 EXTERNAL: Re: Problem with an edit command in tso http://www.garlic.com/~lynn/2011.html#37 CKD DASD http://www.garlic.com/~lynn/2011.html#79 Speed of Old Hard Disks - adcons http://www.garlic.com/~lynn/2011.html#90 Two terrific writers .. are going to write a book http://www.garlic.com/~lynn/2011d.html#72 Multiple Virtual Memory http://www.garlic.com/~lynn/2011e.html#44 junking CKD; was "Social Security Confronts IT Obsolescence" http://www.garlic.com/~lynn/2011l.html#45 segments and sharing, was 68000 assembly language programming http://www.garlic.com/~lynn/2011m.html#15 Any candidates for best acronyms? http://www.garlic.com/~lynn/2011o.html#92 Question regarding PSW correction after translation exceptions on old IBM hardware http://www.garlic.com/~lynn/2011p.html#115 Start Interpretive Execution http://www.garlic.com/~lynn/2012c.html#17 5 Byte Device Addresses? http://www.garlic.com/~lynn/2012i.html#55 Operating System, what is it? http://www.garlic.com/~lynn/2012l.html#73 PDP-10 system calls, was 1132 printer history http://www.garlic.com/~lynn/2012m.html#2 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee http://www.garlic.com/~lynn/2012n.html#19 How to get a tape's DSCB http://www.garlic.com/~lynn/2012n.html#21 8-bit bytes and byte-addressed machines http://www.garlic.com/~lynn/2012n.html#42 history of Programming language and CPU in relation to each http://www.garlic.com/~lynn/2012o.html#30 Regarding Time Sharing http://www.garlic.com/~lynn/2012p.html#4 Query for IBM Systems Magazine website article on z/OS community http://www.garlic.com/~lynn/2013c.html#48 What Makes an Architecture Bizarre? http://www.garlic.com/~lynn/2013c.html#51 What Makes an Architecture Bizarre? http://www.garlic.com/~lynn/2013c.html#62 What Makes an Architecture Bizarre? http://www.garlic.com/~lynn/2013g.html#85 Old data storage or data base http://www.garlic.com/~lynn/2013h.html#47 Storage paradigm [was: RE: Data volumes] http://www.garlic.com/~lynn/2013h.html#73 Storage paradigm [was: RE: Data volumes] http://www.garlic.com/~lynn/2013i.html#47 Making mainframe technology hip again http://www.garlic.com/~lynn/2013l.html#18 A Brief History of Cloud Computing http://www.garlic.com/~lynn/2013n.html#84 'Free Unix!': The world-changing proclamationmade30yearsagotoday http://www.garlic.com/~lynn/2013o.html#12 "hexadecimal"? http://www.garlic.com/~lynn/2014d.html#54 Difference between MVS and z / OS systems http://www.garlic.com/~lynn/2014d.html#59 Difference between MVS and z / OS systems http://www.garlic.com/~lynn/2015b.html#40 OS/360 -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Alan Bowler <atbowler@thinkage.ca> |
|---|---|
| Date | 2016-01-08 13:12 -0500 |
| Message-ID | <n6ou0r$v7u$1@dont-email.me> |
| In reply to | #152664 |
On 2015-10-10 9:08 PM, Anne & Lynn Wheeler wrote: > Another problem is that channel program use "real addresses" but with > os/360 move to MVS ... the application library building channel programs > is now running in virtual address space and all the resulting channel > programs are built with virtual addresses. Standard OS/360 & MVS > convention passes the address of the channel program in EXCP/SVC0 > supervisor call. With OS/360 move to virtual address, the EXCP process > now has to build a copy of the passed channel program substituting real > addresses for the virtual addresses. This turns out to be the same exact > process that (virtual machine) CP67 had to do for running guest > operating systems in virtual address space. It turns out the person > doing the OS/360 initial prototype move to virtual memory, borrowed the > CP67 "CCWTRANS" routine and crafted into the side of EXCP processing. The Honeywell large systems (Level-66, DPS-8 etc.) solved this problem in a different way. The IO processor (IOM, IOP) had access to the page table, and would do the virtual to real translate itself. This was an obvious follow-on to the original GE-600 systems where user mode address were relocated by a simple base and bound, and IOM would do the same mapping as a CPU. Nevertheless, having user mode programs build channel-programs seems like a poor design choice.
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-01-08 10:34 -0800 |
| Message-ID | <871t9r6hug.fsf@garlic.com> |
| In reply to | #156273 |
Alan Bowler <atbowler@thinkage.ca> writes: > The Honeywell large systems (Level-66, DPS-8 etc.) > solved this problem in a different way. The IO processor (IOM, IOP) > had access to the page table, and would do the virtual to real > translate itself. This was an obvious follow-on to the original > GE-600 systems where user mode address were relocated by a simple > base and bound, and IOM would do the same mapping as a CPU. > > Nevertheless, having user mode programs build channel-programs > seems like a poor design choice. it was a trade-off from the real memory days of os/360 ... before virtual memory ... in much the same way that CKD was also real memory trade-off ... could use the channel to search for a record on disk, rather than needing to have some sort of resident index/table in real memory of locations. a couple POK engineers demonstrated virtual channel ... eliminating the need to build the (shadow) channel programs with real addresses that were the ones that really got executed. http://www.google.com/patents/US3839706 one of the issues was the POK virtual channel just did the address translation assuming available page from the page table entry. There still was the problem of when the virtual page wasn't currently available ... it would require a whole lot of additional effort to make channels handle page fault conditions (and restart the operation when the page was brought in). With-out page fault (& restart) capability in the channel, the channel program would still have to be scanned to "fix" the associated virtual pages for the duration of the I/O. LPARs ... which is the standard way that nearly all IBM mainframes operate with today ... tracing back to adding LPAR support to 3090 in the late 80s ... in response to Amdahl's hypervisor support ... is a subset of virtual machine support ... with translated addresses ... but all the virtual addresses are mapped to real pages (LPARs aren't doing any kind of demand paging, total number of LPAR virtual pages doesn't exceed the number of real pages). -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Alan Bowler <atbowler@thinkage.ca> |
|---|---|
| Date | 2016-01-13 15:39 -0500 |
| Message-ID | <n76ch6$2pd$1@dont-email.me> |
| In reply to | #156275 |
On 2016-01-08 1:34 PM, Anne & Lynn Wheeler wrote: > Alan Bowler <atbowler@thinkage.ca> writes: >> The Honeywell large systems (Level-66, DPS-8 etc.) >> solved this problem in a different way. The IO processor (IOM, IOP) >> had access to the page table, and would do the virtual to real >> translate itself. This was an obvious follow-on to the original >> GE-600 systems where user mode address were relocated by a simple >> base and bound, and IOM would do the same mapping as a CPU. >> >> Nevertheless, having user mode programs build channel-programs >> seems like a poor design choice. > > it was a trade-off from the real memory days of os/360 ... before > virtual memory ... in much the same way that CKD was also real memory > trade-off ... could use the channel to search for a record on disk, > rather than needing to have some sort of resident index/table in real > memory of locations. I still don't see why this required the user program to build the channel program. Having the operating system give map user I/O calls that the OS mapped channel programs as many other operating systems then and now do, does not really cost any more in terms of memory, and makes it much more straight forward to support old programs as new I/O hardware comes along. Making user programs build device specific channel programs has considerable cost in memory of replaced code to build the low level I/O request, and lowered adaptability to newer hardware. The OS/360, DOS/360, TOS/360 were not the only operating systems with this design however. GE/Honeywell's GCOS had (still has) the same idea, it just has I/O hardware that looks after the virtual->real mapping and memory protection. Nevertheless, there is a noticeable cost in memory requirements with every program carrying code to build channel programs. Other operating systems for this hardware
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-01-14 08:03 -0500 |
| Message-ID | <2022900669.474466608.685856.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #156594 |
Alan Bowler <atbowler@thinkage.ca> wrote: > On 2016-01-08 1:34 PM, Anne & Lynn Wheeler wrote: >> Alan Bowler <atbowler@thinkage.ca> writes: >>> The Honeywell large systems (Level-66, DPS-8 etc.) >>> solved this problem in a different way. The IO processor (IOM, IOP) >>> had access to the page table, and would do the virtual to real >>> translate itself. This was an obvious follow-on to the original >>> GE-600 systems where user mode address were relocated by a simple >>> base and bound, and IOM would do the same mapping as a CPU. >>> >>> Nevertheless, having user mode programs build channel-programs >>> seems like a poor design choice. >> >> it was a trade-off from the real memory days of os/360 ... before >> virtual memory ... in much the same way that CKD was also real memory >> trade-off ... could use the channel to search for a record on disk, >> rather than needing to have some sort of resident index/table in real >> memory of locations. > > I still don't see why this required the user program to build the > channel program. Having the operating system give map user I/O > calls that the OS mapped channel programs as many other operating systems > then and now do, does not really cost any more in terms of > memory, and makes it much more straight forward to support old > programs as new I/O hardware comes along. Making > user programs build device specific channel programs has considerable > cost in memory of replaced code to build the low level I/O request, > and lowered adaptability to newer hardware. > > The OS/360, DOS/360, TOS/360 were not the only operating systems > with this design however. GE/Honeywell's GCOS had (still has) > the same idea, it just has I/O hardware that looks after the > virtual->real mapping and memory protection. Nevertheless, > there is a noticeable cost in memory requirements with every > program carrying code to build channel programs. > Other operating systems for this hardware > DOS channel programs weren't built dynamically. They were static parts ofhe DTF. OS programs didn't "carry code to build channel programs", in most cases they were built by OS transients at open. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Alan Bowler <atbowler@thinkage.ca> |
|---|---|
| Date | 2016-01-14 13:10 -0500 |
| Message-ID | <n78o50$q96$1@dont-email.me> |
| In reply to | #156633 |
On 2016-01-14 8:03 AM, Peter Flass wrote:>> > > DOS channel programs weren't built dynamically. They were static parts > ofhe DTF. OS programs didn't "carry code to build channel programs", in > most cases they were built by OS transients at open. They had to have been built dynamically. At compile/link/open times the data addresses and even the length of the I/O request might not be known for all I/O's the program would issue. When the channel program is built by an OS transient, there is no advantage seem to be any advantage to doing it user mode.
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2016-01-14 14:49 -0500 |
| Message-ID | <mdd37u0kklk.fsf@panix5.panix.com> |
| In reply to | #156644 |
Alan Bowler <atbowler@thinkage.ca> writes:
> On 2016-01-14 8:03 AM, Peter Flass wrote:>>
>> DOS channel programs weren't built dynamically. They were static parts
>> ofhe DTF. OS programs didn't "carry code to build channel programs", in
>> most cases they were built by OS transients at open.
> They had to have been built dynamically. At compile/link/open times
> the data addresses and even the length of the I/O request might
> not be known for all I/O's the program would issue.
> When the channel program is built by an OS transient,
> there is no advantage seem to be any advantage to doing it user mode.
You don't seem to know much about I/O on the System/360 family.
In the general case, data was handled in fixed-size records, generally in
blocks of multiple records. (Card images were very common, 80 bytes often
blocked 10 or 20 for a block size of 800 or 1600.) Even when variable size
records were used, memory space was allocated for the maximum possible record
size.
So yes, at compile time, the (maxiumu) lengths of I/O requests were known, and
at run time they were obeyed. The data addresses of buffers were decided at
linkage time, in the user's block of memory. There was more dynamism under
OS/360 than under DOS/360, but not all that much.
The same kind of thing is true in Tops-10 for the PDP-10 family. I/O buffers
are part of the user's address space. TOPS-20, on the other hand, allocates
buffers in the monitor's (= kernel's) address space and moves data into and out
of the user program as needed. This means that certain things can be done in
Tops-10 that are (damned near) impossible in TOPS-20, but that does not make
either one superior, just different.
--
Rich Alderson news@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-01-14 15:00 -0500 |
| Message-ID | <340197800.474494164.947926.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #156654 |
Rich Alderson <news@alderson.users.panix.com> wrote: > Alan Bowler <atbowler@thinkage.ca> writes: > >> On 2016-01-14 8:03 AM, Peter Flass wrote:>> > >>> DOS channel programs weren't built dynamically. They were static parts >>> ofhe DTF. OS programs didn't "carry code to build channel programs", in >>> most cases they were built by OS transients at open. > >> They had to have been built dynamically. At compile/link/open times >> the data addresses and even the length of the I/O request might >> not be known for all I/O's the program would issue. >> When the channel program is built by an OS transient, >> there is no advantage seem to be any advantage to doing it user mode. > > You don't seem to know much about I/O on the System/360 family. > > In the general case, data was handled in fixed-size records, generally in > blocks of multiple records. (Card images were very common, 80 bytes often > blocked 10 or 20 for a block size of 800 or 1600.) Even when variable size > records were used, memory space was allocated for the maximum possible record > size. > > So yes, at compile time, the (maxiumu) lengths of I/O requests were known, and > at run time they were obeyed. The data addresses of buffers were decided at > linkage time, in the user's block of memory. There was more dynamism under > OS/360 than under DOS/360, but not all that much. > > The same kind of thing is true in Tops-10 for the PDP-10 family. I/O buffers > are part of the user's address space. TOPS-20, on the other hand, allocates > buffers in the monitor's (= kernel's) address space and moves data into and out > of the user program as needed. This means that certain things can be done in > Tops-10 that are (damned near) impossible in TOPS-20, but that does not make > either one superior, just different. > Except for the amount of data movement required. I don't think any OS plays games with the memory map, but why not do I/O to buffers in kernel space and then just map them into the user's address space? -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <jmelson@wustl.edu> |
|---|---|
| Date | 2016-01-14 14:28 -0600 |
| Message-ID | <-Z-dnXEorJIhmQXLnZ2dnUU7-QmdnZ2d@giganews.com> |
| In reply to | #156656 |
Peter Flass wrote: > Except for the amount of data movement required. I don't think any OS > plays games with the memory map, but why not do I/O to buffers in kernel > space and then just map them into the user's address space? > Because the 360 (and early 370s without DAT) had very coarse memory protection. The storage protect keys were assigned to 2K byte blocks. Also, they only had 4 bits, and were ORed together to decide if the location was no access, read only or read-write to a particular program. So, you couldn't map a 100 byte record into the user's space without revealing a 2K window. Jon
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-01-14 19:57 -0500 |
| Message-ID | <n79g0o$jop$1@dont-email.me> |
| In reply to | #156658 |
Jon Elson <jmelson@wustl.edu> writes: > Peter Flass wrote: > > >> Except for the amount of data movement required. I don't think any OS >> plays games with the memory map, but why not do I/O to buffers in kernel >> space and then just map them into the user's address space? >> > Because the 360 (and early 370s without DAT) had very coarse memory > protection. The storage protect keys were assigned to 2K byte blocks. > Also, they only had 4 bits, and were ORed together to decide if the location > was no access, read only or read-write to a particular program. So, you > couldn't map a 100 byte record into the user's space without revealing a 2K > window. I don't see a problem with all buffers being a multiple of 4K on current machines. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web