Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #236265 > unrolled thread
| Started by | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2026-10-31 21:38 +0000 |
| Last post | 2026-11-02 13:58 +0000 |
| Articles | 20 on this page of 307 — 28 participants |
Back to article view | Back to alt.folklore.computers
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-31 21:38 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-01 04:30 -0500
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-01 10:16 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-01 19:13 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) John Ames <commodorejohn@gmail.com> - 2026-11-02 09:35 -0800
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-02 20:27 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) John Ames <commodorejohn@gmail.com> - 2026-11-02 13:50 -0800
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-02 20:42 -0500
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-03 02:42 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-03 16:38 +0800
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-03 08:40 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-03 07:29 -0700
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-04 02:02 +0800
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-03 19:45 +0100
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-01 18:17 -0500
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-11-01 16:45 -0800
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-01 21:00 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-02 02:16 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-02 04:48 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-02 14:13 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-02 06:47 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-02 20:02 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-02 19:48 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 23:17 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-05 19:37 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-05 21:54 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-06 20:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-06 04:24 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-05 23:31 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Richard Kettlewell <invalid@invalid.invalid> - 2026-11-06 08:46 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-06 07:41 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-06 14:30 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-06 20:53 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-07 06:13 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-07 01:12 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-02 16:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-02 20:10 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-02 03:56 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-02 20:03 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-02 13:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-02 19:56 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-11-04 19:48 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-02 01:28 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-02 09:41 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-02 11:22 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-02 20:11 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-02 13:57 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-03 00:20 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-03 12:45 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Pancho <Pancho.Jones@protonmail.com> - 2026-11-03 11:49 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-03 13:02 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) David Wade <g4ugm@dave.invalid> - 2026-11-03 13:26 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-03 07:35 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-03 18:06 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 21:52 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 07:48 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 21:45 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 21:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-03 14:29 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-03 14:28 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Pancho <Pancho.Jones@protonmail.com> - 2026-11-03 22:15 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-03 22:47 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Pancho <Pancho.Jones@protonmail.com> - 2026-11-03 23:18 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-04 03:12 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Pancho <Pancho.Jones@protonmail.com> - 2026-11-04 08:26 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 01:20 +0000
[OT] Fujitsu Horizon (was: Re: [OT] Mainframes, Dead DEC Punch card times) Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-05 08:19 +0000
Re: [OT] Fujitsu Horizon Pancho <Pancho.Jones@protonmail.com> - 2026-11-05 09:50 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 09:09 -0700
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-04 22:59 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 19:10 -0700
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-03 22:30 -0500
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-04 03:57 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-04 16:57 +0800
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-04 19:51 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-05 04:48 +0800
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-06 06:38 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-05 08:27 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 09:11 -0700
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-06 06:40 +0000
Re: [OT] Mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-04 10:43 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 07:54 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Pancho <Pancho.Jones@protonmail.com> - 2026-11-04 19:59 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 19:04 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 03:34 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-05 06:27 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-05 21:01 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-06 15:45 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-07 11:32 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 20:29 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 07:40 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-04 19:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 19:02 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-05 15:02 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-05 19:18 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-05 21:00 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-05 21:57 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 23:04 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-05 19:15 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-04 03:23 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-04 10:53 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 21:47 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-04 22:22 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-05 21:09 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-05 00:14 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 01:18 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-05 12:27 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-05 21:12 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-05 22:22 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-05 15:59 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-06 06:35 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-06 23:09 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-07 11:45 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-07 07:37 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-07 22:49 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-07 14:54 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-07 13:31 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-08 02:56 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-11-08 21:19 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-07 20:03 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-07 20:56 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-07 21:53 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-08 01:23 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-04 11:25 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-04 19:45 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-05 03:33 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-05 21:05 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-03 00:08 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-02 21:12 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-03 15:13 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-03 20:27 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-03 21:37 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-03 23:01 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 22:18 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-04 11:09 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) David Wade <g4ugm@dave.invalid> - 2026-11-03 22:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 23:02 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-03 22:54 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-03 23:02 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-03 22:58 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lynn Wheeler <lynn@garlic.com> - 2026-11-07 16:04 -1000
NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lars Poulsen <lars@beagle-ears.com> - 2026-11-08 05:59 -0800
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lynn Wheeler <lynn@garlic.com> - 2026-11-08 08:11 -1000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-08 21:31 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lars Poulsen <lars@beagle-ears.com> - 2026-11-08 13:45 -0800
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lynn Wheeler <lynn@garlic.com> - 2026-11-08 12:21 -1000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-08 23:51 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Peter Flass <Peter@Iron-Spring.com> - 2026-11-08 20:33 -0700
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) c186282 <c186282@nnada.net> - 2026-11-08 22:59 -0500
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lynn Wheeler <lynn@garlic.com> - 2026-11-09 07:32 -1000
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) John Levine <johnl@taugh.com> - 2026-11-09 21:20 +0000
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) c186282 <c186282@nnada.net> - 2026-11-09 22:07 -0500
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-11-10 10:37 +0100
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Pancho <Pancho.Jones@protonmail.com> - 2026-11-10 12:22 +0000
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lars Poulsen <lars@beagle-ears.com> - 2026-11-10 06:31 -0800
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) scott@slp53.sl.home (Scott Lurndal) - 2026-11-10 15:14 +0000
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Peter Flass <Peter@Iron-Spring.com> - 2026-11-10 07:35 -0700
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-10 18:36 +0000
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lynn Wheeler <lynn@garlic.com> - 2026-11-10 07:29 -1000
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lynn Wheeler <lynn@garlic.com> - 2026-11-10 07:55 -1000
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Peter Flass <Peter@Iron-Spring.com> - 2026-11-10 12:19 -0700
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Peter Flass <Peter@Iron-Spring.com> - 2026-11-10 12:16 -0700
Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-10 18:36 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-10 07:09 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-10 07:27 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Alexander Schreiber <als@usenet.thangorodrim.de> - 2026-11-10 10:50 +0100
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Peter Flass <Peter@Iron-Spring.com> - 2026-11-10 07:37 -0700
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) scott@slp53.sl.home (Scott Lurndal) - 2026-11-10 15:18 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-10 10:45 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) scott@slp53.sl.home (Scott Lurndal) - 2026-11-10 15:16 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-10 18:36 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-09 04:42 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-09 10:01 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-09 11:08 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) scott@slp53.sl.home (Scott Lurndal) - 2026-11-09 15:59 +0000
Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-09 09:38 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lynn Wheeler <lynn@garlic.com> - 2026-11-08 08:32 -1000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-08 21:32 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lynn Wheeler <lynn@garlic.com> - 2026-11-08 11:55 -1000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-08 21:49 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-04 15:34 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-04 11:08 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 07:36 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-05 00:13 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-05 20:58 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-03 02:42 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 02:49 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-03 02:53 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 04:44 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-03 07:15 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 20:27 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-03 23:41 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-04 10:58 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-04 11:19 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-04 19:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-05 00:19 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 01:24 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-05 15:48 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-05 19:17 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 21:52 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) David Wade <g4ugm@dave.invalid> - 2026-11-03 09:28 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 20:25 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) David Wade <g4ugm@dave.invalid> - 2026-11-03 20:53 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 21:57 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) David Wade <g4ugm@dave.invalid> - 2026-11-03 22:44 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 23:05 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-04 11:27 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 09:20 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 07:52 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 21:50 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Nuno Silva <nunojsilva@invalid.invalid> - 2026-11-05 08:59 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-04 15:36 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-04 02:42 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 07:43 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-04 19:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-03 21:35 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 07:32 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-11-04 11:32 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-04 18:52 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-04 19:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-05 05:02 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lars Poulsen <lars@beagle-ears.com> - 2026-11-05 18:43 -0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-06 06:44 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-11-06 21:29 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-06 04:34 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-06 20:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-11-06 21:31 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-07 01:22 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-07 05:00 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-07 04:12 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-07 05:39 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-07 11:37 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-07 06:25 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-04 22:01 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-02 22:53 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-03 07:15 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-03 19:28 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 22:01 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-03 23:41 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-04 01:13 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-03 12:50 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-03 14:31 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Jeroen Belleman <jeroen@nospam.please> - 2026-11-03 19:16 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-03 07:31 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-04 02:13 +0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lars Poulsen <lars@beagle-ears.com> - 2026-11-03 05:28 -0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 22:00 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-04 15:42 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-04 03:29 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 04:00 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-04 04:05 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-03 23:04 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-03 23:05 -0500
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-04 04:15 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-04 00:14 -0500
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-04 18:24 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-04 06:21 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 07:10 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-04 07:00 -0500
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-04 18:28 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Rich Alderson <news@alderson.users.panix.com> - 2026-11-04 16:50 -0500
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-06 03:02 +0100
Re: [OT] what's a byte, was mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-06 02:44 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-05 19:57 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-05 21:57 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-05 21:57 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-05 16:01 -0700
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-05 23:06 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-06 02:50 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-06 15:25 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Rich Alderson <news@alderson.users.panix.com> - 2026-11-04 16:44 -0500
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-06 17:30 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-07 04:33 +0000
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-07 07:30 -0700
Re: [OT] what's a mini, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-07 19:40 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-03 15:18 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-04 02:59 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-02 22:29 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-04 03:16 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) c186282 <c186282@nnada.net> - 2026-11-03 22:23 -0500
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-04 19:18 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-04 03:17 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-04 02:07 +0000
Re: [OT] highly reliable upgradable mainframes, Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-04 03:06 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 03:54 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-04 15:54 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-04 19:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-11-02 16:51 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-02 11:13 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) rbowman <bowman@montana.com> - 2026-11-02 19:41 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-02 17:01 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) "Carlos E. R." <robin_listas@es.invalid> - 2026-11-03 12:36 +0100
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-03 07:10 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lars Poulsen <lars@beagle-ears.com> - 2026-11-03 05:44 -0800
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-03 07:38 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) antispam@fricas.org (Waldek Hebisch) - 2026-11-03 22:16 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Peter Flass <Peter@Iron-Spring.com> - 2026-11-04 07:58 -0700
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-04 21:44 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Thomas Koenig <tkoenig@netcologne.de> - 2026-11-05 17:13 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-11-03 20:35 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-11-03 21:11 +0000
Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) John Levine <johnl@taugh.com> - 2026-11-04 03:09 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-02 10:52 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) scott@slp53.sl.home (Scott Lurndal) - 2026-11-02 15:35 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-02 10:47 +0000
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-11-02 20:16 +0800
Re: [OT] Punch card times (was Re: Taking Speedy too seriously) The Natural Philosopher <tnp@invalid.invalid> - 2026-11-02 13:58 +0000
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2026-11-07 16:04 -1000 |
| Subject | Re: [OT] Dead DEC Punch card times (was Re: Taking Speedy too seriously) |
| Message-ID | <875wy85ba3.fsf@localhost> |
| In reply to | #236436 |
c186282 <c186282@nnada.net> writes:
> The 'mainframe' era is nearly over - to be replaced
> by cluster/distributed/AI.
>
> However IBM is already into all that, WILL make money.
>
> Many baskets ... How To Survive/Thrive.
>
> Hmmmm ... do remember when IBM was "typewriters" ...
1988, Nick Donofrio approves HA/6000, originally for NYTimes to move
their newspaper system ("ATEX") off DEC VAXCluster to RS/6000 (running
project out at Los Gatos lab). I rename it HA/CMP
https://en.wikipedia.org/wiki/IBM_High_Availability_Cluster_Multiprocessing
when I start doing technical/scientific cluster scale-up with national
labs (LANL, LLNL, NCAR, etc) and commercial cluster scale-up with RDBMS
vendors (Oracle, Sybase, Ingres, Informix) with VAXCluster support in
same source base with UNIX (planning on using Hursley 9333 for mid-range
and full FCS for both technical and commercial scaleup). DB2 was still
all mainframe source, IBM non-mainframe "DB2" had yet to be developed.
IBM S/88 (relogo'ed Stratus) Product Administrator started taking us
around to their customers and also had me write a section for the
corporate continuous availability strategy document (it gets pulled when
both AS400/Rochester and mainframe/POK complain they couldn't meet
requirements). Had coined "disaster survivability" and "geographic
survivability" (as counter to disaster/recovery) when out marketing
HA/CMP.
One of the first HA/CMP customer installs was new Indian Reservation
Casino in Connecticut, was suppose to have week of testing before
opening ... but after 24hrs, they decided to open the doors (based on
projected revenue; at the time was largest in the US, still one of the
largest in the country)
https://en.wikipedia.org/wiki/Foxwoods_Resort_Casino#Debt_default
Early Jan92, there was HA/CMP meeting with Oracle CEO and IBM/AWD
executive Hester tells Ellison that we would have 16-system clusters by
mid92 and 128-system clusters by ye92. Mid-jan92, I update FSD on HA/CMP
work with national labs and FSD decides to go with HA/CMP for federal
supercomputers. By end of Jan, we are told that cluster scale-up is
being transferred to Kingston for announce as IBM Supercomputer (SP,
technical/scientific *ONLY*) and we aren't allowed to work with anything
that has more than four systems (we leave IBM a few months later). A
couple weeks later, 17feb1992, Computerworld news ... IBM establishes
laboratory to develop parallel systems (pg8)
https://archive.org/details/sim_computerworld_1992-02-17_26_7
Some speculation that HA/CMP would have eaten the mainframe in the
commercial market. 1993 industry benchmarks (number of program
iterations compared to the industry MIPS/BIPS reference platform):
ES/9000-982 : 8CPU 408MIPS, (51MIPS/CPU)
RS6000/990 (RIOS chipset) : 1-CPU: 126MIPS
Executive we had reported to, goes over to head up Somerset/AIM (Apple,
IBM, Motorola) to do single chip 801/RISC (Power/PC) and uses Motorola
88k bus/cache enabling SMP implementations.
In the mid-90s, the i86 chip makers then do hardware layer that
translates i86 instructions into RISC micro-ops for actual execution,
largely negating the performance difference with RISC platforms. 1999
industry benchmarks:
IBM PowerPC 440: 1,000MIPS
Intel Pentium3 2,054MIPS
Dec2000 (IBM mainframe) benchmark:
IBM z900 16CPU: 2.5BIPS, 156MIPS/CPU
Also 1988, IBM branch office asked if I could help LLNL (national lab)
standardize some serial stuff they were working with ... which quickly
becomes Fibre Channel Standard ("FCS", including some stuff I had done
in 1980; initially planning on using 1gbit transfer, full-duplex,
aggregate transfer 200mbytes/sec & 64-port non-blocking switches, with
high-end HA/CMP installations). POK mainframe eventually announces its
serial stuff (when it is already obsolete) as "ESCON" (initially
10mbytes/sec). Some POK engineers then become involved with FCS and
define a heavy weight protocol that radically cuts the native
throughput, eventually announced as FICON.
Latest public benchmark I've found is 2010 z196 "Peak I/O" getting 2M
IOPS using 104 FICON (20K IOPS/FICON). About the same time a native FCS
is announced for E5-2600 server blades getting over million IOPS (two
such FCS higher throughput than 104 FICON running over FCS). Note IBM
docs has SAPs (system assist processors that do actual I/O) CPU be kept
to 70% ... or 1.5M IOPS ... also no CKD DASD have been made for decades
(just simulated with industry standard fixed-block devices).
This "Evolution of the System z Channel" (SHARE 2011 presentation at
wayback machine)
https://web.archive.org/web/20170829213251/https://share.confex.com/share/117/webprogram/Handout/Session9931/9934pdhj%20v0.pdf
talks about after 2010 z196 "Peak I/O" benchmark and "zHPF" that
increased throughput from 20K IOPS/FICON to 52K IOPS/FICON then to 92K
IOPS/FICON (aka from 1/50th to almost 1/10th the native FCS announced in
2010).
--
virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Lars Poulsen <lars@beagle-ears.com> |
|---|---|
| Date | 2026-11-08 05:59 -0800 |
| Subject | NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <11cpv8t$c3gs$1@dont-email.me> |
| In reply to | #236662 |
On 11/7/2026 18:04, Lynn Wheeler wrote:
> 1988, Nick Donofrio approves HA/6000, originally for NYTimes to move
> their newspaper system ("ATEX") off DEC VAXCluster to RS/6000 (running
> project out at Los Gatos lab). I rename it HA/CMP
> https://en.wikipedia.org/wiki/IBM_High_Availability_Cluster_Multiprocessing
> when I start doing technical/scientific cluster scale-up with national
> labs (LANL, LLNL, NCAR, etc) and commercial cluster scale-up with RDBMS
> vendors (Oracle, Sybase, Ingres, Informix) with VAXCluster support in
> same source base with UNIX (planning on using Hursley 9333 for mid-range
> and full FCS for both technical and commercial scaleup). DB2 was still
> all mainframe source, IBM non-mainframe "DB2" had yet to be developed.
Around 2001, my group had developed a T1-over-UDP-over-Ethernet bridge
to use in tandem with our wireless ethernet bridge product. After we
spun out from WiLan, and became Afar, we also marketed it separately.
Our largest sale was to NYT, to replace the dual T1 lines they had to
their (16?) regional printing plants, connected to the phototypesetters
in the print shops. At 42nd street they had a rack with 60(?) of our
boxes. While they wanted the two lines for each remote site to be on
separate boxes connected to separate IP networks, two lines to different
sites could share one of our units, which had two T1 jacks.
System worked well; I once got to visit the Old Lady shortly before they
moved down the street.
> IBM S/88 (relogo'ed Stratus) Product Administrator started taking us
> around to their customers and also had me write a section for the
> corporate continuous availability strategy document (it gets pulled when
> both AS400/Rochester and mainframe/POK complain they couldn't meet
> requirements). Had coined "disaster survivability" and "geographic
> survivability" (as counter to disaster/recovery) when out marketing
> HA/CMP.
I was curious about S/88, which I did not know about before. CoPilot
pulled together a nice synopsis, from which I learned that Stratus and
Tandem both had figured out how to do rolling upgrades in a non-stop
environment; I had thought that was an IBM mainframe invention.
I also learned that both Stratus and Tandem survive to this day, in a
fashion:
Tandem-> Compaq-> HP - is now HPE Non-Stop
Stratus-> Ascend-> Lucent -> spin-out Stratus Tech
building HA systems on Xeon processors.
Now called Penguin Solutions.
Many techies despise System/Z as an overpriced dinosaur with an
obsolete architechture. But I wonder if it is any less expensive to dip
the Intel processors in that magic sauce. I bet IBM has better scale to
their builds.
--
Lars Poulsen - an old geek in Santa Barbara, California
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2026-11-08 08:11 -1000 |
| Subject | Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <87se1bp50v.fsf@localhost> |
| In reply to | #236665 |
Lars Poulsen <lars@beagle-ears.com> writes: > Around 2001, my group had developed a T1-over-UDP-over-Ethernet bridge > to use in tandem with our wireless ethernet bridge product. After we > spun out from WiLan, and became Afar, we also marketed it > separately. Our largest sale was to NYT, to replace the dual T1 lines > they had to their (16?) regional printing plants, connected to the > phototypesetters in the print shops. At 42nd street they had a rack > with 60(?) of our boxes. While they wanted the two lines for each > remote site to be on separate boxes connected to separate IP networks, > two lines to different sites could share one of our units, which had > two T1 jacks. > > System worked well; I once got to visit the Old Lady shortly before > they moved down the street. early 80s, I got HSDT project, T1 and faster computer links (both terrestrial and satellite) and battles with SNA group (60s, IBM had 2701 supporting T1, 70s with SNA/VTAM and issues, links were capped at 56kbit ... and I had to mostly resort to non-IBM hardware). Mid-80s, communication group was also fighting off release of mainframe TCP/IP support and when that failed, they said that since they had corporate responsibility for everything that crossed datacenter walls, it had to be release through them. I then add RFC1044 and in some tuning tests at Cray Research between a Cray and 4341, got sustained 4341 channel throughput using only modest amount of 4341 CPU (something like 500 times improvement in bytes moved per instruction executed). HSDT also was working with NSF director and was suppose to get $20M to interconnect the NSF Supercomputer centers. NSF gave grant to Univ. Cal to build Berkeley supercomputer center and I was asked to give them talks on the interconnect. Turns out regents had san diego getting the next new bldg ... and it became the San Diego Supercomputer center instead. Then congress cuts the budget, some other things happened and eventually there was RFP released (in part based on what we already had running). NSF 28Mar1986 Preliminary Announcement: https://web.archive.org/web/20260311074443/https://www.garlic.com/~lynn/2002k.html#12 The OASC has initiated three programs: The Supercomputer Centers Program to provide Supercomputer cycles; the New Technologies Program to foster new supercomputer software and hardware developments; and the Networking Program to build a National Supercomputer Access Network - NSFnet. IBM internal politics was not allowing us to bid. The NSF director tried to help by writing the company a letter (3Apr1986, NSF Director to IBM Chief Scientist and IBM Senior VP and director of Research, copying IBM CEO) with support from other gov. agencies ... but that just made the internal politics worse (as did claims that what we already had operational was at least 5yrs ahead of the winning bid), as regional networks connect in, NSFnet becomes the NSFNET backbone, precursor to modern internet ... aka NCSA ... grant for new "supercomputer software" https://www.ncsa.illinois.edu/ -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-11-08 21:31 +0000 |
| Subject | Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <11cqpn5$nfgo$2@dont-email.me> |
| In reply to | #236665 |
On Sun, 8 Nov 2026 05:59:55 -0800, Lars Poulsen wrote: > ... from which I learned that Stratus and Tandem both had figured > out how to do rolling upgrades in a non-stop environment; I had > thought that was an IBM mainframe invention. The IBM mega-marketing machine strikes again. Or past tense, really; IBM no longer has that power. Microsoft inherited that mantle, but it, too, is losing its grip. > Many techies despise System/Z as an overpriced dinosaur with an > obsolete architechture. But I wonder if it is any less expensive to > dip the Intel processors in that magic sauce. I bet IBM has better > scale to their builds. There was a paper on how Google did it, published 10 or 20 years ago. At that point, they had a total complement of about 460,000 x86 servers. They would buy the cheapest component they could for every component but one: the power supply. With that kind of scale, who cares if 100 or 1000 machines are broken at any moment? The users certainly won’t notice. Mainframes stopped being relevant back in the 1980s; every further development since then has just been driven by customer inertia.
[toc] | [prev] | [next] | [standalone]
| From | Lars Poulsen <lars@beagle-ears.com> |
|---|---|
| Date | 2026-11-08 13:45 -0800 |
| Subject | Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <11cqqh2$ntcu$1@dont-email.me> |
| In reply to | #236671 |
On 11/8/2026 13:31, Lawrence D’Oliveiro wrote: > There was a paper on how Google did it, published 10 or 20 years ago. > At that point, they had a total complement of about 460,000 x86 > servers. They would buy the cheapest component they could for every > component but one: the power supply. > > With that kind of scale, who cares if 100 or 1000 machines are broken > at any moment? The users certainly won’t notice. The parallelism of a Google is a very different beast from the robust parallelism of a banking mainframe. Google needs a way to route an incoming connection to a random running server instance. It does not matter which one, and if the one that was picked has died, the first packet retry will get to a better one. That is very different from transactions that must execute exactly once. > Mainframes stopped being relevant back in the 1980s; every further > development since then has just been driven by customer inertia. If we define mainframes a large, very robust systems, they are still very relevant. Although it may be true that the major technology was in place before 1990 (non-stop cluster systems, transaction locking with completion/rollback and strategic redundancy). What you call customer inertia is also known as vendor lock-in. -- Lars Poulsen - an old geek in Santa Barbara, California
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2026-11-08 12:21 -1000 |
| Subject | Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <87ik27arr6.fsf@localhost> |
| In reply to | #236673 |
Lars Poulsen <lars@beagle-ears.com> writes:
> If we define mainframes a large, very robust systems, they are still
> very relevant. Although it may be true that the major technology was
> in place before 1990 (non-stop cluster systems, transaction locking
> with completion/rollback and strategic redundancy). What you call
> customer inertia is also known as vendor lock-in.
trivia, after early 70s "Future System"
http://www.jfsowa.com/computer/memo125.htm
https://en.wikipedia.org/wiki/IBM_Future_Systems_project
https://people.computing.clemson.edu/~mark/fs.html
imploded, head of POK was convincing corporate to kill the VM370
product, shutdown the development group and transfer all the people to
POK for MVS/XA. Endicott eventually acquires VM370 responsibility (for
the mid-range), but has to recreate a development group from scratch. I
get asked to help with a 16-CPU 370 and we con the 3033 processor
engineers into helping in their spare time (a lot more interesting that
remapping 168 logic to 20% faster chips). Everybody thought it was great
until somebody tells the head of POK that it could be decades POK's
favorite son operating system ("MVS") had effective 16-CPU (MVS
documents were claiming that MVS 2-CPU support only had 1.2-1.5 times
the throughput of single CPU, because of high multiprocessor support
overhead, POK doesn't ship a 16-CPU system until after the turn of the
century). Head of POK then invites some of us to never visit POK again
and directs the 3033 processor engineers, "heads down and no
distractions".
About the same time, Endicott talks me into helping with ECPS for the
138/148 (also used with 4331/4341), identify highest executed 6kbytes of
VM370 kernel execution for re-implementing directly in machine microcode
(at 10:1 performance increase, mid-range 370s were avg. 10 native
instructions for every 370 instruction). Archived post with initial
analysis, 6kbytes accounted for 79.55% of kernel execution:
https://web.archive.org/web/20260416141952/https://www.garlic.com/~lynn/94.html#21
After being invited to never visit POK again, I transfer out to IBM San
Jose Research on the west coast and worked with Jim Gray and Vera Watson
on the original SQL/relational RDBMS, System/R. After Jim Gray left IBM
SJR for Tandem (fall1980), he did studies of system availability and
outages. He was finding that hardware was becoming much more reliable
and outages were shifting to environmental (floods, earthquakes, storms,
etc) and people mistakes, needing redundant systems at geographically
separated distances.
https://courses.cs.duke.edu/spring11/cps210/papers/Gray_computers_stop.pdf
https://web.archive.org/web/20260219063547/https://www.garlic.com/~lynn/grayft84.pdf
As Jim was leaving, he was foisting off stuff on me including BofA;
Research had System/R joint study with BofA and they ordered 60 VM4341s
for System/R. Some amount of resistance from STL, IMS and next great
DBMS "EAGLE". Was able to do tech transfer to Endicott (under the radar
while company was pre-occupied with "EAGLE") for SQL/DS. Then when
"EAGLE" implodes there was request how fast could System/R be ported to
MVS, eventually released as "DB2" (originally for decision support
only).
Also when 1st transfer to west coast, I got to wander around silicon
valley datacenters (and consolidated HONE was just up the road),
including disk bldg14/engineering and bldg15/product test across the
street. They had been doing 7/24, prescheduled stand-alone testing and
mentioned that recently they had tried MVS, but it had 15min MTBF (in
that environment, requiring manual re-ipl). I offer to rewrite I/O
Supervisor, making it bullet proof and never fail allowing any amount of
ondemand, concurrent testing (greatly improving productivity). I then do
an internal research report "I/O Reliability Enhancement" and happen to
mention MVS 15min MTBF, bringing down the wrath of the MVS organization
on my head.
Bldg15 gets the 1st engineering 3033 outside POK 3033 processor
engineering (trivia: after 3033s started shipping, 3033 processor
engineers start on trout/3090). Testing was only percent or two of CPU,
so we scrounge up a 3830 controller and 3330 string and setup our own
private online service. Summer 1978, bldg15 also gets engineering
E5/4341 (year before 1st customer ship). Jan1979, branch office hears
about it and cons me into doing (CDC6600 Fortran) benchmark for national
lab that was looking at getting 70 VM4341s for compute farm (sort of
leading edge of the coming cluster supercomputer tsunami). Spring 1979,
some USAFDC (in the Pentagon) wanted to come by to talk to me about 20
VM4341 systems, visit kept being delayed, by the time they came by (six
months later), it had grown from 20 to 210. Also saw large corporations
ordering hundreds of VM4341s at a time for installing out in
departmental areas (sort of the leading edge of the coming distributed
computing tsunami). VM4341s also contributed to HONE system popping up
all over the world (and inside IBM, departmental conference rooms
becomes scarce, so many converted to VM4341 rooms).
--
virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-11-08 23:51 +0000 |
| Subject | Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <11cr1ub$q796$1@dont-email.me> |
| In reply to | #236673 |
On Sun, 8 Nov 2026 13:45:03 -0800, Lars Poulsen wrote: > On 11/8/2026 13:31, Lawrence D’Oliveiro wrote: >> >> There was a paper on how Google did it, published 10 or 20 years >> ago. At that point, they had a total complement of about 460,000 >> x86 servers. They would buy the cheapest component they could for >> every component but one: the power supply. >> >> With that kind of scale, who cares if 100 or 1000 machines are >> broken at any moment? The users certainly won’t notice. > > The parallelism of a Google is a very different beast from the > robust parallelism of a banking mainframe. Mainframes have never been that “robust”. You’ve mentioned elsewhere learning about Stratus and Tandem, who took robustness to a new level back in the 1980s, beyond anything the mainframe world could match. Think of that kind of redundancy multiplied tenfold, a hundredfold, a thousandfold, all built on open-source technologies: that’s the kind of world we live in today. > That is very different from transactions that must execute exactly > once. That technology is pretty commonplace nowadays <https://kafka.apache.org/44/getting-started/introduction/>. >> Mainframes stopped being relevant back in the 1980s; every further >> development since then has just been driven by customer inertia. > > If we define mainframes a large, very robust systems, they are still > very relevant. That’s kind of a circular definition though, isn’t it. I’ll stick with the traditional definition: one which maximized I/O bandwidth over minimizing latency, batch operation efficiency over interactive responsiveness. That was very much IBM’s core business, and the obsolescence of that market directly correlates with IBM dwindling to a shadow of its former self.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-11-08 20:33 -0700 |
| Subject | Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <11creup$trgi$1@dont-email.me> |
| In reply to | #236676 |
On 11/8/26 16:51, Lawrence D’Oliveiro wrote: > On Sun, 8 Nov 2026 13:45:03 -0800, Lars Poulsen wrote: > >> On 11/8/2026 13:31, Lawrence D’Oliveiro wrote: >>> >>> There was a paper on how Google did it, published 10 or 20 years >>> ago. At that point, they had a total complement of about 460,000 >>> x86 servers. They would buy the cheapest component they could for >>> every component but one: the power supply. >>> >>> With that kind of scale, who cares if 100 or 1000 machines are >>> broken at any moment? The users certainly won’t notice. >> >> The parallelism of a Google is a very different beast from the >> robust parallelism of a banking mainframe. > > Mainframes have never been that “robust”. You’ve mentioned elsewhere > learning about Stratus and Tandem, who took robustness to a new level > back in the 1980s, beyond anything the mainframe world could match. > Think of that kind of redundancy multiplied tenfold, a hundredfold, a > thousandfold, all built on open-source technologies: that’s the kind > of world we live in today. > Mainframes typically achieve an uptime percentage between 99.999% (five nines) and 99.9999999% (nine nines)
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-11-08 22:59 -0500 |
| Subject | Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <mdednVFy4dK82Gz3nZ2dnZfqnPidnZ2d@giganews.com> |
| In reply to | #236682 |
On 11/8/26 22:33, Peter Flass wrote: > On 11/8/26 16:51, Lawrence D’Oliveiro wrote: >> On Sun, 8 Nov 2026 13:45:03 -0800, Lars Poulsen wrote: >> >>> On 11/8/2026 13:31, Lawrence D’Oliveiro wrote: >>>> >>>> There was a paper on how Google did it, published 10 or 20 years >>>> ago. At that point, they had a total complement of about 460,000 >>>> x86 servers. They would buy the cheapest component they could for >>>> every component but one: the power supply. >>>> >>>> With that kind of scale, who cares if 100 or 1000 machines are >>>> broken at any moment? The users certainly won’t notice. >>> >>> The parallelism of a Google is a very different beast from the >>> robust parallelism of a banking mainframe. >> >> Mainframes have never been that “robust”. You’ve mentioned elsewhere >> learning about Stratus and Tandem, who took robustness to a new level >> back in the 1980s, beyond anything the mainframe world could match. >> Think of that kind of redundancy multiplied tenfold, a hundredfold, a >> thousandfold, all built on open-source technologies: that’s the kind >> of world we live in today. >> > > Mainframes typically achieve an uptime percentage between 99.999% (five > nines) and 99.9999999% (nine nines) They ARE very very very good ! Noted in this group though - I/O arch diffs between mainframes and minis. Will someone try to elaborate ? Started off on a "mini" - PDP-11 - with a PDP-8 kinda in the background (but wasn't really allowed to use it for anything). This I/O diff, didn't NOTICE it, but was likely there. Long-after insights would be interesting.
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2026-11-09 07:32 -1000 |
| Subject | Re: NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <87y0b1oqqu.fsf@localhost> |
| In reply to | #236684 |
c186282 <c186282@nnada.net> writes:
> Noted in this group though - I/O arch diffs between
> mainframes and minis.
previously posted, 1988, ibm branch office asked me if I could help LLNL
with standardization of some serial stuff they had been working with,
which quickly becomes fibre-channel standard ("FCS", including some
stuff I had done in the 80s, initially 1gbit transfer, full-duplex,
aggregate 200mbytes/sec).
https://en.wikipedia.org/wiki/Fibre_Channel
then IBM releases some serial stuff they had been working with for
nearly a decade (when it is already obsolete) as ESCON (initially
10mbytes/sec). Then some IBM engineers get involved with FCS and define
a heavy-weight protocol that radically reduced native throughput
https://en.wikipedia.org/wiki/FICON
Latest public benchmark I've found is 2010 z196 "Peak I/O" getting 2M
IOPS using 104 FICON (20K IOPS/FICON). About the same time a native FCS
is announced for E5-2600 server blades getting over million IOPS (two
such FCS higher throughput than 104 FICON running over FCS). Note IBM
docs has SAPs (system assist processors that now do the actual I/O) CPU
be kept to 70% ... or 1.5M IOPS ... also no CKD DASD have been made for
decades (just simulated with industry standard fixed-block devices).
This "Evolution of the System z Channel" (SHARE 2011 presentation at
wayback machine)
https://web.archive.org/web/20170829213251/https://share.confex.com/share/117/webprogram/Handout/Session9931/9934pdhj%20v0.pdf
talks about after 2010 z196 "Peak I/O" benchmark and "zHPF" that
increased throughput from 20K IOPS/FICON to 52K IOPS/FICON then to 92K
IOPS/FICON (aka from 1/50th to almost 1/10th the native FCS announced in
2010).
--
virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-11-09 21:20 +0000 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <11ctde2$2ibp$1@gal.iecc.com> |
| In reply to | #236684 |
According to c186282 <c186282@nnada.net>: > Noted in this group though - I/O arch diffs between > mainframes and minis. > > Will someone try to elaborate ? The classic difference is that mainframes have channels, so the processor sets up a bunch of work for the channel to do, the channel goes off and does it independently of the CPU. Minis had much less complex I/O controllers so they do more detailed stuff. An example I gave a few messages back was for a card reader. A mainframe starts a channel program, it reads in a card or maybe seveal cards, and reports back with an interrupt. On a mini there was an I/O operation to start the card reader, an interrupt for each column and an I/O to read it, and then something at the end to stop the reader or go to the next card. But that was 40 or 50 years ago. These days even cheap generic disk controllers do more than channels did in the 1960s, e.g., keep a queue of requests and schedule them to minimize delay, and handle spare block replacement for bad blocks. Modern mainframes have extremely capable channels but the distinction is more about reliability and things like hardware and software upgrades in place without rebooting. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2026-11-09 22:07 -0500 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <5O-dnQvUAMIEF2_3nZ2dnZfqn_SdnZ2d@giganews.com> |
| In reply to | #236701 |
On 11/9/26 16:20, John Levine wrote: > According to c186282 <c186282@nnada.net>: >> Noted in this group though - I/O arch diffs between >> mainframes and minis. >> >> Will someone try to elaborate ? > > The classic difference is that mainframes have channels, so the > processor sets up a bunch of work for the channel to do, the channel > goes off and does it independently of the CPU. Minis had much less > complex I/O controllers so they do more detailed stuff. An example I > gave a few messages back was for a card reader. A mainframe starts a > channel program, it reads in a card or maybe seveal cards, and reports > back with an interrupt. On a mini there was an I/O operation to start > the card reader, an interrupt for each column and an I/O to read it, > and then something at the end to stop the reader or go to the next > card. > > But that was 40 or 50 years ago. These days even cheap generic disk > controllers do more than channels did in the 1960s, e.g., keep a queue > of requests and schedule them to minimize delay, and handle spare block > replacement for bad blocks. > > Modern mainframes have extremely capable channels but the distinction is > more about reliability and things like hardware and software upgrades in > place without rebooting. Ok ... so 'mainframes' as you saw them were more 'directors' for distributed processing rather than THE processor.
[toc] | [prev] | [next] | [standalone]
| From | Alexander Schreiber <als@usenet.thangorodrim.de> |
|---|---|
| Date | 2026-11-10 10:37 +0100 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <slrn11f5pfd.2l8ql.als@mordor.angband.thangorodrim.de> |
| In reply to | #236710 |
c186282 <c186282@nnada.net> wrote:
> On 11/9/26 16:20, John Levine wrote:
>> According to c186282 <c186282@nnada.net>:
>>> Noted in this group though - I/O arch diffs between
>>> mainframes and minis.
>>>
>>> Will someone try to elaborate ?
>>
>> The classic difference is that mainframes have channels, so the
>> processor sets up a bunch of work for the channel to do, the channel
>> goes off and does it independently of the CPU. Minis had much less
>> complex I/O controllers so they do more detailed stuff. An example I
>> gave a few messages back was for a card reader. A mainframe starts a
>> channel program, it reads in a card or maybe seveal cards, and reports
>> back with an interrupt. On a mini there was an I/O operation to start
>> the card reader, an interrupt for each column and an I/O to read it,
>> and then something at the end to stop the reader or go to the next
>> card.
>>
>> But that was 40 or 50 years ago. These days even cheap generic disk
>> controllers do more than channels did in the 1960s, e.g., keep a queue
>> of requests and schedule them to minimize delay, and handle spare block
>> replacement for bad blocks.
>>
>> Modern mainframes have extremely capable channels but the distinction is
>> more about reliability and things like hardware and software upgrades in
>> place without rebooting.
>
> Ok ... so 'mainframes' as you saw them were more
> 'directors' for distributed processing rather
> than THE processor.
No. The operating system and application software ran on the mainframe
CPU. But - as described above - a key design aspect of mainframes back
then was that I/O was not done by the CPU (like it was done on home
computers were all I/O was entirely handled by the CPU), but fully off-
loaded to peripherials that were essentially limited computers of their
own:
- CPU tells I/O interface (channel): "Do this I/O"
- CPU goes back to computing, channel does some I/O heavy lifting
- channel has completed I/O and sends an "Hey, I'm done" interrupt
to the CPU
Which leaves most of the CPU free to do compute work instead of busily
doing lots of I/O. This and other design concepts (like form based
terminals doing local editing - think web forms filled in the browser, send
as a whole form and processed as a single request by the server, instead
of the server handling every keystroke on the terminal) enabled having
thousands of interactive users on one mainframe, since the mainframe CPU
did almost entirely compute (e.g. run the database and software for
inventory, accounting, ...) and all I/O was offloaded to specialized
computers (channels) acting as I/O interfaces. You essentially pay with
extra complexity for a far more capable system.
Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
[toc] | [prev] | [next] | [standalone]
| From | Pancho <Pancho.Jones@protonmail.com> |
|---|---|
| Date | 2026-11-10 12:22 +0000 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <11cv29t$5s59$1@dont-email.me> |
| In reply to | #236717 |
On 11/10/26 09:37, Alexander Schreiber wrote: > No. The operating system and application software ran on the mainframe > CPU. But - as described above - a key design aspect of mainframes back > then was that I/O was not done by the CPU (like it was done on home > computers were all I/O was entirely handled by the CPU), but fully off- > loaded to peripherials that were essentially limited computers of their "Fully offloaded" is a bit weasel worded. I thought PCs did offload some duties to io devices, nic chip, wifi chip, gpu card. sound card. Also, even a mainframe will need service routines to handle communications with IO devices. Where to draw the line seems unclear. Caveat: I don't have a clue about these things, it is just that what you are saying doesn't sound quite right.
[toc] | [prev] | [next] | [standalone]
| From | Lars Poulsen <lars@beagle-ears.com> |
|---|---|
| Date | 2026-11-10 06:31 -0800 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <11cv9rp$27fcf$1@dont-email.me> |
| In reply to | #236719 |
On 11/10/2026 04:22, Pancho wrote: > On 11/10/26 09:37, Alexander Schreiber wrote: > >> No. The operating system and application software ran on the mainframe >> CPU. But - as described above - a key design aspect of mainframes back >> then was that I/O was not done by the CPU (like it was done on home >> computers were all I/O was entirely handled by the CPU), but fully off- >> loaded to peripherials that were essentially limited computers of their > > "Fully offloaded" is a bit weasel worded. I thought PCs did offload some > duties to io devices, nic chip, wifi chip, gpu card. sound card. Also, > even a mainframe will need service routines to handle communications > with IO devices. Where to draw the line seems unclear. > > Caveat: I don't have a clue about these things, it is just that what you > are saying doesn't sound quite right. The examples you give are all current. "Intelligent"peripherals that contain their own processors, and communicate with the CPU via "mailboxes", ... yes, similarly to how the mainframe I/O channels did in the 1960s. The shift reflects that fact that SMALL processors have become throwaway cheap. And the difference between a desktop and a mainframe nowadays is not in what instruction set architecture the application programmer sees in user mode, but what I/O fabric is behind and underneath that. -- Lars Poulsen - an old geek in Santa Barbara, California
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-11-10 15:14 +0000 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <QxGIS.9171$S23.6555@fx04.iad> |
| In reply to | #236719 |
Pancho <Pancho.Jones@protonmail.com> writes: >On 11/10/26 09:37, Alexander Schreiber wrote: > >> No. The operating system and application software ran on the mainframe >> CPU. But - as described above - a key design aspect of mainframes back >> then was that I/O was not done by the CPU (like it was done on home >> computers were all I/O was entirely handled by the CPU), but fully off- >> loaded to peripherials that were essentially limited computers of their > >"Fully offloaded" is a bit weasel worded. I thought PCs did offload some >duties to io devices, nic chip, wifi chip, gpu card. sound card. Also, >even a mainframe will need service routines to handle communications >with IO devices. Where to draw the line seems unclear. Fully offloaded is accurate. For the Burroughs mainframes, a single instruction -initiated- an I/O request to a channel. The IIO (later SPIO) instruction would instruct the I/O processor (in the late 70s the IOP used an 8085 uProcessor) to initiate an I/O by passing a 6-digit (24-bit) opcode/variant word and the start and end addresses of the buffer. The IOP would pass the command to a Data-Link Processor (DLP) that handled communications to the device controller (magnetic tape, disk) or unit record device (printer, card reader, card punch) or external communications processor (RS232/20ma current loop) and wait for the controller to start passing data back to the IOP. The IOP would move the data to the appropriate memory buffer and, when complete, signal the processor that the I/O had completed with an interrupt. > >Caveat: I don't have a clue about these things, it is just that what you >are saying doesn't sound quite right.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-11-10 07:35 -0700 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <11cva4h$27ikm$1@dont-email.me> |
| In reply to | #236717 |
On 11/10/26 02:37, Alexander Schreiber wrote: > c186282 <c186282@nnada.net> wrote: >> On 11/9/26 16:20, John Levine wrote: >>> According to c186282 <c186282@nnada.net>: >>>> Noted in this group though - I/O arch diffs between >>>> mainframes and minis. >>>> >>>> Will someone try to elaborate ? >>> >>> The classic difference is that mainframes have channels, so the >>> processor sets up a bunch of work for the channel to do, the channel >>> goes off and does it independently of the CPU. Minis had much less >>> complex I/O controllers so they do more detailed stuff. An example I >>> gave a few messages back was for a card reader. A mainframe starts a >>> channel program, it reads in a card or maybe seveal cards, and reports >>> back with an interrupt. On a mini there was an I/O operation to start >>> the card reader, an interrupt for each column and an I/O to read it, >>> and then something at the end to stop the reader or go to the next >>> card. >>> >>> But that was 40 or 50 years ago. These days even cheap generic disk >>> controllers do more than channels did in the 1960s, e.g., keep a queue >>> of requests and schedule them to minimize delay, and handle spare block >>> replacement for bad blocks. >>> >>> Modern mainframes have extremely capable channels but the distinction is >>> more about reliability and things like hardware and software upgrades in >>> place without rebooting. >> >> Ok ... so 'mainframes' as you saw them were more >> 'directors' for distributed processing rather >> than THE processor. > > No. The operating system and application software ran on the mainframe > CPU. But - as described above - a key design aspect of mainframes back > then was that I/O was not done by the CPU (like it was done on home > computers were all I/O was entirely handled by the CPU), but fully off- > loaded to peripherials that were essentially limited computers of their > own: > - CPU tells I/O interface (channel): "Do this I/O" > - CPU goes back to computing, channel does some I/O heavy lifting > - channel has completed I/O and sends an "Hey, I'm done" interrupt > to the CPU > A prime example of neat code is that HASP (now JES) printed an entire page with one channel program instead of a line at a time. It also read a number of cards with one channel program instead of one card at a time, or, as someone has mentioned, one card column at a time.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-11-10 18:36 +0000 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <5vJIS.76787$i43.66245@fx21.iad> |
| In reply to | #236723 |
On 2026-11-10, Peter Flass <Peter@Iron-Spring.com> wrote: > A prime example of neat code is that HASP (now JES) printed an entire > page with one channel program instead of a line at a time. It also read > a number of cards with one channel program instead of one card at a > time, or, as someone has mentioned, one card column at a time. The coolest channel program I ever saw was one I cribbed from a boot loader and enhanced a bit. You passed it a file name and a device address, and it would go out to the drive, find out where the VTOC (volume table of contents) lived, seek to it, and search for the format 1 label that described the file you were looking for. Mind you, it tied up the channel for the duration, but the machine I was working on didn't multitask, so it was a win for me. -- /~\ Charlie Gibbs | In this world there are \ / <cgibbs@kltpzyxm.invalid> | two kinds of people: X I'm really at ac.dekanfrus | 1. Those who can extrapolate / \ if you read it the right way. | from incomplete data.
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2026-11-10 07:29 -1000 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <87eccsppbj.fsf@localhost> |
| In reply to | #236717 |
Alexander Schreiber <als@usenet.thangorodrim.de> writes: > No. The operating system and application software ran on the mainframe > CPU. But - as described above - a key design aspect of mainframes back > then was that I/O was not done by the CPU (like it was done on home > computers were all I/O was entirely handled by the CPU), but fully off- > loaded to peripherials that were essentially limited computers of their > own: > - CPU tells I/O interface (channel): "Do this I/O" > - CPU goes back to computing, channel does some I/O heavy lifting > - channel has completed I/O and sends an "Hey, I'm done" interrupt > to the CPU Original 360, there was limited processor and storage, but a lof of excess channel capacity ... as a result things like finding data was offloaded to channels ... which would "search" for desired data ... and as a result, channels ran half-duplex ... with channel dedicated to single operation ... constantly pulling search argument from processor storage. Move into 80s, storage got lot more abundant ... and channel architecture increasingly channel I/O increasingly became system throughput bottleneck. Early 80s, I wrote tome that 60s era 360/67 could get 70-80 CP67/CMS users on system ... and early 80s, with IBM processors getting 40-50 times faster and storage increasing 40-50 larger, should be able be see 3000-4000 users, but was only seeing 300-400 users (because disks & channels throughput only increased 3-5 times (partly because half-duplex operation increasingly played a latency role in fully being able to see benefits of any speed increase). A IBM disk division executive took exception and assigned the division performance group to refute the claim. After a couple weeks, they came back and said I had slightly understated the issue. 1988, one of issues of being able to see significant increase in throughput with LLNL serial stuff ... becoming fibre-channel standard was running full-duplex being able to concurrently transmit and receive on 1gbit speed links (w/o having to wait for full round-trip hand-shaking). Note: 1980, IBM STL (since renamed SVL) was bursting at seams and 300 people/terminals from IMS group were being moved to offsite bldg, with dataprocessing service back to STL datacenter. They had tried "remote 3270" but found human factors totally unacceptable. I get con'ed into doing channel extender support, allowing placing 3270 controllers at offsite bldg with no perceived difference in human factors. Unanticipated side-effect was the associated systems' throughput increase 10-15 percent. STL had been speading 3270 controllers across all channels with 3330 drives. The channel-extenders (operating full-duplex) significantly reduced the channel busy interference with the 3330 drives (for same amount of 3270 traffic; there was some consideration moving all 3270 controllers to channel-extenders). -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2026-11-10 07:55 -1000 |
| Subject | Re: what's a mainframe, NYT and Stratus (Re: [OT] Dead DEC Punch card times) |
| Message-ID | <87a4ngpo4u.fsf@localhost> |
| In reply to | #236729 |
Lynn Wheeler <lynn@garlic.com> writes: > Note: 1980, IBM STL (since renamed SVL) was bursting at seams and 300 > people/terminals from IMS group were being moved to offsite bldg, with > dataprocessing service back to STL datacenter. They had tried "remote > 3270" but found human factors totally unacceptable. > > I get con'ed into doing channel extender support, allowing placing 3270 > controllers at offsite bldg with no perceived difference in human > factors. Unanticipated side-effect was the associated systems' > throughput increase 10-15 percent. STL had been speading 3270 > controllers across all channels with 3330 drives. The channel-extenders > (operating full-duplex) significantly reduced the channel busy > interference with the 3330 drives (for same amount of 3270 traffic; > there was some consideration moving all 3270 controllers to > channel-extenders). Note once the 3033 was out the door, the processor engineers start on trout/3090. They configure memory, processor, channels, I/O to meet specific throughput goals. However, in San Jose, the administration dictated that the 3880 disk controller would use a (really slow, resulting in significant channel busy) vertical CISC processor (much slower than the previous processor in 3830 controller). The 3090 people thought the 3880 would be the same as 3830, but supporting 3380 3mbyte/sec transfer, when they found out how bad the 3880 controllers' channel busy was (there is significantly amount of half-cuplex channel protocol back&forth undernearth the covers with latency playing increasing role), they realized they would have to significantly increase the number of I/O channels in order to achieve system throughput targets ... which required an additional TCM (3090 said semi-facetiously they would bill the 3880 organization for the increase in 3090 manufacturing cost). Marketing eventually comes up with what a fantastic I/O machine the 3090 is with big increase in number of channels (but it was actually role played by slower 3880 controller and increase in channel busy associated with protocol chatter). -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web