Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #234111 > unrolled thread
| Started by | thresh3@fastmail.com (Lev) |
|---|---|
| First post | 2026-03-18 01:14 +0000 |
| Last post | 2026-04-03 11:33 +0100 |
| Articles | 20 on this page of 319 — 28 participants |
Back to article view | Back to alt.folklore.computers
Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 01:14 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 01:39 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 03:08 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 03:52 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 11:08 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 06:15 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 07:33 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 11:18 +0000
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-18 14:56 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 15:05 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 10:25 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 18:02 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 19:08 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 23:13 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:16 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 05:12 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 12:08 -0500
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 09:10 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 12:08 -0500
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 11:44 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 19:08 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 12:54 -0700
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-19 00:09 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-19 08:07 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 15:14 +0000
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-18 19:45 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 21:11 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 08:45 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:15 +0000
Re: Protocol constraints shaping communities songbird <songbird@anthive.com> - 2026-03-21 09:39 -0400
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 02:19 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 03:08 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 06:15 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 11:07 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 15:56 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 12:08 -0500
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 13:40 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 21:12 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 22:57 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:29 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:19 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 04:44 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 07:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 07:51 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 15:13 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:01 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 22:31 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:10 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 00:07 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 20:17 -0500
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-20 11:07 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 07:52 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 20:17 -0500
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:48 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-20 11:07 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 08:15 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:41 +0000
Re: Protocol constraints shaping communities Rich Alderson <news@alderson.users.panix.com> - 2026-03-20 19:16 -0400
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-20 23:47 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-21 01:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 01:22 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:40 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 20:23 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-21 23:04 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 23:30 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 17:43 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-19 18:33 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 13:41 -0500
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-19 19:38 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 00:10 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 13:40 -0500
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-19 19:38 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:10 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:06 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-20 16:35 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 07:53 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 20:18 -0500
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:16 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-20 11:07 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 08:06 -0700
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-21 00:35 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-21 01:11 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:54 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-21 23:04 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 23:23 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-22 11:16 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-22 11:13 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:01 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 08:04 -0700
Re: As We May Think, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-20 16:15 +0000
Re: As We May Think, Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 12:33 -0700
Re: Protocol constraints shaping communities antispam@fricas.org (Waldek Hebisch) - 2026-03-25 13:27 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-25 19:21 +0000
Re: Protocol constraints shaping communities poitras@pobox.com (Don Poitras) - 2026-03-25 19:48 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-25 20:45 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-26 09:54 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-25 20:41 +0000
Re: Protocol constraints shaping communities antispam@fricas.org (Waldek Hebisch) - 2026-03-26 19:26 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 22:55 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-18 23:41 +0000
Re: terminal memories, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-19 00:39 +0000
Re: terminal memories, Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 20:53 -0700
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 20:50 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 05:43 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-19 14:05 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:16 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 03:01 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 20:58 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 05:10 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 11:52 -0500
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:19 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-19 19:09 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:23 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:11 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-20 02:35 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 05:41 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:33 +0000
Re: Protocol constraints shaping communities Bob Martin <bob.martin@excite.com> - 2026-03-19 06:14 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-19 08:47 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 11:52 -0500
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-19 17:40 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:09 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 00:05 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-19 12:54 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 22:42 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 22:41 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 23:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 00:01 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-20 01:15 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 20:18 -0500
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 02:31 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-20 08:21 -0700
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-21 09:43 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:33 +0000
Re: Protocol constraints shaping communities Lars Poulsen <lars@beagle-ears.com> - 2026-03-20 12:24 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-20 20:47 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-20 21:24 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-20 22:31 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 00:19 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:50 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-21 16:35 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 20:26 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:51 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-21 16:34 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 07:37 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 20:27 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-21 14:16 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 21:18 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-21 23:04 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-21 23:32 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-22 05:02 +0000
Re: Protocol constraints shaping communities Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-03-22 07:02 -0400
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-22 08:14 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 18:02 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 22:50 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-17 20:35 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 03:56 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 06:15 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 07:37 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 11:08 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 18:02 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 13:44 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:19 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-20 10:06 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-23 02:28 -0300
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-23 13:42 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-23 19:10 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-23 20:36 -0300
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-23 17:18 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-24 13:57 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-24 17:40 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-24 14:26 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 22:09 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-24 15:40 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-24 22:51 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 23:15 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 05:03 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-25 18:19 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 23:23 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-26 03:46 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-26 05:40 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-26 05:43 +0000
Re: Protocol constraints shaping communities Lars Poulsen <lars@beagle-ears.com> - 2026-03-26 21:23 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 04:51 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-27 17:23 +0000
Re: IBM ancient history, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-27 18:43 +0000
Re: IBM ancient history, Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-27 12:52 -0700
Re: IBM ancient history, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-27 20:25 +0000
Re: IBM ancient history, Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 20:55 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-27 15:56 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-27 09:27 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-28 00:24 +0000
Re: Protocol constraints shaping communities Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-03-27 16:35 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-27 20:59 +0000
Re: Protocol constraints shaping communities Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-03-28 03:09 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 05:00 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 00:59 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-24 01:10 +0000
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-24 14:09 +0000
Re: Protocol constraints shaping communities "Kurt Weiske" <kurt.weiske@realitycheckbbs.org.remove-gn5-this> - 2026-03-24 07:47 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-23 17:10 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 15:06 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-18 23:47 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:15 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 03:02 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-21 09:27 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-19 08:04 -0700
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-20 08:49 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-20 08:35 -0700
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-20 19:32 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-20 20:03 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-20 20:03 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-20 10:03 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-20 08:12 -0700
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-20 17:54 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-23 02:11 -0300
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-23 05:30 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-23 02:07 -0300
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-23 17:10 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-23 18:42 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-23 21:51 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 01:00 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-24 04:38 -0300
Re: Protocol constraints shaping communities Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-03-23 15:28 -0400
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-23 15:22 -0700
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-24 04:55 -0300
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-24 17:35 +0000
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-24 16:21 -0300
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-24 19:42 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:10 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-24 20:11 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-26 10:00 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-26 18:16 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-28 00:52 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 20:31 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-24 14:08 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:16 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:03 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-24 20:38 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:36 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-24 14:23 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 04:47 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-25 07:32 -0700
Re: Protocol constraints shaping communities Mike Spencer <mds@bogus.nodomain.nowhere> - 2026-03-24 04:30 -0300
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-24 17:48 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-24 20:32 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-24 23:54 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-25 01:35 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-25 05:07 +0000
Re: births and deaths, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-25 02:13 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-24 21:00 -0700
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-25 14:16 +0000
Re: the fate of the world, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-25 16:23 +0000
Re: the fate of the world, Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-25 16:48 +0000
Re: the fate of the world, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-25 17:43 +0000
Re: the fate of the world, Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-25 18:41 +0000
Re: the fate of the world, Protocol constraints shaping communities John Levine <johnl@taugh.com> - 2026-03-25 21:18 +0000
Re: the fate of the world, Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-25 22:44 +0000
Re: the fate of the world, Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-26 03:46 +0000
Re: the fate of the world, Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-26 05:43 +0000
Re: the fate of the world, Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-25 12:16 -0700
Re: the fate of the world, Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-25 18:19 +0000
Re: Protocol constraints shaping communities Andreas Eder <a_eder_muc@web.de> - 2026-03-31 19:53 +0200
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 21:00 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-31 22:03 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-31 22:07 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 23:34 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-31 23:57 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-04-01 01:26 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-04-01 08:18 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-23 18:38 +0000
Re: Protocol constraints shaping communities Chris Ahlstrom <OFeem1987@teleworm.us> - 2026-03-23 15:29 -0400
Re: Protocol constraints shaping communities drb@ihatespam.msu.edu (Dennis Boone) - 2026-03-25 16:20 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 07:31 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 16:02 +0000
Re: Protocol constraints shaping communities Peter Flass <Peter@Iron-Spring.com> - 2026-03-18 13:36 -0700
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 09:44 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 12:08 -0500
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 11:33 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 19:07 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 12:35 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 21:12 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 14:34 -0700
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 01:14 +0000
Re: Protocol constraints shaping communities ram@zedat.fu-berlin.de (Stefan Ram) - 2026-03-19 01:30 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-19 07:11 +0000
Re: Protocol constraints shaping communities Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2026-03-18 19:46 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-18 21:11 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 23:09 +0000
Re: Protocol constraints shaping communities Daniel <me@sc1f1dan.com> - 2026-03-18 10:38 -0700
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-18 18:57 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-18 12:18 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:41 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-18 23:38 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 05:20 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-22 10:16 +0000
Re: Protocol constraints shaping communities scott@slp53.sl.home (Scott Lurndal) - 2026-03-22 16:42 +0000
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-18 22:34 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-19 07:45 -0700
Re: Protocol constraints shaping communities rbowman <bowman@montana.com> - 2026-03-19 18:08 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-18 23:04 +0000
Re: Protocol constraints shaping communities John Ames <commodorejohn@gmail.com> - 2026-03-19 08:00 -0700
Re: Protocol constraints shaping communities Daniel <me@sc1f1dan.com> - 2026-03-18 10:10 -0700
Re: Protocol constraints shaping communities Al Kossow <aek@bitsavers.org> - 2026-03-18 20:43 -0700
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-19 05:45 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-26 14:21 +0000
Re: Protocol constraints shaping communities snipeco.2@gmail.com (Sn!pe) - 2026-03-26 14:32 +0000
Re: Protocol constraints shaping communities thresh3@fastmail.com (Lev) - 2026-03-26 18:16 +0000
Re: Protocol constraints shaping communities snipeco.2@gmail.com (Sn!pe) - 2026-03-26 18:51 +0000
Re: Protocol constraints shaping communities Andy Burns <usenet@andyburns.uk> - 2026-03-26 19:07 +0000
Re: Protocol constraints shaping communities Lev <thresh3@fastmail.com> - 2026-03-26 19:45 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-26 23:37 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-26 19:34 +0000
Re: Protocol constraints shaping communities Lev <thresh3@fastmail.com> - 2026-03-26 19:44 +0000
Re: Protocol constraints shaping communities Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-26 22:33 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-26 23:31 +0000
Re: Protocol constraints shaping communities "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-03-27 10:18 +0000
Re: Protocol constraints shaping communities Nuno Silva <nunojsilva@invalid.invalid> - 2026-04-03 11:33 +0100
Page 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-26 03:46 +0000 |
| Message-ID | <q_1xR.635417$WDc7.118891@fx16.iad> |
| In reply to | #234392 |
On 2026-03-25, rbowman <bowman@montana.com> wrote: > On Wed, 25 Mar 2026 18:19:32 GMT, Charlie Gibbs wrote: > >> On 2026-03-25, rbowman <bowman@montana.com> wrote: >> >>> On Tue, 24 Mar 2026 15:40:53 -0700, Peter Flass wrote: >>> >>>> This is how OS/360 tasks work. Job=process, task=thread. I'm jist >>>> beginning to discover that Multics has threads called "control >>>> points". >>> >>> I am grateful that besides knowing JCL existed I never had to sue it. >> ^^^ >> Freudian slip? > > Yeah, that too. I think some people would like to sue it for cruel and > unusual punishment. It's going to have to wait in line. Far more people have suffered at the hands of Windows, which I think should take priority. As of today's news, though, Google and Meta are at the head of the line. -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-26 05:40 +0000 |
| Message-ID | <10q2grl$2j0c1$1@dont-email.me> |
| In reply to | #234393 |
On Thu, 26 Mar 2026 03:46:30 GMT, Charlie Gibbs wrote: > Far more people have suffered at the hands of Windows, which I think > should take priority. Those suffering at the hands of Microsoft don’t seem able or willing to do anything about it. They would rather continue complainining than take an effective decision to leave the suffering behind.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-03-26 05:43 +0000 |
| Message-ID | <n2jvceF86qbU1@mid.individual.net> |
| In reply to | #234393 |
On Thu, 26 Mar 2026 03:46:30 GMT, Charlie Gibbs wrote: > On 2026-03-25, rbowman <bowman@montana.com> wrote: > >> On Wed, 25 Mar 2026 18:19:32 GMT, Charlie Gibbs wrote: >> >>> On 2026-03-25, rbowman <bowman@montana.com> wrote: >>> >>>> On Tue, 24 Mar 2026 15:40:53 -0700, Peter Flass wrote: >>>> >>>>> This is how OS/360 tasks work. Job=process, task=thread. I'm jist >>>>> beginning to discover that Multics has threads called "control >>>>> points". >>>> >>>> I am grateful that besides knowing JCL existed I never had to sue it. >>> ^^^ >>> Freudian slip? >> >> Yeah, that too. I think some people would like to sue it for cruel and >> unusual punishment. > > It's going to have to wait in line. Far more people have suffered at > the hands of Windows, which I think should take priority. > > As of today's news, though, Google and Meta are at the head of the line. Couldn't happen to finer people.
[toc] | [prev] | [next] | [standalone]
| From | Lars Poulsen <lars@beagle-ears.com> |
|---|---|
| Date | 2026-03-26 21:23 -0700 |
| Message-ID | <10q50or$3e6sj$1@dont-email.me> |
| In reply to | #234373 |
On 2026-03-24 22:03, rbowman wrote:
> On Tue, 24 Mar 2026 15:40:53 -0700, Peter Flass wrote:
>
>> This is how OS/360 tasks work. Job=process, task=thread. I'm jist
>> beginning to discover that Multics has threads called "control points".
>
> I am grateful that besides knowing JCL existed I never had to sue it.
As part of my youthful studies in "comparative operating systems", was
was exposed to (in order of appearance),
* GIER (Danish Regnecentralen, 2nd generation - Transistor CPU,
papertape I/O)
* IBM 1130 DOS
* IBM 7094 IBSYS/IBJOB
* IBM 360/65 OS/360 MVT + HASP
* UNIVAC 1106 EXEC-8
* CDC 6600 KRONOS
and by 1975 had significant exposure to all but the last of these.
I learned JCL as a junior programmer/operator/help-desk for a bunch of
traveling experimental physicists visiting the Niels Bohn Institute of
Theoretical Phycics at University of Copenhaven, circa 1971.
They were puzzled by the control cards that needed to go into their
"dusty decks" of Fortran IV programs, and while at first I too was
puzzled by
//JOBID JOB (ACCT,LIMIT),CLASS=A
//MYJOB EXEC FORTGCLG
//FORT.SYSIN DD *
source
/*
//LINK.SYSIN DD *
overlay description
/*
//GO.SYSIN DD *
input data for Fortran unit 5
/*
//
I read the fine manual so I could understand the underlying macro,
and teach them how to save their things on the disk drives at he data
center.
But I alsway felt hat he Univac command language was much more rational.
And it worked the same on the timesharing side.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-27 04:51 +0000 |
| Message-ID | <10q52bk$3et82$1@dont-email.me> |
| In reply to | #234413 |
On Thu, 26 Mar 2026 21:23:55 -0700, Lars Poulsen wrote: > //FORT.SYSIN DD * > source > /* I think I can make sense of this pattern: the first name after “//” is the dataset name; “DD” indicates a dataset is being defined, and “*” the sentinel to indicate that the end of the data will consist of “/” followed by this string. Presumably, FORT.SYSIN is the dataset name expected by the Fortran compiler for the input source file. > //LINK.SYSIN DD * > overlay description > /* Similarly, LINK.SYSIN is the dataset name expected by the Linker. > //GO.SYSIN DD * > input data for Fortran unit 5 > /* And this is the dataset name for the user program. > // This marks the end of the job. As for this line: > //MYJOB EXEC FORTGCLG my guess is, FORTGCLG is the name of a JCL macro that does a compile, link and run of a user program. MYJOB is presumably some arbitrary job name, and EXEC is the command to run the macro as the job.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2026-03-27 17:23 +0000 |
| Message-ID | <r2zxR.1021$FE1.530@fx20.iad> |
| In reply to | #234414 |
On 2026-03-27, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Thu, 26 Mar 2026 21:23:55 -0700, Lars Poulsen wrote: > >> //FORT.SYSIN DD * >> source >> /* > > I think I can make sense of this pattern: the first name after “//” is > the dataset name; “DD” indicates a dataset is being defined, and “*” > the sentinel to indicate that the end of the data will consist of “/” > followed by this string. > > Presumably, FORT.SYSIN is the dataset name expected by the Fortran > compiler for the input source file. > >> //LINK.SYSIN DD * >> overlay description >> /* > > Similarly, LINK.SYSIN is the dataset name expected by the Linker. > >> //GO.SYSIN DD * >> input data for Fortran unit 5 >> /* > > And this is the dataset name for the user program. > >> // > > This marks the end of the job. Sounds like you've gotten it pretty much right. > As for this line: > >> //MYJOB EXEC FORTGCLG > > my guess is, FORTGCLG is the name of a JCL macro that does a compile, > link and run of a user program. MYJOB is presumably some arbitrary job > name, and EXEC is the command to run the macro as the job. Not necessarily a macro; more often it was the name of an executable program. In this case it's the FORTRAN compiler. If I recall correctly, "FORTGCLG" stands for FORTran G (version G of the FORTRAN compiler), Compile, Link, and Go (i.e. also execute the compiled program, as opposed to leaving the generated executable on disk, ready to be run by another JCL deck's EXEC command). -- /~\ Charlie Gibbs | Growth for the sake of \ / <cgibbs@kltpzyxm.invalid> | growth is the ideology X I'm really at ac.dekanfrus | of the cancer cell. / \ if you read it the right way. | -- Edward Abbey
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-03-27 18:43 +0000 |
| Subject | Re: IBM ancient history, Protocol constraints shaping communities |
| Message-ID | <10q6j4c$25ok$1@gal.iecc.com> |
| In reply to | #234419 |
According to Charlie Gibbs <cgibbs@kltpzyxm.invalid>: >On 2026-03-27, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > >> On Thu, 26 Mar 2026 21:23:55 -0700, Lars Poulsen wrote: >> >>> //FORT.SYSIN DD * >>> source >>> /* >> >> I think I can make sense of this pattern: the first name after “//” is >> the dataset name; “DD” indicates a dataset is being defined, and “*” >> the sentinel to indicate that the end of the data will consist of “/” >> followed by this string. >> >> Presumably, FORT.SYSIN is the dataset name expected by the Fortran >> compiler for the input source file. >> >>> //LINK.SYSIN DD * >>> overlay description >>> /* >> >> Similarly, LINK.SYSIN is the dataset name expected by the Linker. Actually LKED.SYSIN but pretty close. >> As for this line: >> >>> //MYJOB EXEC FORTGCLG >> >> my guess is, FORTGCLG is the name of a JCL macro that does a compile, >> link and run of a user program. MYJOB is presumably some arbitrary job >> name, and EXEC is the command to run the macro as the job. > >Not necessarily a macro; more often it was the name of an executable >program. It's a macro which they called a cataloged procedure and yes FORTGCLG was Fortran G, compile, link edit, and go. If it was directly running a program it'd say so: //MYJOB EXEC PGM=someprogram Nearly everyone used cataloged procecures since that made your job deck a lot smaller. -- 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 | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-27 12:52 -0700 |
| Subject | Re: IBM ancient history, Protocol constraints shaping communities |
| Message-ID | <10q6n5s$1aib$1@dont-email.me> |
| In reply to | #234420 |
On 3/27/26 11:43, John Levine wrote: > According to Charlie Gibbs <cgibbs@kltpzyxm.invalid>: >> On 2026-03-27, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >> >>> On Thu, 26 Mar 2026 21:23:55 -0700, Lars Poulsen wrote: >>> >>>> //FORT.SYSIN DD * >>>> source >>>> /* >>> >>> I think I can make sense of this pattern: the first name after “//” is >>> the dataset name; “DD” indicates a dataset is being defined, and “*” >>> the sentinel to indicate that the end of the data will consist of “/” >>> followed by this string. >>> >>> Presumably, FORT.SYSIN is the dataset name expected by the Fortran >>> compiler for the input source file. >>> >>>> //LINK.SYSIN DD * >>>> overlay description >>>> /* >>> >>> Similarly, LINK.SYSIN is the dataset name expected by the Linker. > > Actually LKED.SYSIN but pretty close. LINK is probably right. It's <stepname>.<ddname>, so it depends on what the step in the PROC is named. You do know that this isn't ancient history, don't you? Well, Fortran G is pretty well gone, but zOS systems still run on JCL today.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-03-27 20:25 +0000 |
| Subject | Re: IBM ancient history, Protocol constraints shaping communities |
| Message-ID | <10q6p4d$1lhc$1@gal.iecc.com> |
| In reply to | #234421 |
It appears that Peter Flass <Peter@Iron-Spring.com> said: >On 3/27/26 11:43, John Levine wrote: >> According to Charlie Gibbs <cgibbs@kltpzyxm.invalid>: >>> On 2026-03-27, Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>> >>>> On Thu, 26 Mar 2026 21:23:55 -0700, Lars Poulsen wrote: >>>> >>>>> //FORT.SYSIN DD * >>>>> source >>>>> /* >>>> >>>> I think I can make sense of this pattern: the first name after “//” is >>>> the dataset name; “DD” indicates a dataset is being defined, and “*” >>>> the sentinel to indicate that the end of the data will consist of “/” >>>> followed by this string. >>>> >>>> Presumably, FORT.SYSIN is the dataset name expected by the Fortran >>>> compiler for the input source file. >>>> >>>>> //LINK.SYSIN DD * >>>>> overlay description >>>>> /* >>>> >>>> Similarly, LINK.SYSIN is the dataset name expected by the Linker. >> >> Actually LKED.SYSIN but pretty close. > >LINK is probably right. It's <stepname>.<ddname>, so it depends on what >the step in the PROC is named. It's LKED.SYSIN. C28-6639-1 says so. >You do know that this isn't ancient history, don't you? Well, Fortran G >is pretty well gone, but zOS systems still run on JCL today. True, but I'm trying not to think about it. I wonder how much of the stuff that zOS does these days is jobs with JCL versus online stuff. I suppose the online subsystems are started from JCL jobs. -- 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 | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-27 20:55 +0000 |
| Subject | Re: IBM ancient history, Protocol constraints shaping communities |
| Message-ID | <10q6qro$2nka$1@dont-email.me> |
| In reply to | #234421 |
On Fri, 27 Mar 2026 12:52:28 -0700, Peter Flass wrote: > You do know that this isn't ancient history, don't you? Well, > Fortran G is pretty well gone, but zOS systems still run on JCL > today. Vestigial legacy technology. As each business still with an IBM mainframe at its core goes bankrupt or otherwise gets acquired and shut down, so the mainframe market shrinks by another little bit.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-27 15:56 +0000 |
| Message-ID | <yMxxR.742655$fo3.293568@fx22.iad> |
| In reply to | #234413 |
Lars Poulsen <lars@beagle-ears.com> writes:
>On 2026-03-24 22:03, rbowman wrote:
>> On Tue, 24 Mar 2026 15:40:53 -0700, Peter Flass wrote:
>>
>>> This is how OS/360 tasks work. Job=process, task=thread. I'm jist
>>> beginning to discover that Multics has threads called "control points".
>>
>> I am grateful that besides knowing JCL existed I never had to sue it.
>
>As part of my youthful studies in "comparative operating systems", was
>was exposed to (in order of appearance),
>
>* GIER (Danish Regnecentralen, 2nd generation - Transistor CPU,
> papertape I/O)
>* IBM 1130 DOS
>* IBM 7094 IBSYS/IBJOB
>* IBM 360/65 OS/360 MVT + HASP
>* UNIVAC 1106 EXEC-8
>* CDC 6600 KRONOS
>
>and by 1975 had significant exposure to all but the last of these.
>I learned JCL as a junior programmer/operator/help-desk for a bunch of
>traveling experimental physicists visiting the Niels Bohn Institute of
>Theoretical Phycics at University of Copenhaven, circa 1971.
>
>They were puzzled by the control cards that needed to go into their
>"dusty decks" of Fortran IV programs, and while at first I too was
>puzzled by
> //JOBID JOB (ACCT,LIMIT),CLASS=A
> //MYJOB EXEC FORTGCLG
> //FORT.SYSIN DD *
> source
> /*
> //LINK.SYSIN DD *
> overlay description
> /*
> //GO.SYSIN DD *
> input data for Fortran unit 5
> /*
> //
The same job on Burroughs entered from
the card reader or a pseudo card disk file.
On a punched card the '?' in column 1 was
an invalid 1-2-3 punch. In a pseudo card
deck, the question mark character was used.
?LI SYSTEM/OPERATOR
?COMPILE ADSINH BPL LIB 08 MEM 990
?FILE PRINT = LADSIN PBK
?DATA CARD
$SET LST1
&
& This is the 00024000
& 00025000
& 00026000
& ____________________________________________________________________ 00027000
& | | 00028000
& | AUTOMATED DOCUMENTATION SYSTEM | 00029000
& |__________________________________________________________________| 00030000
& 00031000
& VERSION: 01 February 1981 00032000
...
?END
Disk and packs were sector-based, not track based. There
were bog-standard directories and files. The MCP handled
allocation of disk and pack space automatically. Automatic extent
based allocation was used, so there were defragmentation
commands (SQ (Squash Disk) and SQP (Squash pack)) avialable
to the operator.
"PRN" directed the listing to the printer. "PBK" would
direct the listing to a printer backup (spool) file on
disk or pack depending on an MCP option.
The resulting executable would be called 'ADSINH' on disk.
Another example:
?LI SYSTEM/OPERATOR
?EX DISPKV; AX"Y"; AX"Y"
?DATA INPUTF
CO LABEL CU 16/0 SN 513222 AC RM PN PAYROLL OI PAYROLL
CO LABEL CU 16/1 SN 513223 AC RM PN FINANCE OI FINANCE
?END
?COPY AND SET(MPID=MCP) = FROM VS2335(TAPE) TO DISK
Executes the disk/pack formatter utility, labels two
packs (channel 16, units 0 and 1). The ?COPY command
executes SYSTEM/COPY to copy everything ('=')
from the tape labeled VS2335 to the disk subsystem.
The MCP supported automatic volume recognition, so the
job would wait for the operator to mount the tape and
ready (e.g. RY 6/0 on the operator console) the drive
to cause it to read the label (the RY is only required
if the tape drive is shared by multiple hosts, otherwise
the MCP will read the tape volume label as soon as it
was mounted and assign it automatically to a program
waiting for that tape).
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <Peter@Iron-Spring.com> |
|---|---|
| Date | 2026-03-27 09:27 -0700 |
| Message-ID | <10q6b6b$3so0n$1@dont-email.me> |
| In reply to | #234416 |
On 3/27/26 08:56, Scott Lurndal wrote: [snip] > The same job on Burroughs entered from > the card reader or a pseudo card disk file. > > On a punched card the '?' in column 1 was > an invalid 1-2-3 punch. In a pseudo card > deck, the question mark character was used. > > ?LI SYSTEM/OPERATOR > ?COMPILE ADSINH BPL LIB 08 MEM 990 > ?FILE PRINT = LADSIN PBK > ?DATA CARD > $SET LST1 > ... > ?END > > "PRN" directed the listing to the printer. "PBK" would > direct the listing to a printer backup (spool) file on > disk or pack depending on an MCP option. Used to be PBD for the 5500 MCP (PBT was tape). I wonder why they changed it?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-28 00:24 +0000 |
| Message-ID | <HcFxR.1508772$At07.811920@fx17.iad> |
| In reply to | #234417 |
Peter Flass <Peter@Iron-Spring.com> writes: >On 3/27/26 08:56, Scott Lurndal wrote: >[snip] > >> The same job on Burroughs entered from >> the card reader or a pseudo card disk file. >> >> On a punched card the '?' in column 1 was >> an invalid 1-2-3 punch. In a pseudo card >> deck, the question mark character was used. >> >> ?LI SYSTEM/OPERATOR >> ?COMPILE ADSINH BPL LIB 08 MEM 990 >> ?FILE PRINT = LADSIN PBK >> ?DATA CARD >> $SET LST1 >> ... >> ?END >> > >> "PRN" directed the listing to the printer. "PBK" would >> direct the listing to a printer backup (spool) file on >> disk or pack depending on an MCP option. > >Used to be PBD for the 5500 MCP (PBT was tape). I wonder why they >changed it? PBD was disk, PBP was pack, PBT was tape and PBK would use the MCP default (the MCP SO (set option) command was used to set the default).
[toc] | [prev] | [next] | [standalone]
| From | Bill Findlay <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2026-03-27 16:35 +0000 |
| Message-ID | <0001HW.2F76E96B0046F88630663638F@news.individual.net> |
| In reply to | #234416 |
On 27 Mar 2026, Scott Lurndal wrote (in article <yMxxR.742655$fo3.293568@fx22.iad>): > Lars Poulsen <lars@beagle-ears.com> writes: > > On 2026-03-24 22:03, rbowman wrote: > > > On Tue, 24 Mar 2026 15:40:53 -0700, Peter Flass wrote: > > > > > > > This is how OS/360 tasks work. Job=process, task=thread. I'm jist > > > > beginning to discover that Multics has threads called "control points". > > > > > > I am grateful that besides knowing JCL existed I never had to sue it. > > > > As part of my youthful studies in "comparative operating systems", was > > was exposed to (in order of appearance), > > > > * GIER (Danish Regnecentralen, 2nd generation - Transistor CPU, > > papertape I/O) > > * IBM 1130 DOS > > * IBM 7094 IBSYS/IBJOB > > * IBM 360/65 OS/360 MVT + HASP > > * UNIVAC 1106 EXEC-8 > > * CDC 6600 KRONOS > > > > and by 1975 had significant exposure to all but the last of these. > > I learned JCL as a junior programmer/operator/help-desk for a bunch of > > traveling experimental physicists visiting the Niels Bohn Institute of > > Theoretical Phycics at University of Copenhaven, circa 1971. > > > > They were puzzled by the control cards that needed to go into their > > "dusty decks" of Fortran IV programs, and while at first I too was > > puzzled by > > //JOBID JOB (ACCT,LIMIT),CLASS=A > > //MYJOB EXEC FORTGCLG > > //FORT.SYSIN DD * > > source > > /* > > //LINK.SYSIN DD * > > overlay description > > /* > > //GO.SYSIN DD * > > input data for Fortran unit 5 > > /* > > // > > The same job on Burroughs entered from > the card reader or a pseudo card disk file. > > On a punched card the '?' in column 1 was > an invalid 1-2-3 punch. In a pseudo card > deck, the question mark character was used. > > ?LI SYSTEM/OPERATOR > ?COMPILE ADSINH BPL LIB 08 MEM 990 > ?FILE PRINT = LADSIN PBK > ?DATA CARD > ... > ?END This is what the command for a Pascal compile-and run looked like under GEORGE 3 on an ICL 1900 Series m/c in 1976: PASCAL TEXT=MYPROG, INPUT=MYDATA where either parameter could be omitted if the corresponding data followed the command in situ. It could be issued from a card reader as part of a batch job, or identically, online, from a terminal. If online, and no INPUT file was named, the run was interactive. To be honest, PASCAL was a complex macro containing many commands and implementing many more options, such as saving the object program, setting diagnostic options, setting CPU time and store limits, etc, etc. Each was specified by a keyword equation like those above, or defaulted. -- Bill Findlay
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-27 20:59 +0000 |
| Message-ID | <10q6r2m$2nka$2@dont-email.me> |
| In reply to | #234418 |
On Fri, 27 Mar 2026 16:35:55 +0000, Bill Findlay wrote:
> To be honest, PASCAL was a complex macro containing many commands
> and implementing many more options, such as saving the object
> program, setting diagnostic options, setting CPU time and store
> limits, etc, etc.
I recall doing some Fortran work on an ICL 1904 as part of a summer
job. We were given some boilerplate job-control cards to use by the
resident systems programmer. I remember things like
LOAD #«prog»
where «prog» was a four-character program name: XFAT for the Fortran
compiler, XPCK for the linker. Then, at the end of it, to run your own
completely-built program, you did
LOAD #
(with no name following).
[toc] | [prev] | [next] | [standalone]
| From | Bill Findlay <findlaybill@blueyonder.co.uk> |
|---|---|
| Date | 2026-03-28 03:09 +0000 |
| Message-ID | <0001HW.2F777DE000524BCF30663638F@news.individual.net> |
| In reply to | #234424 |
On 27 Mar 2026, Lawrence D´Oliveiro wrote (in article <10q6r2m$2nka$2@dont-email.me>): > On Fri, 27 Mar 2026 16:35:55 +0000, Bill Findlay wrote: > > > To be honest, PASCAL was a complex macro containing many commands > > and implementing many more options, such as saving the object > > program, setting diagnostic options, setting CPU time and store > > limits, etc, etc. > > I recall doing some Fortran work on an ICL 1904 as part of a summer > job. We were given some boilerplate job-control cards to use by the The commands you show below would have been typed in at the console TTY (normally, there was a facility to redirect the command input temporarily to an input device). > resident systems programmer. I remember things like > > LOAD #«prog» You were using what was known as Operator's Executive, an elementary OS that preceded GEORGE and was repurposed somewhat as a microkernel/HAL for GEORGE. > where «prog» was a four-character program name: XFAT for the Fortran > compiler, XPCK for the linker. Well remembered! > Then, at the end of it, to run your own completely-built program, you did > > LOAD # > (with no name following). Not quite so well remembered. -- Bill Findlay
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-03-25 05:00 +0000 |
| Message-ID | <n2h8f9FgjvlU7@mid.individual.net> |
| In reply to | #234359 |
On Tue, 24 Mar 2026 22:09:25 -0000 (UTC), Lawrence D’Oliveiro wrote: > This is why threads are inherently more prone to mysterious, > intermittent, > hard-to-reproduce bugs. The bugs will likely be due improper sequences > of accesses to shared data structures -- i.e. they are timing-related. > And all too frequently, attempts to narrow down their causes -- by > adding diagnostic code etc -- can make the problem disappear, just > adding to the frustration. A later project that used a LOT of threads that were all hitting on the same data had problems. Not my circus, not my monkeys. It was done by the programmer who originally criticized my use of threads and an accomplice. My use was simple. Receive a CJIN (criminal justice network) query from on of the stations, send the query to the state agency, receive the return asynchronously, format the data and return it to the querying station. Each thread could happily block waiting for its semaphore and wasn't messing with a common data pool. The alternate would be a loop with a bunch of select statements and so forth. Horses for courses. Node.js does very well with a single threaded model although I prefer not to look under the hood.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-03-24 00:59 +0000 |
| Message-ID | <10psnl3$kqga$1@dont-email.me> |
| In reply to | #234336 |
On 23 Mar 2026 20:36:26 -0300, Mike Spencer wrote: > I'm now 84, less agile of mind, and what I take to be the > authoritative resource for js (O'Reilly Rhino book) is 1,000 pages. The core language is a lot smaller than that. A good place to find some introductory tutes is MDN <https://developer.mozilla.org/en-US/docs/Web/JavaScript>.
[toc] | [prev] | [next] | [standalone]
| From | rbowman <bowman@montana.com> |
|---|---|
| Date | 2026-03-24 01:10 +0000 |
| Message-ID | <n2e6jhF2j0cU1@mid.individual.net> |
| In reply to | #234336 |
On 23 Mar 2026 20:36:26 -0300, Mike Spencer wrote: > I learned C by reading K&R cover to cover. Alas, that was 40 years ago. > I'm now 84, less agile of mind, and what I take to be the authoritative > resource for js (O'Reilly Rhino book) is 1,000 pages. Crockford's 'JavaScript: The Good Parts' is 172 pages :) It probably is still useful but it's from 2014 so if pre-ES6, TypeScript, and other attempts to turn a sow's ear into a silk purse. Sometimes though a pig's ear is just the right tool if you don't roll around in the sty.
[toc] | [prev] | [next] | [standalone]
| From | ram@zedat.fu-berlin.de (Stefan Ram) |
|---|---|
| Date | 2026-03-24 14:09 +0000 |
| Message-ID | <programming-20260324150411@ram.dialup.fu-berlin.de> |
| In reply to | #234336 |
Mike Spencer <mds@bogus.nodomain.nowhere> wrote or quoted: >I learned C by reading K&R cover to cover. Alas, that was 40 years >ago. I'm now 84, less agile of mind, and what I take to be the >authoritative resource for js (O'Reilly Rhino book) is 1,000 pages. Chatbots can help you code these days. ECMAScript® (JavaScript) 2025 Language Specification 847 pages ISO/IEC 9899 (C), 2025 working draft 812 pages
[toc] | [prev] | [next] | [standalone]
Page 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web