Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #160014 > unrolled thread
| Started by | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| First post | 2016-02-20 23:29 -0500 |
| Last post | 2016-02-24 15:24 -0600 |
| Articles | 20 on this page of 193 — 30 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: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-20 23:29 -0500
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-20 22:48 -0600
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-21 19:37 +1100
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-21 09:17 +0000
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-21 23:28 +0000
Re: Qbasic Walter Bushell <proto@panix.com> - 2016-03-18 18:04 -0400
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-21 05:59 -0500
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-22 03:30 +1100
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-21 18:34 -0600
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-20 21:03 -0800
Re: Qbasic "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-21 05:53 -0500
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-22 03:27 +1100
Re: Qbasic JimP <solosam90@gmail.com> - 2016-02-21 12:52 -0600
Re: Qbasic Quadibloc <jsavard@ecn.ab.ca> - 2016-02-21 12:23 -0800
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-22 03:17 +1100
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-21 18:36 -0700
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-22 14:03 +1100
Re: Qbasic Andrew Swallow <am.swallow@btinternet.com> - 2016-02-22 13:14 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 11:05 -0600
Re: Qbasic hancock4@bbs.cpcn.com - 2016-02-22 11:19 -0800
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 15:39 -0600
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-25 06:18 -0600
Re: Qbasic Peter Flass <peter_flass@yahoo.com> - 2016-02-25 06:53 -0700
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-25 08:45 -0600
Re: Qbasic mausg@mail.com - 2016-02-25 15:56 +0000
Re: Qbasic Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-25 18:19 +0000
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-02-25 10:25 -0500
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-02-25 16:07 +0000
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-25 16:28 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-02-25 16:01 -0800
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-25 18:51 -0600
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-02-26 15:42 +0000
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-02-26 10:15 -0600
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-02-26 11:20 -0700
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-02-27 10:30 -0800
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-02-27 13:06 -0600
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-02-26 19:05 -0600
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-02-26 20:49 -0600
Re: Qbasic - lies about Medicare "hgww" <hgww@gmail.com> - 2016-02-27 14:33 +1100
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-02-26 21:46 -0600
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-02-27 06:44 -0700
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-02-27 11:51 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-28 10:51 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-02-28 12:58 -0800
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-28 16:34 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-02-28 17:47 -0800
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 07:40 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 09:28 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 12:46 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 14:31 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 17:23 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 18:13 -0600
Re: Qbasic - lies about Medicare Quadibloc <jsavard@ecn.ab.ca> - 2016-02-28 20:14 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-28 21:04 -0800
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-02-29 09:31 +0000
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 07:43 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 08:21 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 12:43 -0600
Re: Qbasic - lies about Medicare pechter@chuckie.(none) (William Pechter) - 2016-02-29 17:43 +0000
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-29 17:35 +0000
Re: Qbasic - lies about Medicare Walter Banks <walter@bytecraft.com> - 2016-02-29 14:19 -0500
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-29 17:19 -0600
Re: Qbasic - lies about Medicare Ahem A Rivet's Shot <steveo@eircom.net> - 2016-03-01 06:02 +0000
Re: Qbasic - lies about Medicare Walter Banks <walter@bytecraft.com> - 2016-03-02 10:40 -0500
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-01 10:31 +0000
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-01 13:55 +0000
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-01 14:14 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-02 01:33 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-02 14:19 +0000
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-03-02 10:23 -0600
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-03 13:39 +0000
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-03-03 08:28 -0600
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-03 16:21 +0100
Re: Qbasic - lies about Medicare Ahem A Rivet's Shot <steveo@eircom.net> - 2016-03-03 16:17 +0000
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-03 16:23 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-03 03:58 +1100
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-02 15:06 -0600
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-03 13:39 +0000
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-03 15:57 +0100
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-04 09:58 +0000
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-04 11:11 +0100
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-04 16:22 +0000
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-05 03:05 +0100
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-04 19:31 -0700
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-04 19:25 -0800
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-03-05 11:14 -0500
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-05 09:50 -0800
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-03-05 17:41 -0500
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-05 20:06 -0700
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-05 20:06 -0700
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-05 20:36 -0800
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-05 22:08 -0800
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-03-06 09:46 -0500
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-06 09:59 -0800
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-03-06 18:40 -0500
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-06 17:25 -0700
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-07 01:13 +0000
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-06 17:26 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-15 12:32 -0700
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-06 18:04 -0800
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-07 14:09 +0000
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-07 11:18 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-07 11:57 -0800
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-07 16:24 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-08 08:18 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-11 11:40 -0800
Re: Qbasic - lies about Medicare Anne & Lynn Wheeler <lynn@garlic.com> - 2016-03-13 10:14 -0700
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 13:37 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-06 14:08 +0000
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-06 11:24 -0800
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 07:34 +1100
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-06 17:25 -0700
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 12:14 +1100
Re: Qbasic - lies about Medicare pechter@mongo.(none) (William Pechter) - 2016-03-07 02:49 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 15:47 +1100
Re: Qbasic - lies about Medicare Lawrence Statton NK1G <lawrence@senguio.mx> - 2016-03-06 19:54 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-05 12:02 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-05 14:53 -0800
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-05 23:42 +0000
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-05 21:57 -0800
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-03-06 00:26 -0600
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-07 01:13 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-06 17:29 +1100
Re: Qbasic - lies about Medicare Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-03-06 02:52 -0400
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-06 11:16 -0800
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 07:30 +1100
Re: Qbasic - lies about Medicare Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-03-06 17:37 -0400
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 10:12 +1100
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-03-06 19:52 -0600
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 13:39 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-06 14:08 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 01:59 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-07 14:12 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-08 03:11 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-08 13:16 +0000
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-03-08 08:07 -0600
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-08 14:58 -0800
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-09 00:32 +0000
Re: Basic - lies about Medicare "Sam Crean" <sg55443@gmail.com> - 2016-03-09 11:58 +1100
Re: Basic - lies about Medicare mausg@mail.com - 2016-03-09 11:28 +0000
Re: Qbasic - lies about Medicare mausg@mail.com - 2016-03-09 11:25 +0000
Re: Qbasic - lies about Medicare hancock4@bbs.cpcn.com - 2016-03-08 15:01 -0800
Water: was Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-08 07:18 -0700
Re: Water: was Re: Qbasic - lies about Medicare Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-03-08 15:06 -0400
Re: Water: was Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-09 13:41 +0000
Re: Water: was Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-09 06:48 -0700
Re: Water: was Re: Qbasic - lies about Medicare "Sam Crean" <sg55443@gmail.com> - 2016-03-10 04:44 +1100
Re: Water: was Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-10 13:24 +0000
Re: Water: was Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-10 14:14 +0000
Re: Qbasic - lies about Medicare "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-03-09 05:09 +1100
Re: Qbasic - lies about Medicare Gerard Schildberger <gerard46@rrt.net> - 2016-03-08 11:23 -0800
Re: Qbasic - lies about Medicare Ibmekon <Ibmekon> - 2016-03-06 09:54 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 01:57 +1100
Re: Qbasic - lies about Medicare Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-03-07 01:13 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-07 13:35 +1100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-06 14:08 +0000
Re: Qbasic - lies about Medicare "Sangmo" <ju410@gmail.com> - 2016-03-06 11:51 +1100
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-07 14:24 +0000
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-07 10:38 -0700
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-04 12:57 -0600
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-03-04 12:08 -0700
Re: computer security hancock4@bbs.cpcn.com - 2016-03-04 14:36 -0800
Re: computer security Peter Flass <peter_flass@yahoo.com> - 2016-03-04 19:31 -0700
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-05 13:57 +0000
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-05 15:37 -0600
Re: Qbasic - lies about Medicare Morten Reistad <first@last.name.invalid> - 2016-03-06 00:35 +0100
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-06 14:08 +0000
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-03-16 21:34 -0500
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-17 13:17 +0000
Re: Qbasic - lies about Medicare Huge <Huge@nowhere.much.invalid> - 2016-03-17 14:17 +0000
Re: Qbasic - lies about Medicare jmfbahciv <See.above@aol.com> - 2016-03-18 12:45 +0000
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-03-07 15:01 +0000
Re: Qbasic - lies about Medicare Walter Banks <walter@bytecraft.com> - 2016-03-02 10:37 -0500
Re: Qbasic - lies about Medicare Dave Garland <dave.garland@wizinfo.com> - 2016-03-01 10:47 -0600
Re: Qbasic - lies about Medicare Andrew Swallow <am.swallow@btinternet.com> - 2016-03-01 10:12 +0000
Re: Qbasic - lies about Medicare Dan Espen <despen@verizon.net> - 2016-02-27 00:28 -0500
Re: Qbasic - lies about Medicare Peter Flass <peter_flass@yahoo.com> - 2016-02-27 06:44 -0700
Re: Qbasic - lies about Medicare Lawrence Statton NK1G <lawrence@senguio.mx> - 2016-02-28 14:03 -0600
Re: Qbasic - lies about Medicare JimP <solosam90@gmail.com> - 2016-02-28 10:47 -0600
Re: Qbasic - lies about Medicare scott@slp53.sl.home (Scott Lurndal) - 2016-02-29 14:52 +0000
Re: Qbasic - lies about Medicare "Osmium" <r124c4u102@comcast.net> - 2016-02-29 09:25 -0600
Re: Qbasic - lies about Medicare Stephen Sprunk <stephen@sprunk.org> - 2016-02-29 14:33 -0600
Re: Qbasic - lies about Medicare Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-27 08:32 +0000
Re: Qbasic - lies about Medicare Walter Banks <walter@bytecraft.com> - 2016-02-27 11:21 -0500
Re: Qbasic pechter@chuckie.(none) (William Pechter) - 2016-02-25 15:31 +0000
Re: Qbasic "Osmium" <r124c4u102@comcast.net> - 2016-02-25 10:22 -0600
Re: Qbasic pechter@chuckie.(none) (William Pechter) - 2016-02-25 17:28 +0000
Re: Qbasic Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-25 08:11 -0800
Re: Qbasic Dave Garland <dave.garland@wizinfo.com> - 2016-02-25 10:40 -0600
Re: Qbasic "hgww" <hgww@gmail.com> - 2016-02-26 04:37 +1100
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-23 12:29 -0600
Re: Qbasic scott@slp53.sl.home (Scott Lurndal) - 2016-02-24 13:55 +0000
Re: Qbasic Stephen Sprunk <stephen@sprunk.org> - 2016-02-24 15:24 -0600
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-03-07 14:09 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <PM00052D75DFF93FB2@aca44602.ipt.aol.com> |
| In reply to | #160638 |
hancock4@bbs.cpcn.com wrote: > On Sunday, March 6, 2016 at 8:13:33 PM UTC-5, Charlie Gibbs wrote: > >> > If customers want something you're not selling, whose fault is that? >> >> Your marketing department, which hasn't convinced the customers to >> want what you're selling. > > Well, I have to say I think IBM's marketing people of the 1930s > deserve a lot of credit. Tabulating machines were an expensive > niche product back then, but they managed to convince lots of > businesses that they'd be more productive with them. Today, > we take IBM's reputation for granted, but before WW II, IBM > wasn't particularly well known. > > Conversely, in the late 1960s, computers were so fashionable and > popular, especially System/360, that, AFAIK, the 'selling' aspect > of the job was relatively easy--the hard part was getting the > customer up and running. > > > Switching industries, the steel industry was basically booming from > 1940 to 1974 for the most part. After 1974, foreign competition, > both in raw steel and finished goods, really hammered the industry, > and it was a big adjustment to take (likewise with autos, too). Then the steel industry was unable to provide the different kinds of steel that manufacturers wanted. The small steel mills were able to adjust but not the big ones. The big ones also couldn't convince the union to change methods so they could only sell "one size fits all" steel. > > > I must admit that being a salesman was not a job I wanted. (I was > a clerk in a store and sold newspapers, but that was different; it > wasn't actually 'selling'; I just took the money and delivered the > item.) You have to like people to be an effective salesman. /BAH
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-03-07 11:18 -0800 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <3573bc30-a4d2-4f0b-9bdb-d5443ac870d6@googlegroups.com> |
| In reply to | #160646 |
On Monday, March 7, 2016 at 9:10:30 AM UTC-5, jmfbahciv wrote: > Then the steel industry was unable to provide the different kinds > of steel that manufacturers wanted. The small steel mills were > able to adjust but not the big ones. The big ones also couldn't > convince the union to change methods so they could only sell > "one size fits all" steel. The steel industry always offered a large variety of steel; that's nothing new. The problem for domestic mills was cost and quality. Foreign steel was cheaper, and closer to specifications. One problem was that domestic producers were still using the open hearth method, which was obsolete. Foreign producers used the basic oxygen which was superior. Another problem was that foreign wages were substantially less than domestic wages. Lastly, domestic producers had much more strict safety and environmental regulations than foreign producers. Pollution and fatalities in foreign mills are just covered up and not discussed. You can see on TV people in certain countries wearing masks on the street because the pollution is so bad. These are tough questions to which there are no easy answers. As mentioned, I know of local specialty mill that closed due to (a) foreign competition and (b) pollution. About 1,000 jobs were lost. But, to save those jobs, should skilled workers in a tough environment be paid minimum wage and no benefits? Should the mill be allowed to pollute a key water supply with nasty acids? Send nasty smoke into the atmosphere?
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-03-07 11:57 -0800 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <87d1r6gixg.fsf@garlic.com> |
| In reply to | #160646 |
jmfbahciv <See.above@aol.com> writes: > Then the steel industry was unable to provide the different kinds > of steel that manufacturers wanted. The small steel mills were > able to adjust but not the big ones. The big ones also couldn't > convince the union to change methods so they could only sell > "one size fits all" steel. much of the industry was looting revenue; not reinvesting in the business, and not fully funding pensions. because they weren't reinvesting and keeping up with technology ... they start to see downturn (from competition) ... but it was accelerated because of pensions being paid out of current revenue. in downturn, it is possible for revenue to drop below the unfunded pension obligations. Having previously looted fully-funded pension obligations as profits ... then in any downturn they could reduce the number of current employees ... but they couldn't reduce past pension obligations. They eventually declare bankruptcy based on the unfuneded pension obligation ... dumping the obligation off onto PBGC (no "clawbacks" of previous payouts as profit instead of funding pensions). http://www.pbgc.gov/ dumping the obligations on the federal government is similar to employers paying below living wages and relying on government social programs to make up the difference. another gimmick that industries used was changing the corporate structure so that profit was moved from heavy people intensive part of the business to subsidiary that required relatively few people. airline industry did this by structuring airline operations as break-even and moving profit to ticket (mostly computerized) subsidiary. The airline operations can be showing no profit while the parent company shows significant overall profit because the way it is booked with ticket sales. Showing no profit or even loss gives advantage in union/employee negotiations (even when parent company still shows significant profit because of the way books are done). They can even declare bankruptcy for the airline operations and dump the employee pension obligations on PBGC. A number of years ago, the parent company of one of the auto big three showed 5% of its profit from making cars, but 95% of its profit from financing the selling of cars (it was even possible for the making of cars shows loss while parent company is still showing significant profit). the books are cooked so the profit from operation that involves large number of people making something are moved into a different subidiary ... so the people-intensive operation shows break-even or loss. The latest gimmick is that the subsidiary (where the profits are being booked) is moved offshore ... so the profit shows up in an extremely attractive tax haven. http://www.garlic.com/~lynn/submisc.html#tax.evasion in other times and places ... most of these activities could have been viewed as scams. a few past PBGC posts http://www.garlic.com/~lynn/2008.html#65 As Expected, Ford Falls From 2nd Place in U.S. Sales http://www.garlic.com/~lynn/2010b.html#24 Happy DEC-10 Day http://www.garlic.com/~lynn/2010d.html#46 search engine history, was Happy DEC-10 Day http://www.garlic.com/~lynn/2014m.html#8 weird apple trivia -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-03-07 16:24 -0800 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <ae65bac7-ee76-42ea-b3fe-c031fdd45940@googlegroups.com> |
| In reply to | #160665 |
On Monday, March 7, 2016 at 2:57:34 PM UTC-5, Anne & Lynn Wheeler wrote: > jmfbahciv <> writes: > > Then the steel industry was unable to provide the different kinds > > of steel that manufacturers wanted. The small steel mills were > > able to adjust but not the big ones. The big ones also couldn't > > convince the union to change methods so they could only sell > > "one size fits all" steel. > > much of the industry was looting revenue; not reinvesting in the > business, and not fully funding pensions. To be honest, I'm not sure I can blame the steel (or other) industries for failing to fund pensions. They had every reason to expect continued growth and plenty of business to support pensions. Also, I suspect at the time (1960s), people weren't living as long as later, so they expected less exposure. Western Union also got hammered by hits pension obligations because it was a declining company. > because they weren't reinvesting and keeping up with technology ... they > start to see downturn (from competition) ... but it was accelerated > because of pensions being paid out of current revenue. in downturn, it > is possible for revenue to drop below the unfunded pension > obligations. Having previously looted fully-funded pension obligations > as profits ... then in any downturn they could reduce the number of > current employees ... but they couldn't reduce past pension > obligations. They eventually declare bankruptcy based on the unfuneded > pension obligation ... dumping the obligation off onto PBGC (no > "clawbacks" of previous payouts as profit instead of funding pensions). > http://www.pbgc.gov/ It is true steel wasn't investing in technologies, and yes, part of that was indeed a bad management decision. But I think part of it was that new technology was very expensive and they weren't sure of getting good returns on it, so they stuck with what they had. Also, some of their newest mills were built in the 1950s and while obsolete (still using open hearth), they weren't that old. Part of the problem with steel was that in the early 1960s they had granted extremely generous wage increases, and basically at that point priced themselves out of business. It was that, or sustain a very long strike. This applies to auto, too. Regarding pensions, clearly bankruptcy laws need to be redone to elevate pension obligations to the top of the pecking order, not the bottom. Too many companies, like the airlines, just walk away. Frankly, this is a disgrace. I don't understand why there isn't more of a public outcry over it. Supposedly, senior citizens are aggressive voters, but pensions do not seem to be a big issue. > another gimmick that industries used was changing the corporate > structure so that profit was moved from heavy people intensive part of > the business to subsidiary that required relatively few people. airline > industry did this by structuring airline operations as break-even and > moving profit to ticket (mostly computerized) subsidiary. The airline > operations can be showing no profit while the parent company shows > significant overall profit because the way it is booked with ticket > sales. Showing no profit or even loss gives advantage in union/employee > negotiations (even when parent company still shows significant profit > because of the way books are done). They can even declare bankruptcy for > the airline operations and dump the employee pension obligations on > PBGC. A number of years ago, the parent company of one of the auto big > three showed 5% of its profit from making cars, but 95% of its profit > from financing the selling of cars (it was even possible for the > making of cars shows loss while parent company is still showing > significant profit). > the books are cooked so the profit from operation that involves large > number of people making something are moved into a different subidiary > ... so the people-intensive operation shows break-even or loss. > The latest gimmick is that the subsidiary (where the profits are being > booked) is moved offshore ... so the profit shows up in an extremely > attractive tax haven. I don't know enough about accounting rules or government regulations to stop this clearly unethical practice. The Feds do have the power to regulate interstate commerce and can put a stop to it if they really wanted to, but these days 'regulation' is a bad word. Again, I don't understand how workers so screwed by this sort of thing are so passive about it.
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-03-08 08:18 -0800 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <87vb4xkko6.fsf@garlic.com> |
| In reply to | #160665 |
Anne & Lynn Wheeler <lynn@garlic.com> writes: > The latest gimmick is that the subsidiary (where the profits are being > booked) is moved offshore ... so the profit shows up in an extremely > attractive tax haven. > http://www.garlic.com/~lynn/submisc.html#tax.evasion Democrats and Republicans Are Quietly Planning a Corporate Giveaway -- to the Tune of $400 Billion http://www.thenation.com/article/democrats-and-republicans-are-quietly-planning-a-corporate-giveaway-to-the-tune-of-400-billion/ one of the poster child is heavy equipment maker that makes, sells, and delivers in the US; it changes to selling at cost to a new distributor subsidiary in Luxembourg, which sells to the buyers in the US (the equipment never leaves the US, delivered directly from US plant to US buyer. The difference is nearly all the profit is booked with the distributor Luxemberg (where trivial tax has been negotiated) http://www.icij.org/project/luxembourg-leaks -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-03-11 11:40 -0800 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <877fh8ls6n.fsf@garlic.com> |
| In reply to | #160708 |
Anne & Lynn Wheeler <lynn@garlic.com> writes: > http://www.icij.org/project/luxembourg-leaks latest from Luxembourg leaks Ministers agree to new EU rule to curb corporate tax dodging http://www.icij.org/blog/2016/03/ministers-agree-new-eu-rule-curb-corporate-tax-dodging cooking the books so that profit is moved offshore into subsidiary for tax evasion http://www.garlic.com/~lynn/submisc.html#tax.evasion ... but can also play gimmicks where human intensive operations are manipulated so that they have little or no profit ... which plays factor in benefit negotiations ... but can also setup for declaring bankruptcy and dump the pension obligations on the government http://www.pbgc.gov/ even while the parent company is making record profits. and now they are working on congress being able to bring the offshore trillions back home with little or no taxes http://www.thenation.com/article/democrats-and-republicans-are-quietly-planning-a-corporate-giveaway-to-the-tune-of-400-billion/ "private equity" (industry got such bad reputation during S&L crisis that they changed the industry name to "private equity" and junk bonds became "high-yield" bonds). They borrow the money to buy company, put the money on the victim company books, loot the company and then sell it off (make enormous profits even if they sell the company for less than they paid). Analogy to house flipping ... except they don't have to pay off the original loan (it now belongs to the victim company). Over half corporate defaults are companies currently or formaly owned by private equity http://www.nytimes.com/2009/10/05/business/economy/05simmons.html?_r=0 They make out with enormous profits and in addition also bought special tax loopholes from congress for the scam (and the defaulted loans for some reason never show up in the credit rating of the private equity firms). http://www.garlic.com/~lynn/submisc.html#private.equity -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2016-03-13 10:14 -0700 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <878u1mnvvd.fsf@garlic.com> |
| In reply to | #160868 |
Anne & Lynn Wheeler <lynn@garlic.com> writes: > http://www.icij.org/project/luxembourg-leaks > > latest from Luxembourg leaks > > Ministers agree to new EU rule to curb corporate tax dodging > http://www.icij.org/blog/2016/03/ministers-agree-new-eu-rule-curb-corporate-tax-dodging > > cooking the books so that profit is moved offshore into subsidiary > for tax evasion > http://www.garlic.com/~lynn/submisc.html#tax.evasion 27 Companies That Paid No Taxes http://ritholtz.com/2016/03/27-companies-that-paid-no-taxes/ 27 giant profitable companies paid no taxes http://www.usatoday.com/story/money/markets/2016/03/07/27-giant-profitable-companies-paid-no-taxes/81399094/ other drift It Turns Out the Koch Brothers Took an Interest in the VA Hospital System http://www.esquire.com/news-politics/politics/news/a42938/koch-brothers-va-hospitals/ We consulted on dataprocessing modernization (replacing what was used for 1980 & 1990 census) for the 2000 census ... essentially for out-of-pocket expenses). When census had all day audit on the effort, I was asked to stand in front of the room and answer all the questions. We then made an offer to do something similar for the VA, meeting with the head VA staffer on the hill ... VA was just coming off a multiple billion dollar dataprocessing modernization failure and gearing up for the next one. Turns out that such offers are major threat to the beltway bandits and their "Success of Failure" culture (not limited to intelligence agencies) http://www.govexec.com/excellence/management-matters/2007/04/the-success-of-failure/24107/ past posts http://www.garlic.com/~lynn/submisc.html#success.of.failure -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | "Sangmo" <ju410@gmail.com> |
|---|---|
| Date | 2016-03-07 13:37 +1100 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <dk47rbF1gblU1@mid.individual.net> |
| In reply to | #160631 |
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote in message news:nbikj4213ig@news3.newsguy.com... > On 2016-03-06, Dan Espen <despen@verizon.net> wrote: > >> Anne & Lynn Wheeler <lynn@garlic.com> writes: >> >>> Dan Espen <despen@verizon.net> writes: >>> >>>> Any decent company would have written you up as the discoverer of >>>> a short coming in the existing product line that needed to be >>>> corrected ASAP. >>> >>> I was still undergraduate at the univ (before I joined Boeing and then >>> IBM). Close as I can tell they hardwired the line speed to each port on >>> purpose ... because there was no easy way to dynamically change line >>> speed. The interdata was programmed to strobe the signal rise/fall to >>> determine terminal speed. >>> >>> standard IBM operating system support (other than cp67) didn't even >>> bother with dynamic termeinal type identification ... "sysgen" required >>> terminal type explicitly defined for each line/port. >> >> One of the BTAM systems I supported matched up S/360 UCBs and remote >> printers based on line speed (and other things). >> >> If customers want something you're not selling, whose fault is that? > > Your marketing department, which hasn't convinced the customers to > want what you're selling. Not even possible with something like that hardwired line speed.
[toc] | [prev] | [next] | [standalone]
| From | jmfbahciv <See.above@aol.com> |
|---|---|
| Date | 2016-03-06 14:08 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <PM00052D61CBDB6CCA@aca4072c.ipt.aol.com> |
| In reply to | #160583 |
hancock4@bbs.cpcn.com wrote: > On Saturday, March 5, 2016 at 11:14:37 AM UTC-5, D_J_E wrote: > >> I'm not aware of any 3rd party device drivers for OS/360. >> Even still, I believe I've heard of 3rd party software incompatible >> with new z/OS releases. > > When independent companies began to develop their own peripherals for > S/360, didn't they also have to develop device drivers for their > devices? Or, were their devices exact clones of IBM devices, so > they looked the same to the machine and program? > > Also, when independents, for example Syncsort, develop mainframe > utilities, don't they do fancy stuff at a low level in order to > optimize performance? If an independent company had developed a device for DEC systems, they had to use the values which DEC had reserved for customer use. that would ensure that anything DEC manufactured would not conflict with the independent company's hardware. We did similar customer reserved values for software, including the monitor (kernal). /BAH
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-03-06 11:24 -0800 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <48a0b7b6-18ea-41a2-a07a-6c5c22b58013@googlegroups.com> |
| In reply to | #160605 |
On Sunday, March 6, 2016 at 9:08:54 AM UTC-5, jmfbahciv wrote: > If an independent company had developed a device for DEC systems, > they had to use the values which DEC had reserved for customer > use. that would ensure that anything DEC manufactured would > not conflict with the independent company's hardware. Was there a lot of third party hardware developed for DEC systems-- as a competitive replacement for a DEC product (not a specialty add-on)? That is, someone saying, "here, my tape drive is cheaper than DEC's but just as good"? Indeed, if memory serves, DEC's terminals were widely copied; I recalled "VT101" compatibility being widely advertised (or was it VT102?) I presume that given DEC computers were used in many labs, that all sorts of measuring equipment was attached to DEC computers, and obviously had to meet protocol requirements. > > We did similar customer reserved values for software, including > the monitor (kernal). > ...
[toc] | [prev] | [next] | [standalone]
| From | "Sangmo" <ju410@gmail.com> |
|---|---|
| Date | 2016-03-07 07:34 +1100 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <dk3ihtFr0c4U1@mid.individual.net> |
| In reply to | #160615 |
<hancock4@bbs.cpcn.com> wrote in message news:48a0b7b6-18ea-41a2-a07a-6c5c22b58013@googlegroups.com... > On Sunday, March 6, 2016 at 9:08:54 AM UTC-5, jmfbahciv wrote: > > >> If an independent company had developed a device for DEC systems, >> they had to use the values which DEC had reserved for customer >> use. that would ensure that anything DEC manufactured would >> not conflict with the independent company's hardware. > > Was there a lot of third party hardware developed for DEC systems-- > as a competitive replacement for a DEC product (not a specialty add-on)? > That is, someone saying, "here, my tape drive is cheaper than DEC's but > just as good"? Yep, heaps of that with all of tape drives, disk drives, terminals, printers etc etc etc. > Indeed, if memory serves, DEC's terminals were widely copied; I > recalled "VT101" compatibility being widely advertised (or was it VT102?) VT100. > I presume that given DEC computers were used in many labs, that > all sorts of measuring equipment was attached to DEC computers, Yes, but often just appeared to the computer as a terminal. > and obviously had to meet protocol requirements. Only at the most primitive level. The higher levels were up to the app, not the OS or driver. >> We did similar customer reserved values for software, including >> the monitor (kernal).
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-03-06 17:25 -0700 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <430664300.479002883.880667.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #160615 |
<hancock4@bbs.cpcn.com> wrote: > On Sunday, March 6, 2016 at 9:08:54 AM UTC-5, jmfbahciv wrote: > > >> If an independent company had developed a device for DEC systems, >> they had to use the values which DEC had reserved for customer >> use. that would ensure that anything DEC manufactured would >> not conflict with the independent company's hardware. > > Was there a lot of third party hardware developed for DEC systems-- > as a competitive replacement for a DEC product (not a specialty add-on)? > That is, someone saying, "here, my tape drive is cheaper than DEC's but > just as good"? > > Indeed, if memory serves, DEC's terminals were widely copied; I > recalled "VT101" compatibility being widely advertised (or was it VT102?) VT100 for a long time. This was one of the usual personalities for PC terminal emutators. > > I presume that given DEC computers were used in many labs, that all > sorts of measuring equipment was attached to DEC computers, and > obviously had to meet protocol requirements. > I don't know about DEC, but a lot of lab stuff used the equivalent of parallel ports for communication. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | "Sangmo" <ju410@gmail.com> |
|---|---|
| Date | 2016-03-07 12:14 +1100 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <dk430bFejuU1@mid.individual.net> |
| In reply to | #160629 |
"Peter Flass" <peter_flass@yahoo.com> wrote in message news:430664300.479002883.880667.peter_flass-yahoo.com@news.eternal-september.org... > <hancock4@bbs.cpcn.com> wrote: >> On Sunday, March 6, 2016 at 9:08:54 AM UTC-5, jmfbahciv wrote: >> >> >>> If an independent company had developed a device for DEC systems, >>> they had to use the values which DEC had reserved for customer >>> use. that would ensure that anything DEC manufactured would >>> not conflict with the independent company's hardware. >> >> Was there a lot of third party hardware developed for DEC systems-- >> as a competitive replacement for a DEC product (not a specialty add-on)? >> That is, someone saying, "here, my tape drive is cheaper than DEC's but >> just as good"? >> >> Indeed, if memory serves, DEC's terminals were widely copied; I >> recalled "VT101" compatibility being widely advertised (or was it VT102?) > > VT100 for a long time. This was one of the usual personalities for PC > terminal emutators. > >> >> I presume that given DEC computers were used in many labs, that all >> sorts of measuring equipment was attached to DEC computers, and >> obviously had to meet protocol requirements. >> > > I don't know about DEC, but a lot of lab stuff used the equivalent of > parallel ports for communication. We never saw a lot of that with DEC stuff. Quite a bit of lab stuff used GPIB/IEEE-488 which did have a DEC adapter.
[toc] | [prev] | [next] | [standalone]
| From | pechter@mongo.(none) (William Pechter) |
|---|---|
| Date | 2016-03-07 02:49 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <nbiq85$i53$1@pechter.eternal-september.org> |
| In reply to | #160633 |
In article <dk430bFejuU1@mid.individual.net>, Sangmo <ju410@gmail.com> wrote:
>
>
>"Peter Flass" <peter_flass@yahoo.com> wrote in message
>news:430664300.479002883.880667.peter_flass-yahoo.com@news.eternal-september.org...
>> <hancock4@bbs.cpcn.com> wrote:
>>> On Sunday, March 6, 2016 at 9:08:54 AM UTC-5, jmfbahciv wrote:
>>>
>>>
>>>> If an independent company had developed a device for DEC systems,
>>>> they had to use the values which DEC had reserved for customer
>>>> use. that would ensure that anything DEC manufactured would
>>>> not conflict with the independent company's hardware.
>>>
>>> Was there a lot of third party hardware developed for DEC systems--
>>> as a competitive replacement for a DEC product (not a specialty add-on)?
>>> That is, someone saying, "here, my tape drive is cheaper than DEC's but
>>> just as good"?
>>>
>>> Indeed, if memory serves, DEC's terminals were widely copied; I
>>> recalled "VT101" compatibility being widely advertised (or was it VT102?)
>>
>> VT100 for a long time. This was one of the usual personalities for PC
>> terminal emutators.
>>
>>>
>>> I presume that given DEC computers were used in many labs, that all
>>> sorts of measuring equipment was attached to DEC computers, and
>>> obviously had to meet protocol requirements.
>>>
>>
>> I don't know about DEC, but a lot of lab stuff used the equivalent of
>> parallel ports for communication.
>
>We never saw a lot of that with DEC stuff.
Actually the DR11-B and the DR11-W (iirc) were commonly used parallel
interconnects (IIRC the DR11-B was full 16 bit wide with DMA and the DR11-W
was non-DMA). They were often used for interprocessor parallel links
as well as driving stuff on other busses from the DEC Unibus..
Some PDP11 sites used it as a cpu-to-cpu parallel link to do interprocessor
communications and syncronization...
Most of the common workstations with VME or Multibus had DR11's available. It
looks like Ikon corporation made them for everything including PCI busses.
http://www.tahomatech.com/About.htm
http://www.tahomatech.com/OlderProducts.htm
>
>Quite a bit of lab stuff used GPIB/IEEE-488 which did have a DEC adapter.
>
Yup, but I think the DR11 came out well before the IEEE-488. The DR11 manual
on bitsavers has a copyright date starting in 1971.
Bill
--
---
Three things never anger: First, the one who runs your DEC,
The one who does Field Service and the one who signs your check.
--pechter_at_gmail.com
[toc] | [prev] | [next] | [standalone]
| From | "Sangmo" <ju410@gmail.com> |
|---|---|
| Date | 2016-03-07 15:47 +1100 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <dk4felF33nqU1@mid.individual.net> |
| In reply to | #160643 |
"none (William Pechter)" <pechter@mongo.> wrote in message news:nbiq85$i53$1@pechter.eternal-september.org... > In article <dk430bFejuU1@mid.individual.net>, Sangmo <ju410@gmail.com> > wrote: >> >> >>"Peter Flass" <peter_flass@yahoo.com> wrote in message >>news:430664300.479002883.880667.peter_flass-yahoo.com@news.eternal-september.org... >>> <hancock4@bbs.cpcn.com> wrote: >>>> On Sunday, March 6, 2016 at 9:08:54 AM UTC-5, jmfbahciv wrote: >>>> >>>> >>>>> If an independent company had developed a device for DEC systems, >>>>> they had to use the values which DEC had reserved for customer >>>>> use. that would ensure that anything DEC manufactured would >>>>> not conflict with the independent company's hardware. >>>> >>>> Was there a lot of third party hardware developed for DEC systems-- >>>> as a competitive replacement for a DEC product (not a specialty >>>> add-on)? >>>> That is, someone saying, "here, my tape drive is cheaper than DEC's but >>>> just as good"? >>>> >>>> Indeed, if memory serves, DEC's terminals were widely copied; I >>>> recalled "VT101" compatibility being widely advertised (or was it >>>> VT102?) >>> >>> VT100 for a long time. This was one of the usual personalities for PC >>> terminal emutators. >>> >>>> >>>> I presume that given DEC computers were used in many labs, that all >>>> sorts of measuring equipment was attached to DEC computers, and >>>> obviously had to meet protocol requirements. >>>> >>> >>> I don't know about DEC, but a lot of lab stuff used the equivalent of >>> parallel ports for communication. >> >>We never saw a lot of that with DEC stuff. > > Actually the DR11-B and the DR11-W (iirc) were commonly used parallel > interconnects (IIRC the DR11-B was full 16 bit wide with DMA and the > DR11-W was non-DMA). They were often used for interprocessor parallel > links as well as driving stuff on other busses from the DEC Unibus.. Yes, but we didn’t see a lot of lab stuff done that way. > Some PDP11 sites used it as a cpu-to-cpu parallel link to do > interprocessor > communications and syncronization... > Most of the common workstations with VME or Multibus had DR11's available. > It looks like Ikon corporation made them for everything including PCI > busses. > http://www.tahomatech.com/About.htm > http://www.tahomatech.com/OlderProducts.htm Sure, but like I said, not a lot of lab stuff was done that way. >> Quite a bit of lab stuff used GPIB/IEEE-488 which did have a DEC adapter. > Yup, but I think the DR11 came out well before the IEEE-488. Yes it did. But like I said not a lot of lab stuff was done that way. I used the A/D converter myself. > The DR11 manual on bitsavers has a copyright date starting in 1971. HP did use the IEEE-488 extensively for lab stuff.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence Statton NK1G <lawrence@senguio.mx> |
|---|---|
| Date | 2016-03-06 19:54 -0600 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <87pov7xdat.fsf@senguio.mx> |
| In reply to | #160629 |
Peter Flass <peter_flass@yahoo.com> writes: > I don't know about DEC, but a lot of lab stuff used the equivalent of > parallel ports for communication. Some years later (late 80s) we were using DRV11 general-purpose 64-bit parallel interfaces on Q-Bus machines for instrumentation. --NK1G
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2016-03-05 12:02 -0600 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <nbf6qk$ve4$1@dont-email.me> |
| In reply to | #160570 |
On 04-Mar-16 20:31, Peter Flass wrote: > Morten Reistad <first@last.name.invalid> wrote: >> The problem about this driver menagerie has been stated many times >> by core windows maintainers as the main problem affecting windows >> operatonal stability. The problem isn't so much the stability of >> the drivers as they are initially developed, but the maintenence >> along subsequent windows releases. > > Why would the driver interface have to change from release to > release. That has always seemed to me to be the biggest > weakness/problem of windows: > ... > Look at zOS, where the basic OS/360 interface is still there, though > buried. Users have no need to change their code for each release. APIs are relatively stable; Windows is on only its third version, and the second one still works fine. POSIX is even more stable. Device drivers are different because the entire kernel is exposed, in effect making the kernel implementation itself the API. There are APIs driver developers are _supposed_ to use, but nothing stops them from coloring outside the lines, and if what's outside the lines changes, their driver breaks--and since drivers run in a kernel context, that can take down the entire kernel. This is why MS instituted WHQL testing and will only bundle or auto-update WHQL-certified drivers, which radically improved the stability of Windows virtually overnight. > the developers seem to change stuff just for the sake of changing > stuff. I've _never_ met developers who did that. Marketing people, sure; they often see change (even for the worse) as valuable differentiator. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-03-05 14:53 -0800 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <b67b926d-3545-4e98-8236-a3b415eb2fd2@googlegroups.com> |
| In reply to | #160584 |
On Saturday, March 5, 2016 at 1:02:53 PM UTC-5, Stephen Sprunk wrote: > > the developers seem to change stuff just for the sake of changing > > stuff. > > I've _never_ met developers who did that. Marketing people, sure; they > often see change (even for the worse) as valuable differentiator. Lots of the computer folks have always liked to get as fancy as they could, even if the requirements do not call for certain features. This goes all the way back, even Feynman documented it in the early days. One of the challenges computer manufacturers had was putting the brakes on designers who wanted to do it all. Machines had to meet cost and delivery constraints, and excess design would overrun the plans. Further, excess design would add complexity making maintenance harder. (Likewise in programming--fancy programming can be a maintenance nightmare). Sure, some crazy designs are the result of marketing people. But a lot of stuff comes from the developers. Of course, some innovation is needed. I don't think any of us would want to have this conversation on a 10 char/sec Teletype, not even me. But on the other hand, sometimes change is unnecessary, even disruptive. One example of a bad change: Google is supposedly this super smart company, right? Well, it has a service, Google Groups. The old one worked perfectly fine. For whatever reason, they came up with a radically new version that is full of bugs, is very bloated and runs slow using tons of memory, and actually offers less features. So why did they did this? Why did they spend the money? It does not bring in more ad revenue.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2016-03-05 23:42 +0000 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <nbfqso0lgj@news6.newsguy.com> |
| In reply to | #160589 |
On 2016-03-05, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote: > On Saturday, March 5, 2016 at 1:02:53 PM UTC-5, Stephen Sprunk wrote: > >>> the developers seem to change stuff just for the sake of changing >>> stuff. >> >> I've _never_ met developers who did that. Marketing people, sure; they >> often see change (even for the worse) as valuable differentiator. At a sales conference I was once forced to attend, the marketroids proudly trumpeted the term "product differentiation". When you read between the lines, this is exactly what they were talking about: making their product different, even if it meant screwing it up. > Lots of the computer folks have always liked to get as fancy as > they could, even if the requirements do not call for certain features. > This goes all the way back, even Feynman documented it in the early days. > > One of the challenges computer manufacturers had was putting the brakes > on designers who wanted to do it all. Machines had to meet cost and > delivery constraints, and excess design would overrun the plans. > Further, excess design would add complexity making maintenance harder. > (Likewise in programming--fancy programming can be a maintenance > nightmare). > > Sure, some crazy designs are the result of marketing people. But a > lot of stuff comes from the developers. Fred Brooks, in his book "The Mythical Man-Month", talks about the "second system effect". That's when developers try to stuff in every feature they missed in the first version (or thought about after release). The result, if not controlled, can be disaster. > Of course, some innovation is needed. I don't think any of us would > want to have this conversation on a 10 char/sec Teletype, not even me. > But on the other hand, sometimes change is unnecessary, even disruptive. Funny how "disruptive technology" has become a hot new buzzword. > One example of a bad change: Google is supposedly this super smart > company, right? Well, it has a service, Google Groups. The old > one worked perfectly fine. For whatever reason, they came up with > a radically new version that is full of bugs, is very bloated and > runs slow using tons of memory, and actually offers less features. > So why did they did this? Why did they spend the money? It does not > bring in more ad revenue. But what self-respecting luser would want to be seen running last week's software? Ease of use is often a matter of perception. I've seen people spending all sorts of time pointing and clicking and pointing and clicking their way through a fancy GUI where a few simple keystrokes would get the job done much more quickly. And all the while they'll exclaim how easy to use the new system is. All too often, fancy GUIs are just video games. -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2016-03-05 21:57 -0800 |
| Subject | Re: Qbasic - lies about Medicare |
| Message-ID | <38f9fbde-1217-4cb3-8d26-bd10eb342d87@googlegroups.com> |
| In reply to | #160591 |
On Saturday, March 5, 2016 at 6:40:54 PM UTC-5, Charlie Gibbs wrote: > At a sales conference I was once forced to attend, the marketroids > proudly trumpeted the term "product differentiation". When you > read between the lines, this is exactly what they were talking about: > making their product different, even if it meant screwing it up. Sad. They're focused on making a product 'different', but not necessarily _better_ than the competition. (When I was a kid, we were taught that business grew because they made things better than their competitors.) On the other hand, I must admit I do feel sorry for marketers at say a laundry detergent company. Laundry detergents haven't changed much, but they have to constantly come up with new graphics for the container, and new ways to say "NEW AND IMPROVED". (I don't understand why they switched from powder to liquid. I think the liquid costs more to make and ship than powder. Was it just marketing?) > Fred Brooks, in his book "The Mythical Man-Month", talks about the > "second system effect". That's when developers try to stuff in every > feature they missed in the first version (or thought about after > release). The result, if not controlled, can be disaster. Thanks for the reference. Brooks is still around, up in years, but AFAIK, still kicking. > Funny how "disruptive technology" has become a hot new buzzword. That I didn't know. But it's about time. Actually, there isn't anything wrong with new technology in itself. The tricky part is how it's rolled and what is expected of it. As mentioned, the old Bell System always tried new technology in a test area first to see how it functioned in service; then they would roll it out nationwide. Some new stuff didn't work at first, such as electronic ringers, or the earliest pushbutton phones (using plucked reeds). When dial came along, they sent out people from door to door to teach folks out to use their new dial phone. They also had displays and even films (which can be seen online now). When direct long distance dialing came out, which merely added an area code, they again put out a big instructional effort. In my humble opinion, the change of technology for computer users is too fast. Lay users are forced to spend a lot of time learning new operating systems and applications; by the time they're done, something new has come out and they have to start all over again. Let's take MS-Word. I learned Ver 6 years ago. It is an extremely powerful product, doing everything and anything I could possible want in word processing, and even desktop publishing. (I'll note at this point that a number of famous authors manage to write classics using a plain typewriter). But anyway, M/S goes and makes a big change, macros won't work, stuff is all moved around. So I go and learn it, but it's not as convenient for me to use. Oh well. They go out and make another major change, really shifting everything around. It's really hard to find stuff in the menus--stuff that used to be right up front is now hidden in secondary menus that are hard to find. I must admit one time I had to get a letter out and just didn't have time to screw around with word. I used Notepad like a typewriter and pounded it out. I use the old Word-6 at home, but when I get a new machine that probably won't even work anymore. But that's good for M/S, since I'll have to buy a new copy of Office when I get the new machine. > But what self-respecting luser would want to be seen running last > week's software? Indeed, some people do tease me for using an old web browser. I've basically switched to Firefox, though that is far from reliable. > Ease of use is often a matter of perception. I've seen people spending > all sorts of time pointing and clicking and pointing and clicking their > way through a fancy GUI where a few simple keystrokes would get the job > done much more quickly. And all the while they'll exclaim how easy to > use the new system is. All too often, fancy GUIs are just video games. I think I want my Teletype back. A nice 33, with the built in modem and control buttons.
[toc] | [prev] | [next] | [standalone]
Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web