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 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2016-01-14 22:24 -0600 |
| Message-ID | <C7-dnc9dccLC6QXLnZ2dnUU7-f-dnZ2d@giganews.com> |
| In reply to | #156665 |
Dan Espen wrote: > 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. > Well, I thought we were talking about 360 machines, from the late 1960's. Memory was very tight on them. Large machines had 256 - 512 KB or more, lower models could have as little as 16 - 32 KB. With 32 KB of memory, the storage protection keys only defined 16 sections! Way too coarse for an I/O buffer. Jon
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-01-15 14:51 +0000 |
| Message-ID | <PM0005296090C17D7F@aca20255.ipt.aol.com> |
| In reply to | #156656 |
Peter Flass wrote: > 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? Accounting. /BAH
[toc] | [prev] | [next] | [standalone]
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-01-15 16:40 +0100 |
| Message-ID | <uggnmc-uqp.ln1@sambook.reistad.name> |
| In reply to | #156675 |
In article <PM0005296090C17D7F@aca20255.ipt.aol.com>, jmfbahciv <See.above@aol.com> wrote: >Peter Flass wrote: >> 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? > >Accounting. Tops20 can do i/o to user space, in two ways. One with having the pages aligned in memory and disk and setting some bits, and the other in memory mapping the disk. In both cases the i/o is an integral number of pages; and access control is enforced. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2016-01-15 14:18 -0500 |
| Message-ID | <mdd37tyejnp.fsf@panix5.panix.com> |
| In reply to | #156684 |
Morten Reistad <first@last.name.invalid> writes:
> Tops20 can do i/o to user space, in two ways. One with having the pages
> aligned in memory and disk and setting some bits, and the other in memory
> mapping the disk.
> In both cases the i/o is an integral number of pages; and access control
> is enforced.
But the I/O is done in monitor space, with the page maps then being adjusted.
With Tops-10, a user program can manipulate the buffer pointers directly,
adding or dropping buffers as desired, because all of that is in user space.
Not common, but entirely possible.
--
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 | timcaffrey420@gmail.com |
|---|---|
| Date | 2016-01-15 15:57 -0800 |
| Message-ID | <44818166-07b6-43aa-a312-5330c36f722d@googlegroups.com> |
| In reply to | #156699 |
On Friday, January 15, 2016 at 2:18:19 PM UTC-5, Rich Alderson wrote:
> Morten Reistad <first@last.name.invalid> writes:
>
> > Tops20 can do i/o to user space, in two ways. One with having the pages
> > aligned in memory and disk and setting some bits, and the other in memory
> > mapping the disk.
>
> > In both cases the i/o is an integral number of pages; and access control
> > is enforced.
>
> But the I/O is done in monitor space, with the page maps then being adjusted.
>
> With Tops-10, a user program can manipulate the buffer pointers directly,
> adding or dropping buffers as desired, because all of that is in user space.
>
> Not common, but entirely possible.
Well, to bring the discussion back to the subject:
On the CDC machines the I/O was done by the Perpherial Processor (PP). The
user program filled out an I/O request and pointed it at a circular buffer
for the actual I/O data. The I/O request could be issued non-blocking, meaning
that the request got sent to the appropriate PP (via the OS) and control
was returned the user program. It was entirely possible to do file copies
with two PPs doing the I/O through a single circular buffer and the user
program never got involved. Or, in other cases, the CPU could easily process
the data as fast as it came in from the disk and never have to issue another I/O request because the buffer never got full.
Why do this? Well, at the University they charged for CPU time, Memory usage,
and # of PP requests. Shrinking any of those factors could have a dramatic
effect on costs. There was even a Fortran I/O Library to help users do this.
It wasn't real common, but it was used.
- Tim
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0006@eager.cx> |
|---|---|
| Date | 2016-01-15 22:22 +0000 |
| Message-ID | <dft9omFt0s9U10@mid.individual.net> |
| In reply to | #156656 |
On Thu, 14 Jan 2016 15:00:33 -0500, 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? Or map the same page frame to user space and kernel space. I've seen that done. -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-01-18 15:24 +0000 |
| Message-ID | <us7ny.109176$Hz3.75072@fx43.iad> |
| In reply to | #156711 |
Bob Eager <news0006@eager.cx> writes: >On Thu, 14 Jan 2016 15:00:33 -0500, 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? > >Or map the same page frame to user space and kernel space. I've seen that >done. > >-- >Using UNIX since v6 (1975)... Even UNIX v6 had raw (character special) devices where all I/O was done directly to/from a buffer in user space. Certain alignment requirements were enforced. SunOS/SVR4 introduced mmap() which maps a file directly to pages in the user address space.
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0006@eager.cx> |
|---|---|
| Date | 2016-01-18 16:35 +0000 |
| Message-ID | <dg4ijaFtpcfU8@mid.individual.net> |
| In reply to | #156901 |
On Mon, 18 Jan 2016 15:24:10 +0000, Scott Lurndal wrote: > Bob Eager <news0006@eager.cx> writes: >>On Thu, 14 Jan 2016 15:00:33 -0500, 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? >> >>Or map the same page frame to user space and kernel space. I've seen >>that done. >> >>-- >>Using UNIX since v6 (1975)... > > Even UNIX v6 had raw (character special) devices where all I/O was done > directly to/from a buffer in user space. Certain alignment > requirements were enforced. It did indeed. The I/O couldn't span a page boundary. > SunOS/SVR4 introduced mmap() which maps a file directly to pages in the > user address space. Which is of course a MUCH older technique. See Multics and EMAS. (I worked a lot on EMAS) -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-01-18 17:46 +0000 |
| Message-ID | <Cx9ny.150069$LO3.20423@fx15.iad> |
| In reply to | #156910 |
Bob Eager <news0006@eager.cx> writes: >On Mon, 18 Jan 2016 15:24:10 +0000, Scott Lurndal wrote: > >> Bob Eager <news0006@eager.cx> writes: >>>On Thu, 14 Jan 2016 15:00:33 -0500, 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? >>> >>>Or map the same page frame to user space and kernel space. I've seen >>>that done. >>> >>>-- >>>Using UNIX since v6 (1975)... >> >> Even UNIX v6 had raw (character special) devices where all I/O was done >> directly to/from a buffer in user space. Certain alignment >> requirements were enforced. > >It did indeed. The I/O couldn't span a page boundary. And it had to start on a sector boundary as well.
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-01-14 11:13 -0800 |
| Message-ID | <87mvs8gek8.fsf@garlic.com> |
| In reply to | #156633 |
Peter Flass <peter_flass@yahoo.com> writes: > 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. os/360 with minimum real storage design point had 2kbyte transient area ... an open operation might have 6-12 transient routines sequentially executed. A nominally null 3-step job that did little or no execution, just the job scheduler and the open close operations ... could take more than 30secs elapsed time ... where each one of the open/close transient routines loaded sequentially one at a time ... for each file opened and then closed. One of the performance boosts of things like CICS and other monitors would they mostly their own system ... making minimal use of the underlying os/360. they would start, acquire system resources, batch open all needed files, etc ... and then manage all of those resources internally ... scheduling tasks, memory management, etc. CICS task start/stop for transaction was exceedingly "light-weight" since they made minimal use of os/360. past posts mentioning cics http://www.garlic.com/~lynn/submain.html#cics -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-01-08 19:57 +0000 |
| Message-ID | <MwUjy.106370$Xk5.100212@fx17.iad> |
| In reply to | #156273 |
Alan Bowler <atbowler@thinkage.ca> writes: >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. > > The Burroughs medium systems I/O Processor only accepted absolute addresses. The operating system would use the CIO (Convert I/O) instruction to convert the base-relative addresses in the I/O descriptor to absolute addresses and pin the memory region. The SPIO (Start Physical I/O) instruction would convey the I/O Control Block describing the operation to the IOP which would perform the operation. After the operation completes the I/O interrupt handler would use the PIQ (Pop I/O Queue) instruction followed by the IOC (I/O Complete) instruction to 'unpin' the memory region pinned by the CIO instruction (to prevent the operating system from rolling the region out to disk). http://vseries.lurndal.org/doku.php?id=instructions:cio http://vseries.lurndal.org/doku.php?id=instructions:spio http://vseries.lurndal.org/doku.php?id=instructions:piq http://vseries.lurndal.org/doku.php?id=instructions:ioc A suitably privileged application could use the DIRECT I/O API's (Branch Communicate - BCT) to provide I/O descriptors directly, but the MCP would still use the CIO->SPIO->PIQ->IOC sequence on the addresses provided by the application. This was mainly used by diagnostic software.
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0006@eager.cx> |
|---|---|
| Date | 2016-01-08 21:50 +0000 |
| Message-ID | <dfap8qF9q3oU11@mid.individual.net> |
| In reply to | #156273 |
On Fri, 08 Jan 2016 13:12:14 -0500, Alan Bowler wrote: > 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. Presumably the page had to be resident. The same idea was used on the ICL 2900 series. I did a lot of work on a 'home brew' operating system for those machines. -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | Alan Bowler <atbowler@thinkage.ca> |
|---|---|
| Date | 2016-01-14 13:23 -0500 |
| Message-ID | <n78ouf$tb5$1@dont-email.me> |
| In reply to | #156285 |
On 2016-01-08 4:50 PM, Bob Eager wrote: > On Fri, 08 Jan 2016 13:12:14 -0500, Alan Bowler wrote: > >> 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. > > Presumably the page had to be resident. > > The same idea was used on the ICL 2900 series. I did a lot of work on a > 'home brew' operating system for those machines. Yes, it has to be resident on the Honeywell (now Bull/ATOS) systems. The page tables actually have a separate bit indicating that the page is "present" to to IOP. In Gcos8, one of the annoyances of user I/O programming is making a separate calls to mark and unmark the pages involved before/after I/O requests.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2016-01-08 14:27 -0800 |
| Message-ID | <229767fd-8f8f-47b0-a2ce-ab372c9dc0f4@googlegroups.com> |
| In reply to | #156273 |
On Friday, January 8, 2016 at 12:08:04 PM UTC-7, Alan Bowler wrote: > Nevertheless, having user mode programs build channel-programs > seems like a poor design choice. Yes, no, and maybe. It certainly _is_ true that loading programs into channels should require the use of privileged I/O instructions so as to be controlled by the operating system. But _building_ channel programs? I mean, the UNIX operating system was written in C. Does that mean the C compiler has to be made part of the kernel? So what you said _sounded_ like something that didn't make sense, although I'm sure you didn't mean it that way. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2016-01-09 13:31 -0600 |
| Message-ID | <ZPadnVkD-P62_QzLnZ2dnUU7-L-dnZ2d@giganews.com> |
| In reply to | #156287 |
Quadibloc wrote: > On Friday, January 8, 2016 at 12:08:04 PM UTC-7, Alan Bowler wrote: > >> Nevertheless, having user mode programs build channel-programs >> seems like a poor design choice. > > Yes, no, and maybe. > > It certainly _is_ true that loading programs into channels should require > the use of privileged I/O instructions so as to be controlled by the > operating system. > > But _building_ channel programs? > Ok, to explain further, the channel program can be written by the user program, or created by a utility, called an "access method". For security, al channel programs MUST be checked. Even though the old 360 operating system was totally full of security holes big enough for ocean liners to breeze through, OS/360 did require that the execute channel program supervisor check the channel program before execution. The instructions start I/O, halt I/O and test I/O were privileged instructions. On disk, it checked what area of the disk you would read/write to, and what area of memory the transfer would go to/from. For other devices, it would check that you owned that device (comm line, tape drive, etc.) Jon
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-01-09 17:22 -0500 |
| Message-ID | <1808401436.474070429.927238.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #156324 |
Jon Elson <elson@pico-systems.com> wrote: > Quadibloc wrote: > >> On Friday, January 8, 2016 at 12:08:04 PM UTC-7, Alan Bowler wrote: >> >>> Nevertheless, having user mode programs build channel-programs >>> seems like a poor design choice. >> >> Yes, no, and maybe. >> >> It certainly _is_ true that loading programs into channels should require >> the use of privileged I/O instructions so as to be controlled by the >> operating system. >> >> But _building_ channel programs? >> > Ok, to explain further, the channel program can be written by the user > program, or created by a utility, called an "access method". For security, > al channel programs MUST be checked. Even though the old 360 operating > system was totally full of security holes big enough for ocean liners to > breeze through, OS/360 did require that the execute channel program > supervisor check the channel program before execution. The instructions > start I/O, halt I/O and test I/O were privileged instructions. > > On disk, it checked what area of the disk you would read/write to, and what > area of memory the transfer would go to/from. For other devices, it would > check that you owned that device (comm line, tape drive, etc.) > The stuff in OS/360 was there because someone wanted it, or because IBM thought someone would want it. I't's interesting to compare the level of detail with current systems. Of course A) OS/360 didn't have "device drivers", and the access methods performed a lot of the same functions. B) I think a lot of the functionality is still available as IOCTLS on some systems. C) Many types of devices now have standardized interfaces that require less specialized programming - display devices are the big exception, and I don't understand why they haven't been standardized more. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Alan Bowler <atbowler@thinkage.ca> |
|---|---|
| Date | 2016-01-14 13:30 -0500 |
| Message-ID | <n78pbg$uuf$1@dont-email.me> |
| In reply to | #156287 |
On 2016-01-08 5:27 PM, Quadibloc wrote: > On Friday, January 8, 2016 at 12:08:04 PM UTC-7, Alan Bowler wrote: > >> Nevertheless, having user mode programs build channel-programs >> seems like a poor design choice. > > Yes, no, and maybe. > > It certainly _is_ true that loading programs into channels should > require the use of privileged I/O instructions so has to be > controlled by the operating system. > > But _building_ channel programs? > > I mean, the UNIX operating system was written in C. Does that mean the C > compiler has to be made part of the kernel? No, the compiler does not. Note however, that in Unix, the user I/O call is read() or write(), and the OS does the work of building the equivalent of a channel programs.
[toc] | [prev] | [next] | [standalone]
| From | Jon Elson <jmelson@wustl.edu> |
|---|---|
| Date | 2016-01-08 17:01 -0600 |
| Message-ID | <SbGdnW0RWNlWog3LnZ2dnUU7-fWdnZ2d@giganews.com> |
| In reply to | #156273 |
Alan Bowler wrote: > Nevertheless, having user mode programs build channel-programs > seems like a poor design choice. It gave you enormous flexibility to "do it YOUR way". When the 360 was first designed (had to start no later than 1962 or so) programmers were WAY closer to the hardware than in later years. The channel and contol units provided a LOT of fancy funtionality, such as the ability to search disk records for a specific key value located at such and such a position in the data records. Back in the days of punch card accounting machines, this probably looked like a fantastic capability. Of course, once you got into multiprogramming, it became a horrible bottleneck, and database systems were written so that the CPU could decide the exact record to pull off disk, rather than scanning hundreds of tracks for the desired data (while all other programs were frozen out of the disks). Generally, unless you were writing a database program, or some special system utility, a system programmer would NOT actually write a channel program, he'd call an "access method" that would write suitable channel programs to do what you needed. But, if you really needed the channel to do something different than you could get an access method to create, you COULD write your own. We had a tape data recovery program that ran entirely in the channel, and allowed the operator to abort endless retries when a record couldn't be recovered, by flipping sense switches on the tape control unit. It did lock all other users out of the tape system while it was running. But since it was only used to duplicate tapes that were otherwise unrecoverable, it was a great thing to have. Obviously, a totally custom channel program. Jon
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2016-01-09 01:10 +0000 |
| Message-ID | <n6pmlq0cen@news4.newsguy.com> |
| In reply to | #156292 |
On 2016-01-08, Jon Elson <jmelson@wustl.edu> wrote: > But, if you really needed the channel to do something different than you > could get an access method to create, you COULD write your own. We had a > tape data recovery program that ran entirely in the channel, and allowed the > operator to abort endless retries when a record couldn't be recovered, by > flipping sense switches on the tape control unit. It did lock all other > users out of the tape system while it was running. But since it was only > used to duplicate tapes that were otherwise unrecoverable, it was a great > thing to have. Obviously, a totally custom channel program. I had a bit of fun writing channel programs. I cribbed one out of a boot loader and turned it into a program that would find the VTOC, search it for a given file's format 1 label, and read it into memory in a single operation. I also got my hands on a fast disk duplicator, originally written for the Univac 9400, which would copy the equivalent of an IBM 2316 disk pack in 11 minutes. It issued a bunch of multi-track Read R0 commands, whose results it analyzed to determine the exact format of records on one or more tracks. Using this, it built a custom-tailored chain of read count/key/data commands to read the entire track into memory in a single revolution of the disk, regardless of its format. Changing the read commands to writes enabled it to write to the destination disk just as fast. When porting the program to the 9300 (and back to the 9400 afterwards), I read the alternate track tables at the start so it didn't have to check whether a track was replaced by an alternate before copying it (which was wasting a revolution per track). This got the copy time down to 8 minutes - which was a darn sight better than the 60 minutes that the standard Univac-supplied utility took. With a utility that fast, there was no need to not make lots of backups. But people found an excuse not to anyway. -- /~\ 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 | Jon Elson <elson@pico-systems.com> |
|---|---|
| Date | 2016-01-08 22:33 -0600 |
| Message-ID | <cbednewo48MZEA3LnZ2dnUU7-bOdnZ2d@giganews.com> |
| In reply to | #156297 |
Charlie Gibbs wrote: > I also got my hands on a fast disk duplicator, originally written for > the Univac 9400, which would copy the equivalent of an IBM 2316 disk > pack in 11 minutes. It issued a bunch of multi-track Read R0 commands, > whose results it analyzed to determine the exact format of records on > one or more tracks. Using this, it built a custom-tailored chain of > read count/key/data commands to read the entire track into memory in > a single revolution of the disk, regardless of its format. Changing > the read commands to writes enabled it to write to the destination disk > just as fast. When porting the program to the 9300 (and back to the > 9400 afterwards), I read the alternate track tables at the start so it > didn't have to check whether a track was replaced by an alternate before > copying it (which was wasting a revolution per track). This got the copy > time down to 8 minutes - which was a darn sight better than the 60 minutes > that the standard Univac-supplied utility took. > > With a utility that fast, there was no need to not make lots of backups. > But people found an excuse not to anyway. > Back when I worked on a PDP-11, we had some Calcomp 2311-style drives, they held 40 MB. Hmmm, 40 MB will fit on a 1600 BPI mag tape, I thought. Reading some more info, I discovered our tape controller had a "reinstruct window". If you jammed a read or write command into the controller within this time, it would not begin decelerating the tape, but set up different gap timing to account for just rolling through the gap. This made the drive stream! I seem to recall this was 10 us, which was really tight, but an 11/45 could do it with a polling loop. So, I wrote a double-buffered disk - > tape or tape -> disk backup/restore program that could do a whole pack in 10 minutes on a 45 IPS tape drive. It required error-free media, as it as just like dd on Linux, physical block transfer. Of course, the tapes were virtually useless EXCEPT for use with this program, as it was block by block, not file by file. Jon
[toc] | [prev] | [next] | [standalone]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web