Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #212313 > unrolled thread
| Started by | Iron Spring Software <Peter_Flass@Yahoo.com> |
|---|---|
| First post | 2020-07-24 09:38 -0700 |
| Last post | 2020-07-30 20:27 +0000 |
| Articles | 20 on this page of 164 — 35 participants |
Back to article view | Back to alt.folklore.computers
DEC Iron Spring Software <Peter_Flass@Yahoo.com> - 2020-07-24 09:38 -0700
Re: DEC Mike Spencer <mds@bogus.nodomain.nowhere> - 2020-07-24 17:12 -0300
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-24 17:14 -0400
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-24 19:43 -0700
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-24 23:28 -0400
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-25 02:06 -0700
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 05:27 -0400
Re: DEC Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-25 10:58 +0100
Re: 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-07-25 17:21 +0000
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 13:54 -0400
Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 14:43 -0700
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 18:05 -0400
Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 20:27 -0400
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-25 21:08 -0400
Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 23:29 -0400
Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 23:30 -0400
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-26 00:06 -0400
Re: 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-05 06:06 +0000
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-07 10:19 -0400
Re: 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-07 20:01 +0000
Re: wiki software, not 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-08-07 22:45 +0000
Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-08 13:35 -0400
Re: wiki software, not 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-09 15:33 +0000
Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-09 13:16 -0400
Re: wiki software, not 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-08-09 15:00 -0400
Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-09 18:35 -0400
Re: wiki software, not 360 PCs was DEC maus <maus@dmaus.org> - 2020-08-10 23:10 +0000
Re: wiki software, not 360 PCs was DEC Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-09 19:18 +0000
Re: wiki software, not 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-09 18:40 -0400
Re: wiki software, not 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-09 15:30 -0700
Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 18:39 -0700
Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 18:43 -0700
Re: 360 PCs was DEC Dan Espen <dan1espen@gmail.com> - 2020-07-25 23:32 -0400
Re: 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-07-26 21:45 +0000
Re: 360 PCs was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-26 18:01 -0400
Re: 360 PCs was DEC Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-27 06:38 +0100
Re: 360 PCs was DEC John Levine <johnl@taugh.com> - 2020-07-26 01:24 +0000
Re: 360 PCs was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-25 18:39 -0700
Re: 360 PCs was DEC Bob Eager <news0073@eager.cx> - 2020-07-26 20:18 +0000
Re: 360 PCs was DEC Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-25 19:39 +0100
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-25 12:50 -0700
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-25 02:26 -0700
Re: DEC usenet@only.tnx (Questor) - 2020-07-26 19:23 +0000
Re: DEC Thomas Koenig <tkoenig@netcologne.de> - 2020-07-26 21:05 +0000
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-26 16:23 -0700
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-26 21:24 -0400
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-27 11:42 -0700
Re: DEC archaeology John Levine <johnl@taugh.com> - 2020-07-27 02:41 +0000
Re: DEC archaeology Andy Burns <usenet@andyburns.uk> - 2020-07-27 07:37 +0100
Re: DEC archaeology Thomas Koenig <tkoenig@netcologne.de> - 2020-07-27 07:10 +0000
Re: DEC archaeology Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-27 09:03 +0100
Re: DEC archaeology Michael LeVine <mlevinespmfltr@redshift.com> - 2020-07-27 02:09 -0700
Re: DEC archaeology Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-27 11:27 +0100
Origin of Niven/Pournelle quips (was: DEC archaeology) Thomas Koenig <tkoenig@netcologne.de> - 2020-07-27 12:22 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Rich Alderson <news@alderson.users.panix.com> - 2020-07-27 20:51 -0400
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-28 06:02 +0100
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Bob Eager <news0073@eager.cx> - 2020-07-28 08:29 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-07-28 17:30 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) djheydt@kithrup.com (Dorothy J Heydt) - 2020-07-28 18:18 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Bob Eager <news0073@eager.cx> - 2020-07-28 19:57 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-28 21:32 +0100
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) djheydt@kithrup.com (Dorothy J Heydt) - 2020-07-28 21:34 +0000
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) J. Clarke <jclarke.873638@gmail.com> - 2020-07-28 18:33 -0400
Re: Origin of Niven/Pournelle quips (was: DEC archaeology) Ahem A Rivet's Shot <steveo@eircom.net> - 2020-07-28 20:55 +0100
Re: DEC archaeology John Levine <johnl@taugh.com> - 2020-07-27 14:53 +0000
Re: DEC archaeology drb@ihatespam.msu.edu (Dennis Boone) - 2020-07-27 11:30 -0500
Re: DEC archaeology scott@slp53.sl.home (Scott Lurndal) - 2020-07-27 16:37 +0000
Re: DEC archaeology drb@ihatespam.msu.edu (Dennis Boone) - 2020-07-28 10:24 -0500
Re: DEC archaeology scott@slp53.sl.home (Scott Lurndal) - 2020-07-28 15:59 +0000
Re: DEC archaeology Peter Flass <peter_flass@yahoo.com> - 2020-07-27 11:42 -0700
Re: DEC archaeology J. Clarke <jclarke.873638@gmail.com> - 2020-07-27 18:47 -0400
Re: DEC archaeology Quadibloc <jsavard@ecn.ab.ca> - 2020-07-27 17:43 -0700
Re: DEC usenet@only.tnx (Questor) - 2020-07-28 03:21 +0000
Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-07-28 17:30 +0000
Re: ou sont les ordinateurs d'antan, was DEC John Levine <johnl@taugh.com> - 2020-07-28 20:27 +0000
Re: ou sont les ordinateurs d'antan, was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-07-28 18:53 -0400
Re: ou sont les ordinateurs d'antan, was DEC Gareth Evans <headstone255@yahoo.com> - 2020-07-29 10:36 +0100
Re: ou sont les ordinateurs d'antan, was DEC Andreas Eder <a_eder_muc@web.de> - 2020-08-02 12:55 +0200
Re: ou sont les ordinateurs d'antan, was DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-02 12:49 -0400
Re: ou sont les ordinateurs d'antan, was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-29 14:08 -0700
Re: ou sont les ordinateurs d'antan, was DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-29 14:04 -0700
Re: DEC Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2020-07-30 03:49 -0600
Re: DEC scott@slp53.sl.home (Scott Lurndal) - 2020-07-30 14:41 +0000
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-30 10:12 -0700
Re: DEC scott@slp53.sl.home (Scott Lurndal) - 2020-07-30 18:40 +0000
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-07-30 12:02 -0700
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-07-31 02:38 -0700
Re: DEC large computers John Levine <johnl@taugh.com> - 2020-07-31 20:21 +0000
Re: DEC large computers Thomas Koenig <tkoenig@netcologne.de> - 2020-07-31 23:23 +0000
Re: DEC large computers J. Clarke <jclarke.873638@gmail.com> - 2020-07-31 21:13 -0400
Re: DEC large computers Thomas Koenig <tkoenig@netcologne.de> - 2020-08-01 10:39 +0000
Re: vectors, was DEC large computers John Levine <johnl@taugh.com> - 2020-08-01 02:21 +0000
Re: vectors, was DEC large computers Bob Eager <news0073@eager.cx> - 2020-08-01 11:14 +0000
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-07-31 20:30 -0700
Re: IBM models 91, 195 & CDC 7600 Dan Espen <dan1espen@gmail.com> - 2020-08-01 00:00 -0400
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:20 -0700
Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-01 07:00 -0700
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 08:18 -0700
Re: IBM models 91, 195 & CDC 7600 Dan Espen <dan1espen@gmail.com> - 2020-08-01 11:52 -0400
Re: IBM models 91, 195 & CDC 7600 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-02 21:58 +0000
Re: IBM models 91, 195 & CDC 7600 Dan Espen <dan1espen@gmail.com> - 2020-08-02 18:50 -0400
Re: IBM models 91, 195 & CDC 7600 Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-03 18:23 +0000
Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-03 13:34 -0700
Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-01 00:55 -0700
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:27 -0700
Re: IBM models 91, 195 & CDC 7600 John Levine <johnl@taugh.com> - 2020-08-01 17:27 +0000
Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-01 12:11 -0700
Re: IBM models 91, 195 & CDC 7600 Bob Eager <news0073@eager.cx> - 2020-08-01 19:56 +0000
Re: IBM models 91, 195 & CDC 7600 John Levine <johnl@taugh.com> - 2020-08-01 20:18 +0000
Re: IBM models 91, 195 & CDC 7600 Bob Eager <news0073@eager.cx> - 2020-08-01 23:42 +0000
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 20:32 -0700
Re: IBM models 91, 195 & CDC 7600 Gerard Schildberger <gerard46@rrt.net> - 2020-08-02 12:58 -0700
Re: IBM models 91, 195 & CDC 7600 J. Clarke <jclarke.873638@gmail.com> - 2020-08-01 16:28 -0400
Re: IBM models 91, 195 & CDC 7600 David Lesher <wb8foz@panix.com> - 2020-08-02 20:42 +0000
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 20:27 -0700
Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-02 00:28 -0700
Re: IBM models 91, 195 & CDC 7600 Thomas Koenig <tkoenig@netcologne.de> - 2020-08-02 08:01 +0000
Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 16:47 -0700
Re: IBM models 91, 195 & CDC 7600 Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 19:45 -0700
Re: IBM models 91, 195 & CDC 7600 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-08-03 21:00 -0600
Re: IBM models 91, 195 & CDC 7600 scott@slp53.sl.home (Scott Lurndal) - 2020-08-02 22:45 +0000
Re: IBM models 91, 195 & CDC 7600 Peter Flass <peter_flass@yahoo.com> - 2020-08-03 07:45 -0700
Re: IBM models 91, 195 & CDC 7600 "Kerr-Mudd,John" <notsaying@127.0.0.1> - 2020-08-01 08:24 +0000
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:30 -0700
Re: IBM models 91, 195 & CDC 7600 robin.vowels@gmail.com - 2020-08-01 02:34 -0700
Re: DEC large computers Quadibloc <jsavard@ecn.ab.ca> - 2020-08-01 00:51 -0700
Re: DEC large computers robin.vowels@gmail.com - 2020-08-01 02:23 -0700
Jupiter alternatives [was Re: DEC] Rich Alderson <news@alderson.users.panix.com> - 2020-07-31 21:16 -0400
Re: Jupiter alternatives [was Re: DEC] Robert Swindells <rjs@fdy2.co.uk> - 2020-08-01 01:56 +0000
Re: Jupiter alternatives [was Re: DEC] Adam Sampson <ats@offog.org> - 2020-08-01 15:59 +0100
Re: Jupiter alternatives [was Re: DEC] Rich Alderson <news@alderson.users.panix.com> - 2020-08-01 22:09 -0400
Re: Jupiter alternatives [was Re: DEC] Rich Alderson <news@alderson.users.panix.com> - 2020-08-01 22:07 -0400
Re: DEC usenet@only.tnx (Questor) - 2020-08-03 00:32 +0000
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-02 23:54 -0700
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-03 07:45 -0700
Re: DEC robin.vowels@gmail.com - 2020-08-03 09:16 -0700
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 10:10 -0700
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-03 10:35 -0700
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-03 11:28 -0700
Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-03 21:26 +0000
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-08-03 16:38 -0700
Re: DEC Dan Espen <dan1espen@gmail.com> - 2020-08-03 21:44 -0400
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-03 23:55 -0700
Re: DEC Dan Espen <dan1espen@gmail.com> - 2020-08-04 08:05 -0400
Re: DEC J. Clarke <jclarke.873638@gmail.com> - 2020-08-04 08:59 -0400
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-04 06:29 -0700
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-04 07:48 -0700
Re: DEC Niklas Karlsson <anksil@yahoo.se> - 2020-08-05 04:13 +0000
Re: DEC robin.vowels@gmail.com - 2020-08-04 22:45 -0700
Re: DEC JimP <chucktheouch@gmail.com> - 2020-08-05 12:33 -0500
Re: DEC "Kerr-Mudd,John" <notsaying@127.0.0.1> - 2020-08-05 19:31 +0000
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-04 22:57 -0700
Re: DEC Bob Eager <news0073@eager.cx> - 2020-08-05 08:13 +0000
Re: DEC Peter Flass <peter_flass@yahoo.com> - 2020-08-05 10:58 -0700
Re: DEC drb@ihatespam.msu.edu (Dennis Boone) - 2020-08-05 13:28 -0500
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-06 16:21 -0700
Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-03 18:23 +0000
Re: DEC Terry Kennedy <terry-groups@glaver.org> - 2020-08-03 11:31 -0700
Re: DEC danny burstein <dannyb@panix.com> - 2020-08-03 18:38 +0000
Re: DEC "m. thompson" <michael.99.thompson@gmail.com> - 2020-08-04 05:38 -0700
Re: DEC Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-08-04 18:54 +0000
Re: DEC usenet@only.tnx (Questor) - 2020-08-03 00:32 +0000
Re: DEC Quadibloc <jsavard@ecn.ab.ca> - 2020-07-30 13:29 -0700
Re: DEC usenet@only.tnx (Questor) - 2020-07-30 20:27 +0000
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2020-08-02 18:50 -0400 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <rg7fv7$u18$1@dont-email.me> |
| In reply to | #212506 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> writes: > On 2020-08-01, Dan Espen <dan1espen@gmail.com> wrote: > >> robin.vowels@gmail.com writes: >> >>> On Sunday, August 2, 2020 at 12:00:54 AM UTC+10, Peter Flass wrote: >>> >>>> I don’t think I found much need to increment a word in memory. For >>>> indexing the value would be kept in a register, or would have to be >>>> loaded before use anyhow. >>> >>> There is a limited number of registers. >>> >>> When tallying a number of variables (including separate elements of an >>> array), incrementing a memory word would be very handy. >>> >>> Even if, for normal indexing, a variable need to be loaded for that >>> purpose, it would still be more economical to increment memory, then >>> load it to register for indexing (2 instructions instead of 3). > > Still, there are tricks for conserving registers. You can get away > with using registers 15, 0, and 1 in a BXLE loop, for instance. > >> Seems to me, I've seen more than 1 page counter declared as binary. >> Because every one knows binary arithmetic is more efficient. >> >> :) > > As opposed to the CS weenie who wrote a COBOL program full of > subscript handling, and declared all the subscripts as COMP-3. I was assigned to a project at an insurance company as a consultant. The client had a large COBOL program to do some heavy statistics calculations. They checked the IBM documentation on coding rules. Some of the rules: Name all constants. Keep all fields the same size. Keep everything the same usage, packed. So, they had some big numbers, so they made all fields S9(7)V9(5). They named constants like this: 01 ONE PIC S9(7)V9(5) COMP-3 VALUE 1. There were lots of calculations with reciprocals like this: DIVIDE ONE BY VAR-NAME GIVING RESULT-NAME. The programmer was pretty bright, just mislead.. I took a quick look at the generated assembler code and just about every calculation converted packed to float and back again. They didn't have the floating point feature installed, all the calculations were done in library routines. Full test runs took days. Even their tiny sample data test took hours. I got rid of all the crap and submitted a test. The operator wrote on the test results that the job didn't run. It ran fine, it only took a few seconds. Good times. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2020-08-03 18:23 +0000 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <rg9kmv01mk9@news3.newsguy.com> |
| In reply to | #212510 |
On 2020-08-02, Dan Espen <dan1espen@gmail.com> wrote: > I got rid of all the crap and submitted a test. > The operator wrote on the test results that the job didn't run. > It ran fine, it only took a few seconds. I did that once. We had a program that read paper tapes, producing a detail listing as it did so. It also built a summary table in memory. After the last tape was read, the program sorted the accumulated data - using a bubble sort, no less. The machine sat there for 60 seconds, the CPU grinding like mad, before it went into the summary report. This was a small machine with no spooling, and each detail record was being listed on a 600-lpm printer. I realized that this gave me a full 100 milliseconds to process each record, whether I needed it or not. So I re-worked the program to build the summary table with an insertion sort; there was no penalty in wall-clock time, and the table always remained in sequence, so after the operator signaled that the last tape has been read, the program instantly went into the summary report. Being the devious sort that I am, I gave the new version of the program to the operator without telling him about this modification. And predictably, I got an anguished cry that the program wasn't sorting anymore. "Check the report," I said. "It's in sequence, isn't it?" To this day I see examples of people locked into the mindset that if something doesn't take a long time, it can't be right. Sometimes they're right, but other times they're barred from realizing that a better algorithm can work miracles. > Good times. Yup. -- /~\ Charlie Gibbs | Microsoft is a dictatorship. \ / <cgibbs@kltpzyxm.invalid> | Apple is a cult. X I'm really at ac.dekanfrus | Linux is anarchy. / \ if you read it the right way. | Pick your poison.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-08-03 13:34 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <1485802200.618179259.170456.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #212523 |
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote: > On 2020-08-02, Dan Espen <dan1espen@gmail.com> wrote: > >> I got rid of all the crap and submitted a test. >> The operator wrote on the test results that the job didn't run. >> It ran fine, it only took a few seconds. > > I did that once. We had a program that read paper tapes, producing > a detail listing as it did so. It also built a summary table in > memory. After the last tape was read, the program sorted the > accumulated data - using a bubble sort, no less. The machine > sat there for 60 seconds, the CPU grinding like mad, before it > went into the summary report. > > This was a small machine with no spooling, and each detail record > was being listed on a 600-lpm printer. I realized that this gave > me a full 100 milliseconds to process each record, whether I needed > it or not. So I re-worked the program to build the summary table > with an insertion sort; there was no penalty in wall-clock time, > and the table always remained in sequence, so after the operator > signaled that the last tape has been read, the program instantly > went into the summary report. Very clever. > > Being the devious sort that I am, I gave the new version of the > program to the operator without telling him about this modification. > And predictably, I got an anguished cry that the program wasn't > sorting anymore. "Check the report," I said. "It's in sequence, > isn't it?" > > To this day I see examples of people locked into the mindset that > if something doesn't take a long time, it can't be right. Sometimes > they're right, but other times they're barred from realizing that > a better algorithm can work miracles. Not so much “doesn’t take a long time”, but “behaves differently”. You’d get the same reaction if a job that usually took a minute suddenly took an hour. That’s good. The operators often have no way of telling if a job ran correctly, but they can tell if it behaved the same way it usually does. Some jobs have something for the operator to check at the end, verify that a check number in a console message matches the number of the last check actually printed, for example. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-08-01 00:55 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <f8c5fe41-79de-4632-9776-5edf608df725o@googlegroups.com> |
| In reply to | #212471 |
On Friday, July 31, 2020 at 9:30:33 PM UTC-6, robin...@gmail.com wrote: > the fact that CDC had 65 characters stored in > 6-bits. At first I thought that meant they had a 390 bit word, but then I realized that what was meant was that... they were using a double-byte character set? John Savard
[toc] | [prev] | [next] | [standalone]
| From | robin.vowels@gmail.com |
|---|---|
| Date | 2020-08-01 02:27 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <948acf04-5d36-480f-89fa-fb03ec1e3bc5o@googlegroups.com> |
| In reply to | #212474 |
On Saturday, August 1, 2020 at 5:55:17 PM UTC+10, Quadibloc wrote: > On Friday, July 31, 2020 at 9:30:33 PM UTC-6, robin...@gmail.com wrote: > > the fact that CDC had 65 characters stored in > > 6-bits. > > At first I thought that meant they had a 390 bit word, but then I realized that > what was meant was that... they were using a double-byte character set? No; characters were only 6 bits.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-08-01 17:27 +0000 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <rg48mf$15s0$1@gal.iecc.com> |
| In reply to | #212478 |
In article <948acf04-5d36-480f-89fa-fb03ec1e3bc5o@googlegroups.com>, <robin.vowels@gmail.com> wrote: >On Saturday, August 1, 2020 at 5:55:17 PM UTC+10, Quadibloc wrote: >> On Friday, July 31, 2020 at 9:30:33 PM UTC-6, robin...@gmail.com wrote: >> > the fact that CDC had 65 characters stored in >> > 6-bits. >> >> At first I thought that meant they had a 390 bit word, but then I realized that >> what was meant was that... they were using a double-byte character set? > >No; characters were only 6 bits. How do you store 65 characters in 6 bits? -- 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_flass@yahoo.com> |
|---|---|
| Date | 2020-08-01 12:11 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <641404549.618001844.129357.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #212487 |
John Levine <johnl@taugh.com> wrote: > In article <948acf04-5d36-480f-89fa-fb03ec1e3bc5o@googlegroups.com>, > <robin.vowels@gmail.com> wrote: >> On Saturday, August 1, 2020 at 5:55:17 PM UTC+10, Quadibloc wrote: >>> On Friday, July 31, 2020 at 9:30:33 PM UTC-6, robin...@gmail.com wrote: >>>> the fact that CDC had 65 characters stored in >>>> 6-bits. >>> >>> At first I thought that meant they had a 390 bit word, but then I realized that >>> what was meant was that... they were using a double-byte character set? >> >> No; characters were only 6 bits. > > How do you store 65 characters in 6 bits? > Very carefully ;-) -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0073@eager.cx> |
|---|---|
| Date | 2020-08-01 19:56 +0000 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <holvmvFmsnaU20@mid.individual.net> |
| In reply to | #212487 |
On Sat, 01 Aug 2020 17:27:43 +0000, John Levine wrote: > In article <948acf04-5d36-480f-89fa-fb03ec1e3bc5o@googlegroups.com>, > <robin.vowels@gmail.com> wrote: >>On Saturday, August 1, 2020 at 5:55:17 PM UTC+10, Quadibloc wrote: >>> On Friday, July 31, 2020 at 9:30:33 PM UTC-6, robin...@gmail.com >>> wrote: >>> > the fact that CDC had 65 characters stored in 6-bits. >>> >>> At first I thought that meant they had a 390 bit word, but then I >>> realized that what was meant was that... they were using a double-byte >>> character set? >> >>No; characters were only 6 bits. > > How do you store 65 characters in 6 bits? Probably a typo, but...shift characters. See the ICL 1900, for example. -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-08-01 20:18 +0000 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <rg4inf$25gi$1@gal.iecc.com> |
| In reply to | #212489 |
In article <holvmvFmsnaU20@mid.individual.net>, Bob Eager <news0073@eager.cx> wrote: >>>No; characters were only 6 bits. >> >> How do you store 65 characters in 6 bits? > >Probably a typo, but...shift characters. See the ICL 1900, for example. That would get about 124, shift up and down and 62 in each case. I gather from other messages that :: was treated as the 65th character. (I'm old enough to remember Baudot.) -- 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 | Bob Eager <news0073@eager.cx> |
|---|---|
| Date | 2020-08-01 23:42 +0000 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <homcuiFmsnaU21@mid.individual.net> |
| In reply to | #212490 |
On Sat, 01 Aug 2020 20:18:55 +0000, John Levine wrote: > In article <holvmvFmsnaU20@mid.individual.net>, > Bob Eager <news0073@eager.cx> wrote: >>>>No; characters were only 6 bits. >>> >>> How do you store 65 characters in 6 bits? >> >>Probably a typo, but...shift characters. See the ICL 1900, for example. > > That would get about 124, shift up and down and 62 in each case. I > gather from other messages that :: was treated as the 65th character. > > (I'm old enough to remember Baudot.) The 1900 had one fewer. It had a 'shift up for next character only' code. -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | robin.vowels@gmail.com |
|---|---|
| Date | 2020-08-01 20:32 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <8f2d89ce-2422-4c5d-9696-6079295c842do@googlegroups.com> |
| In reply to | #212490 |
On Sunday, August 2, 2020 at 6:18:57 AM UTC+10, John Levine wrote: > In article <h......@mid.individual.net>, > Bob Eager <n......@eager.cx> wrote: > >>>No; characters were only 6 bits. > >> > >> How do you store 65 characters in 6 bits? > > > >Probably a typo, but...shift characters. See the ICL 1900, for example. > > That would get about 124, shift up and down and 62 in each case. I gather > from other messages that :: was treated as the 65th character. There was no shift character on the CDC. (Later there was an escape character.) > (I'm old enough to remember Baudot.) 5-channel teleprinters are still around.
[toc] | [prev] | [next] | [standalone]
| From | Gerard Schildberger <gerard46@rrt.net> |
|---|---|
| Date | 2020-08-02 12:58 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <e43ba3e6-bc4e-4649-ae63-c0663c9e6397o@googlegroups.com> |
| In reply to | #212490 |
On Saturday, August 1, 2020 at 3:18:57 PM UTC-5, John Levine wrote: > Bob Eager wrote: > >>>No; characters were only 6 bits. > >> > >> How do you store 65 characters in 6 bits? > > > >Probably a typo, but...shift characters. See the ICL 1900, for example. > > That would get about 124, shift up and down and 62 in each case. I gather > from other messages that :: was treated as the 65th character. > (I'm old enough to remember Baudot.) I remember Bridget being pretty hot. Oh wait, that was Bardot. ... Never mind. _________________________________ Gerard Schildberger
[toc] | [prev] | [next] | [standalone]
| From | J. Clarke <jclarke.873638@gmail.com> |
|---|---|
| Date | 2020-08-01 16:28 -0400 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <41kbif5r5u3v9ncdqc0s3ikro9nbbtuf3p@4ax.com> |
| In reply to | #212489 |
On 1 Aug 2020 19:56:15 GMT, Bob Eager <news0073@eager.cx> wrote: >On Sat, 01 Aug 2020 17:27:43 +0000, John Levine wrote: > >> In article <948acf04-5d36-480f-89fa-fb03ec1e3bc5o@googlegroups.com>, >> <robin.vowels@gmail.com> wrote: >>>On Saturday, August 1, 2020 at 5:55:17 PM UTC+10, Quadibloc wrote: >>>> On Friday, July 31, 2020 at 9:30:33 PM UTC-6, robin...@gmail.com >>>> wrote: >>>> > the fact that CDC had 65 characters stored in 6-bits. >>>> >>>> At first I thought that meant they had a 390 bit word, but then I >>>> realized that what was meant was that... they were using a double-byte >>>> character set? >>> >>>No; characters were only 6 bits. >> >> How do you store 65 characters in 6 bits? > >Probably a typo, but...shift characters. See the ICL 1900, for example. Wiki has a relevant entry: https://en.wikipedia.org/wiki/Six-bit_character_code I was not aware that Braille was a binary encoding.
[toc] | [prev] | [next] | [standalone]
| From | David Lesher <wb8foz@panix.com> |
|---|---|
| Date | 2020-08-02 20:42 +0000 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <rg78fh$ar8$1@reader1.panix.com> |
| In reply to | #212491 |
J. Clarke <jclarke.873638@gmail.com> writes: >>> How do you store 65 characters in 6 bits? >> >>Probably a typo, but...shift characters. See the ICL 1900, for example. >Wiki has a relevant entry: >https://en.wikipedia.org/wiki/Six-bit_character_code >I was not aware that Braille was a binary encoding. The Tek 834 RS-232 test set also handled a format I'd not seen before or since. ALPRS or such ~ AirLine Passenger Reservation System I was told it dated back to when the airlines interline booking system was created, long before other folks' computers talked with each other. (Can't find a 834 TFM on line or I'd look it up..) -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close.......................... Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
[toc] | [prev] | [next] | [standalone]
| From | robin.vowels@gmail.com |
|---|---|
| Date | 2020-08-01 20:27 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <cc1e0834-15fa-40cd-9ea7-76d0f2805913o@googlegroups.com> |
| In reply to | #212487 |
On Sunday, August 2, 2020 at 3:27:45 AM UTC+10, John Levine wrote: > In article <9......@googlegroups.com>, > <r......@gmail.com> wrote: > >On Saturday, August 1, 2020 at 5:55:17 PM UTC+10, Quadibloc wrote: > >> On Friday, July 31, 2020 at 9:30:33 PM UTC-6, robin...@gmail.com wrote: > >> > the fact that CDC had 65 characters stored in > >> > 6-bits. > >> > >> At first I thought that meant they had a 390 bit word, but then I realized that > >> what was meant was that... they were using a double-byte character set? > > > >No; characters were only 6 bits. > > How do you store 65 characters in 6 bits? I just explained that. The 65th character was the :: , which was interpreted as end of line. The pair was not printed; you got the print line split over 2 lines. Brilliant. (The :: needed to be at the beginning of a word.)
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-08-02 00:28 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <9b0e7f28-78e7-4dee-86b0-54a4d4d922cbo@googlegroups.com> |
| In reply to | #212487 |
On Saturday, August 1, 2020 at 11:27:45 AM UTC-6, John Levine wrote: > How do you store 65 characters in 6 bits? I didn't know either, but it was explained in this thread now: the character sequence "::" was treated as a new line character. But there was no way to escape the colon to allow two consecutive colons to be printed. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2020-08-02 08:01 +0000 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <rg5rsn$eep$1@newsreader4.netcologne.de> |
| In reply to | #212497 |
Quadibloc <jsavard@ecn.ab.ca> schrieb: > On Saturday, August 1, 2020 at 11:27:45 AM UTC-6, John Levine wrote: > >> How do you store 65 characters in 6 bits? > > I didn't know either, but it was explained in this thread now: the character > sequence "::" was treated as a new line character. But there was no way to escape > the colon to allow two consecutive colons to be printed. So, no chance of implementing any Fortran later than FORTRAN 77 on a CDC 7600, because you cannot then write real, dimension(10) :: a Fair enough, I guess - that machine had been a bit out of date by 1991, when Fortran 90 was released.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-08-03 16:47 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <0858870f-b2b8-40cb-9e88-1c084d5ca339o@googlegroups.com> |
| In reply to | #212497 |
On Sunday, August 2, 2020 at 1:28:27 AM UTC-6, Quadibloc wrote: > On Saturday, August 1, 2020 at 11:27:45 AM UTC-6, John Levine wrote: > > > How do you store 65 characters in 6 bits? > > I didn't know either, but it was explained in this thread now: the character > sequence "::" was treated as a new line character. But there was no way to escape > the colon to allow two consecutive colons to be printed. This discussion about fitting 65 characters into six bits has given me inspiration! So at the end of my page at http://www.quadibloc.com/comp/ascint.htm under the heading "And Now for Six Bits", I describe how one could devise a six- bit character set which stores text very efficiently... by having it switch between three modes. The first mode is a plain 63-character code, with one code reserved as an escape character for switching modes. The second mode picks a different 62 characters. No digits. Only a precious few punctuation marks. But both the upper-case and lower-case alphabets, making it very efficient for text documents. In addition to also having the escape character for switching modes, it has a character for switching directly to (a modified version of) the third mode when it is desired to print a digit or some other punctuation mark. The third mode provides 48 characters... _and_ control characters to shift between upper-case and lower-case. So one can still have lower-case but have more punctuation marks than in the second mode. But there are now also twelve _prefix_ characters. So one doesn't just have 48 characters, one has 48 characters that are one character long, 512 characters that are two character cells long, and 16,384 characters that are three character cells long. All right, that takes care of Chinese. How about other foreign languages? Here, I use other mode values to switch languages so that other languages can be efficiently coded to use only one six-bit character per letter if possible... this is defintely _not_ structured like UTF-8, even if the use of prefix characters is somewhat reminiscent of it. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-08-03 19:45 -0700 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <7aaa7c28-1b60-4a55-9239-d6f79f49a46bo@googlegroups.com> |
| In reply to | #212533 |
On Monday, August 3, 2020 at 5:47:30 PM UTC-6, Quadibloc wrote: > On Sunday, August 2, 2020 at 1:28:27 AM UTC-6, Quadibloc wrote: > > On Saturday, August 1, 2020 at 11:27:45 AM UTC-6, John Levine wrote: > > > > > How do you store 65 characters in 6 bits? > > > > I didn't know either, but it was explained in this thread now: the character > > sequence "::" was treated as a new line character. But there was no way to escape > > the colon to allow two consecutive colons to be printed. > > This discussion about fitting 65 characters into six bits has given me > inspiration! > > So at the end of my page at > > http://www.quadibloc.com/comp/ascint.htm > > under the heading "And Now for Six Bits", I describe how one could devise a six- > bit character set which stores text very efficiently... by having it switch > between three modes. > > The first mode is a plain 63-character code, with one code reserved as an escape > character for switching modes. > > The second mode picks a different 62 characters. No digits. Only a precious few > punctuation marks. But both the upper-case and lower-case alphabets, making it > very efficient for text documents. In addition to also having the escape > character for switching modes, it has a character for switching directly to (a > modified version of) the third mode when it is desired to print a digit or some > other punctuation mark. > > The third mode provides 48 characters... _and_ control characters to shift > between upper-case and lower-case. So one can still have lower-case but have > more punctuation marks than in the second mode. > > But there are now also twelve _prefix_ characters. So one doesn't just have 48 > characters, one has 48 characters that are one character long, 512 characters > that are two character cells long, and 16,384 characters that are three > character cells long. > > All right, that takes care of Chinese. How about other foreign languages? Here, > I use other mode values to switch languages so that other languages can be > efficiently coded to use only one six-bit character per letter if possible... > this is defintely _not_ structured like UTF-8, even if the use of prefix > characters is somewhat reminiscent of it. There was one thing about the scheme I came up with I wasn't entirely happy with - some characters had to be shifted around to different positions between modes. By giving up some preferences for where it was most logical to put certain things in some of the modes, I was able to fix that flaw, and the corrected code is now also on this page. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-08-03 21:00 -0600 |
| Subject | Re: IBM models 91, 195 & CDC 7600 |
| Message-ID | <1bzh7baze2.fsf@pfeifferfamily.net> |
| In reply to | #212497 |
Quadibloc <jsavard@ecn.ab.ca> writes: > On Saturday, August 1, 2020 at 11:27:45 AM UTC-6, John Levine wrote: > >> How do you store 65 characters in 6 bits? > > I didn't know either, but it was explained in this thread now: the character > sequence "::" was treated as a new line character. But there was no way to escape > the colon to allow two consecutive colons to be printed. No way if the colons were the first characters in the word. If they were anywhere else, they were printed as two colons. My first exposure to Lisp was Lisp 1.5, on cards, on a 6400. The bug I remember most clearly was it used a bunch of colons (ten maybe?) to mark the end of a line, so every line of output had an apparently-random number of colons at the end.
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web