Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #218117 > unrolled thread
| Started by | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| First post | 2021-06-16 11:59 -0700 |
| Last post | 2021-11-17 13:06 -0500 |
| Articles | 20 on this page of 134 — 26 participants |
Back to article view | Back to alt.folklore.computers
iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-06-16 11:59 -0700
Re: iBM System/3 FORTRAN for engineering/science work? J. Clarke <jclarke.873638@gmail.com> - 2021-06-16 16:08 -0400
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-06-26 12:40 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Grant Taylor <gtaylor@tnetconsulting.net> - 2021-06-26 15:14 -0600
Re: s/3, s/34, s/36, and so forth not iBM System/3 FORTRAN John Levine <johnl@taugh.com> - 2021-06-27 01:27 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-06-28 17:28 -0700
Re: iBM System/3 FORTRAN for engineering/science work? John Levine <johnl@taugh.com> - 2021-06-29 22:47 +0000
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-06-29 12:55 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-06-28 17:28 -0700
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-06-29 13:04 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-06-29 21:33 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-06-30 11:44 -0700
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-01 11:40 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-06-30 11:44 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Rich Alderson <news@alderson.users.panix.com> - 2021-06-30 15:56 -0400
Re: iBM System/3 FORTRAN for engineering/science work? Bob Eager <news0009@eager.cx> - 2021-06-30 22:15 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Thomas Koenig <tkoenig@netcologne.de> - 2021-07-01 05:12 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Bob Eager <news0009@eager.cx> - 2021-07-01 06:28 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-07-01 13:28 +0100
Re: iBM System/3 FORTRAN for engineering/science work? John Levine <johnl@taugh.com> - 2021-07-03 01:19 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-07-03 10:14 +0100
Re: iBM System/3 FORTRAN for engineering/science work? Niklas Karlsson <nikke.karlsson@gmail.com> - 2021-07-03 10:43 +0000
Re: iBM System/3 FORTRAN for engineering/science work? sidd@situ.com - 2021-11-02 07:18 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Bob Eager <news0009@eager.cx> - 2021-11-02 09:26 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-11-02 05:07 -0700
Re: iBM System/3 FORTRAN for engineering/science work? cross@spitfire.i.gajendra.net (Dan Cross) - 2021-11-02 15:28 +0000
Re: iBM System/3 FORTRAN for engineering/science work? sidd@hugin.membrane.com - 2021-11-16 01:50 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-01 11:25 -0700
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-01 11:34 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-01 15:56 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-01 20:57 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-02 23:28 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-02 18:26 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Anne & Lynn Wheeler <lynn@garlic.com> - 2021-07-05 13:39 -1000
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-03 18:40 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-07-08 14:51 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-08 15:06 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-07-08 17:19 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-10 07:32 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-10 07:41 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Dan Espen <dan1espen@gmail.com> - 2021-07-10 13:30 -0400
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-07-10 13:29 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Dan Espen <dan1espen@gmail.com> - 2021-07-10 17:13 -0400
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-10 22:32 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-11 12:46 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Anne & Lynn Wheeler <lynn@garlic.com> - 2021-07-11 13:58 -1000
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-13 15:03 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Anne & Lynn Wheeler <lynn@garlic.com> - 2021-07-13 18:19 -1000
Re: iBM System/3 FORTRAN for engineering/science work? Anne & Lynn Wheeler <lynn@garlic.com> - 2021-07-13 18:50 -1000
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-16 11:33 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-16 22:40 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-16 23:13 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-17 19:12 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-17 21:33 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-18 15:20 +0000
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-20 12:05 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Thomas Koenig <tkoenig@netcologne.de> - 2021-07-21 05:29 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-21 17:14 +0000
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-23 12:19 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-24 21:35 +0000
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-26 13:13 -0700
Re: iBM System/3 FORTRAN for engineering/science work? gah4 <gah4@u.washington.edu> - 2021-07-27 22:13 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-21 11:08 -0700
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-23 12:16 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-24 21:35 +0000
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-26 13:09 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-20 22:49 -0700
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-23 12:01 -0700
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-13 14:55 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Thomas Koenig <tkoenig@netcologne.de> - 2021-07-14 10:03 +0000
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-13 15:11 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-13 21:42 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-07-14 00:39 -0700
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-20 12:07 -0700
Re: iBM System/3 FORTRAN for engineering/science work? gah4 <gah4@u.washington.edu> - 2021-07-27 22:07 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-07-29 21:19 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-07-29 21:20 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-30 07:57 -0700
Re: why PL/I makes us sad, iBM System/3 FORTRAN for engineering/science work? John Levine <johnl@taugh.com> - 2021-07-11 02:23 +0000
Re: why PL/I makes us sad, iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-07-10 21:23 -0700
Re: why PL/I makes us sad, iBM System/3 FORTRAN for engineering/science work? John Levine <johnl@taugh.com> - 2021-07-11 18:46 +0000
Re: why PL/I makes us sad, iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-11 12:46 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Bob Eager <news0009@eager.cx> - 2021-07-01 20:22 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Rich Alderson <news@alderson.users.panix.com> - 2021-07-01 19:00 -0400
Re: iBM System/3 FORTRAN for engineering/science work? Grant Taylor <gtaylor@tnetconsulting.net> - 2021-11-02 08:54 -0600
Re: iBM System/3 FORTRAN for engineering/science work? antispam@math.uni.wroc.pl - 2021-10-05 22:56 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-05 23:13 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-10-06 03:55 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 12:32 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-10-06 14:11 +0100
Re: iBM System/3 FORTRAN for engineering/science work? Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-06 13:34 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-10-06 04:00 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-10-06 04:07 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-10-06 04:11 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Bob Eager <news0009@eager.cx> - 2021-10-06 12:50 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Bob Eager <news0009@eager.cx> - 2021-10-06 12:49 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-10-06 17:40 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Bob Eager <news0009@eager.cx> - 2021-10-07 06:18 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Bob Eager <news0009@eager.cx> - 2021-10-06 13:22 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-10-06 04:18 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-10-06 04:21 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Bob Eager <news0009@eager.cx> - 2021-10-06 12:45 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-06-30 18:23 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Robin Vowels <robin.vowels@gmail.com> - 2021-06-30 18:10 -0700
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-01 11:36 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-02 23:28 +0000
Re: iBM System/3 FORTRAN for engineering/science work? gareth evans <headstone255@yahoo.com> - 2021-07-03 10:32 +0100
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-03 18:40 -0700
Re: iBM System/3 FORTRAN for engineering/science work? gareth evans <headstone255@yahoo.com> - 2021-07-04 09:13 +0100
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-07 12:46 -0700
Re: iBM System/3 FORTRAN for engineering/science work? gareth evans <headstone255@yahoo.com> - 2021-07-07 21:19 +0100
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-08 15:01 -0700
Re: iBM System/3 FORTRAN for engineering/science work? J. Clarke <jclarke.873638@gmail.com> - 2021-07-07 17:06 -0400
Re: iBM System/3 FORTRAN for engineering/science work? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-08 05:15 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-07-08 15:01 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Dan Espen <dan1espen@gmail.com> - 2021-07-08 19:39 -0400
Re: iBM System/3 FORTRAN for engineering/science work? Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2021-06-30 17:58 -0600
Re: iBM System/3 FORTRAN for engineering/science work? Rich Alderson <news@alderson.users.panix.com> - 2021-06-18 14:31 -0400
Re: iBM System/3 FORTRAN for engineering/science work? Dan Espen <dan1espen@gmail.com> - 2021-06-18 16:00 -0400
Re: iBM System/3 FORTRAN for engineering/science work? undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-06-26 12:47 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Dan Espen <dan1espen@gmail.com> - 2021-06-26 16:40 -0400
Re: iBM System/3 FORTRAN for engineering/science work? Grant Taylor <gtaylor@tnetconsulting.net> - 2021-06-26 15:20 -0600
Re: iBM System/3 FORTRAN for engineering/science work? "Kerr-Mudd, John" <admin@127.0.0.1> - 2021-06-27 11:28 +0100
Re: iBM System/3 FORTRAN for engineering/science work? Anne & Lynn Wheeler <lynn@garlic.com> - 2021-06-27 13:40 -1000
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-06-28 17:28 -0700
Re: iBM System/3 FORTRAN for engineering/science work? drb@ihatespam.msu.edu (Dennis Boone) - 2021-06-27 16:00 -0500
Re: iBM System/3 FORTRAN for engineering/science work? Peter Flass <peter_flass@yahoo.com> - 2021-06-28 17:28 -0700
Re: iBM System/3 FORTRAN for engineering/science work? Quadibloc <jsavard@ecn.ab.ca> - 2021-11-17 09:47 -0800
Re: iBM System/3 FORTRAN for engineering/science work? scott@slp53.sl.home (Scott Lurndal) - 2021-11-17 18:06 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Thomas Koenig <tkoenig@netcologne.de> - 2021-11-17 22:28 +0000
Re: iBM System/3 FORTRAN for engineering/science work? scott@slp53.sl.home (Scott Lurndal) - 2021-11-18 01:00 +0000
Re: iBM System/3 FORTRAN for engineering/science work? John Levine <johnl@taugh.com> - 2021-11-18 01:51 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-11-18 06:06 +0000
Re: iBM System/3 FORTRAN for engineering/science work? Dan Espen <dan1espen@gmail.com> - 2021-11-17 13:06 -0500
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-26 13:13 -0700 |
| Message-ID | <baae4645-9ba1-4861-8235-a420d4b8363bn@googlegroups.com> |
| In reply to | #218532 |
On Saturday, July 24, 2021 at 5:36:10 PM UTC-4, Charlie Gibbs wrote: > > Our 90/30 had ISAM. > Did you get to the point where MIRAM files were introduced? > They were much nicer, and allowed indexing on up to 5 keys. No, that was after my time. On our IBM mainframe, we made use of VSAM alternate indexes to allow for multiple non-unique keys (e.g. searching by name, DOB, etc). Very efficient and worked well. As mentioned, VSAM was kind of disparaged, everyone pushed for a modern system like SQL. But our systems programmers and database administrators, who monitored performance, noted that our VSAM system was very efficient while they had problems with some SQL systems. Even on new powerful machines, a sloppy SQL query could flog the machine. Geez, we have one VSAM system now 45 years old, and will probably reach 50.
[toc] | [prev] | [next] | [standalone]
| From | gah4 <gah4@u.washington.edu> |
|---|---|
| Date | 2021-07-27 22:13 -0700 |
| Message-ID | <971567eb-9659-4d5b-9af4-5bab2e709d12n@googlegroups.com> |
| In reply to | #218491 |
On Tuesday, July 20, 2021 at 10:29:40 PM UTC-7, Thomas Koenig wrote: (snip) > I remember the recommendation for FB80 files switching from a > blocksize of 3200 bytes to a blocksize of 3120 bytes when the > computer center switched generations of mainframes and therefore > disk type, as well. > 30 years ago I could probably have told you the disk drive > types this was optimum for. Not any more :-) 3120 is (rounded down from 3156) quarter track 3330. It is also not so far from half track 2314, so if you don't know which one, it is a good choice.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-07-21 11:08 -0700 |
| Message-ID | <1374957347.648582817.135247.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #218479 |
undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote: > On Sunday, July 18, 2021 at 11:21:30 AM UTC-4, Charlie Gibbs wrote: >> True, but one shop I worked in went to the other extreme: >> full-track blocking for every file. One system consisted >> of a program that created half a dozen work files (even >> though some were redundant). Six output files - plus an >> input file - with a track size of 10K meant that 70K of >> the machine's 192K went to buffers alone. It certainly >> didn't make anything else run faster since there was no >> memory left to run more. > > Yes, on older machines too high a blocking factor caused problems, too. > They used to warn us not max out on blocking factors. Memory was not > unlimited, as you say. When designing a system we considered the program with the most files and figured how much memory would be required for double-buffering. We’d usually start looking at half-track blocking, then look at single-buffering on some datasets if we couldn’t do double. Systems design was fun in the olden days. > > In the old days we calculated optimum blocksizes based on our logical > record length and the device we were writing to. Disk drives had different > lengths. Switching from 2311 to 2314 meant recalculating everything. There were a lot of programs to do this. I wrote one, and only this year found out I could have gotten one from SHARE. > > I once experimented with a S/360 tape drive. I found a block size of > about 5,000 characters was the max, anything beyond that would > generate I/O errors and waste time with retries. At first I misread this as disk. I don’t recall a lot of problems with tape, but maybe we didn’t use huge blick sizes. > > Later machines could handle maximum blocks. Indeed, in later years > we coded BLKSIZE=0 in our JCL which would maximize blocksize > for whatever device we were creating a file on. As data centers got > bigger and had a mix of devices, the dynamic automatic blocking > made it easier for us, since we didn't have to worry about the device > type. Blksize=0 only came along much later, maybe as part of SMS on MVS/XA or maybe /ESA. It was better than sliced bread, but wouldn’t have worked on machines with limited storage where we counted every byte. > > Amazing, in the early days we were intimately familiar with the > characteristics of say the 2311 vs. the 2314 or various tape drives. > Our coding depended on it to optimize performance and memory. > But now, devices evolve and we don't even know what we're writing to. > The system handles it all automatically, with automatic file allocation. All the fun is gone :-( > > Sometimes we had older jobs with hardcoded low blocksizes. They > ran poorly. Upgrading it was an easy way to improve performance. > > In a few cases, such as files being sent out or specialty devices, > blocksize and other issues still mattered. JCL still allows to set > specifics if desired. > > > > -- Pete
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-23 12:16 -0700 |
| Message-ID | <2dd153ce-8419-4949-be4d-fb4aaf0bb1a6n@googlegroups.com> |
| In reply to | #218494 |
On Wednesday, July 21, 2021 at 2:08:33 PM UTC-4, Peter Flass wrote: > When designing a system we considered the program with the most files and > figured how much memory would be required for double-buffering. We’d > usually start looking at half-track blocking, then look at single-buffering > on some datasets if we couldn’t do double. Systems design was fun in the > olden days. On the smaller S/360 and equivalent competitors (e.g. RCA Spectra), physical size was limited but files could be big. Careful design was required, as you describe, to fit everything in without flogging the machine. In my opinion, sometimes data centers would attempt to do too much on their machines of the time--loading too much data volume or program complexity onto a machine that simply wasn't up to handling it. Programmers would pull all sorts of tricks to squeeze it all in, and be on standby if something blew up--which happened often. And it seemed that no sooner that they got a bigger machine then they loaded another new bulky application on it which continued the old problems. Indeed, I think these problems continued until roughly 1990 (depending on a site) when hardware finally got cheap enough that they could buy adequately sized and powered machines (enough memory, I/O channels, disk and space, and CPU speed). > > In the old days we calculated optimum blocksizes based on our logical > > record length and the device we were writing to. Disk drives had different > > lengths. > Switching from 2311 to 2314 meant recalculating everything. There were a > lot of programs to do this. I wrote one, and only this year found out I > could have gotten one from SHARE. Yes, every time the data center upgraded conversions were necessary to reflect the new hardware, even if it was the same brand of computer. > > I once experimented with a S/360 tape drive. I found a block size of > > about 5,000 characters was the max, anything beyond that would > > generate I/O errors and waste time with retries. > At first I misread this as disk. I don’t recall a lot of problems with > tape, but maybe we didn’t use huge blick sizes. We were using a cheapo S/360 tape drive. I think the later models on S/370 with 6250 bpi worked better. And of course the later cartridges were even better. > > Later machines could handle maximum blocks. Indeed, in later years > > we coded BLKSIZE=0 in our JCL which would maximize blocksize > > for whatever device we were creating a file on. As data centers got > > bigger and had a mix of devices, the dynamic automatic blocking > > made it easier for us, since we didn't have to worry about the device > > type. > Blksize=0 only came along much later, maybe as part of SMS on MVS/XA or > maybe /ESA. It was better than sliced bread, but wouldn’t have worked on > machines with limited storage where we counted every byte. SMS had a lot of advantages, especially for the system programmers, but there were some growing pains. It took a lot of overhead and wouldn't have been possible on older machines. But overall it worked out well, including automated backups. I think SMS introduced compression onto IBM mainframes which could save a lot of space. PKZIP on steroids. Transparent to application people. Indeed, I think one function of SMS was to automatically offload little used files to slower medium freeing high speed stuff for more important files. Again, transparent. > > Amazing, in the early days we were intimately familiar with the > > characteristics of say the 2311 vs. the 2314 or various tape drives. > > Our coding depended on it to optimize performance and memory. > > But now, devices evolve and we don't even know what we're writing to. > > The system handles it all automatically, with automatic file allocation. > All the fun is gone :-( There was a sense of pride in knowing how to use the reference cards and optimize settings to get improved performance and space usage. Likewise in coding for efficiency. Indeed, that was fun. On the flip side, as mentioned above when systems were squeezed to the hilt, failures were common and a nuisance to fix. Getting a phone call at 3 a.m. to come in (no home terminals then) was not much fun and happened too often. I think at least one data center programmers got tired of the 3 a.m. phone calls and pressured management to spend the money to upgrade the machine to reduce troubles. At least a few data centers suffered massive resignations when staff just got tired of problems.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-07-24 21:35 +0000 |
| Message-ID | <sdi12m2663@news3.newsguy.com> |
| In reply to | #218527 |
On 2021-07-23, undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote: > On Wednesday, July 21, 2021 at 2:08:33 PM UTC-4, Peter Flass wrote: > >> When designing a system we considered the program with the most files >> and figured how much memory would be required for double-buffering. >> We’d usually start looking at half-track blocking, then look at >> single-buffering on some datasets if we couldn’t do double. Systems >> design was fun in the olden days. > > On the smaller S/360 and equivalent competitors (e.g. RCA Spectra), > physical size was limited but files could be big. Careful design > was required, as you describe, to fit everything in without flogging > the machine. > > In my opinion, sometimes data centers would attempt to do too much > on their machines of the time--loading too much data volume or program > complexity onto a machine that simply wasn't up to handling it. > Programmers would pull all sorts of tricks to squeeze it all in, > and be on standby if something blew up--which happened often. Part of this was due to computer salesmen lowballing hardware requirements. Once the machine had been sold and installed, it was usually too late to back out, so the customer sucked it up and paid for the additional hardware that, had they known, they would have needed all along. > And it seemed that no sooner that they got a bigger machine then they > loaded another new bulky application on it which continued the old > problems. Parkinson's Law states that work expands so as to fill the time available for its completion. There are various corollaries, such as programs expanding to fill available memory, data files expanding to fill available drives, etc. > Indeed, I think these problems continued until roughly 1990 (depending > on a site) when hardware finally got cheap enough that they could buy > adequately sized and powered machines (enough memory, I/O channels, > disk and space, and CPU speed). Alas, there is a difference between "could" and "did". Even in the last few years we've run into problems when customers scrimped on disk space: not just with inadequate drives but also with bad partitioning schemes. x > There was a sense of pride in knowing how to use the reference cards > and optimize settings to get improved performance and space usage. > Likewise in coding for efficiency. > > Indeed, that was fun. > > On the flip side, as mentioned above when systems were squeezed to > the hilt, failures were common and a nuisance to fix. Getting a phone > call at 3 a.m. to come in (no home terminals then) was not much fun > and happened too often. BTDTGTS (been there, done that, got the scars) That's why, for a long time, I didn't have a telephone at home. It had to be a _real_ emergency before someone would drive over, bang on the door, wake up the landlady, and have her get me. > I think at least one data center programmers got tired of the 3 a.m. > phone calls and pressured management to spend the money to > upgrade the machine to reduce troubles. > > At least a few data centers suffered massive resignations when > staff just got tired of problems. You just had to pray that management was intelligent enough to take the hint. -- /~\ Charlie Gibbs | They don't understand Microsoft \ / <cgibbs@kltpzyxm.invalid> | has stolen their car and parked X I'm really at ac.dekanfrus | a taxi in their driveway. / \ if you read it the right way. | -- Mayayana
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-26 13:09 -0700 |
| Message-ID | <e52e4d2e-cef7-40a2-8d40-70c5ef4730d8n@googlegroups.com> |
| In reply to | #218533 |
On Saturday, July 24, 2021 at 5:36:10 PM UTC-4, Charlie Gibbs wrote: > > I think at least one data center programmers got tired of the 3 a.m. > > phone calls and pressured management to spend the money to > > upgrade the machine to reduce troubles. > > At least a few data centers suffered massive resignations when > > staff just got tired of problems. > You just had to pray that management was intelligent enough to > take the hint. Unfortunately, a lot of data center managements were not intelligent enough and allowed massive disruptions. For some reason, high corporate management supported them until it was too late. A fix usually required very expensive consultants to dig through everything. At least one large bank was forced to sell out to another since its customers got too pissed off from the mess, but this was not unique. Sometimes the trainwreck made the newspaper with resultant bad publicity.
[toc] | [prev] | [next] | [standalone]
| From | Robin Vowels <robin.vowels@gmail.com> |
|---|---|
| Date | 2021-07-20 22:49 -0700 |
| Message-ID | <7b4da19a-1e85-46c9-b804-32fcf4031505n@googlegroups.com> |
| In reply to | #218457 |
On Monday, July 19, 2021 at 1:21:30 AM UTC+10, Charlie Gibbs wrote: > On 2021-07-18, Robin Vowels <robin....@gmail.com> wrote: > > > On Sunday, July 18, 2021 at 5:13:28 AM UTC+10, Charlie Gibbs wrote: > > > >> On 2021-07-17, Robin Vowels <robin....@gmail.com> wrote: > >> > >>> A lot depended on the blocking factor. > >>> The ICL System 4 thrashed the disc drives because there was no blocking > >>> of 80-byte records. > >>> The drives began failing after about 5 years of that punishment. > >>> Records were subsequently de-blanked and blocked to 386(?) bytes > >>> with considerable improvement in performance, but full-track > >>> blocking would have been even better. > >> > >> Assuming you have enough memory for those big buffers... > > > > Plenty of memory fir that. > > You can't get any work out of thrashing disc drives. . > True, but one shop I worked in went to the other extreme: > full-track blocking for every file. One system consisted > of a program that created half a dozen work files (even > though some were redundant). Six output files - plus an > input file - with a track size of 10K meant that 70K of > the machine's 192K went to buffers alone. It certainly > didn't make anything else run faster since there was no > memory left to run more. . Another useful improvement, in the days of PCP, was to specify a number of buffers. I think that we used about 8 buffers, which gave a useful improvement when reading cards and simultaneously printing.
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-23 12:01 -0700 |
| Message-ID | <a36f174d-5213-4d69-8844-6a2ef525834fn@googlegroups.com> |
| In reply to | #218492 |
On Wednesday, July 21, 2021 at 1:49:05 AM UTC-4, Robin Vowels wrote: > Another useful improvement, in the days of PCP, was to specify > a number of buffers. I think that we used about 8 buffers, which > gave a useful improvement when reading cards and simultaneously > printing. In the QuickBasic compiler there was a LEN option for file I/O. Setting this high would greatly improve reading and writing speed, especially with floppy drives since a bigger block would be written. I don't think it saved any space (sector drives), but on floppies it reduced the start/stop action, allowing more continuous writing. (This was not available on the interpreted QBASIC version).
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-13 14:55 -0700 |
| Message-ID | <9d0c79fc-af44-4fb9-8a71-b8a9ec228261n@googlegroups.com> |
| In reply to | #218346 |
On Sunday, July 11, 2021 at 1:32:59 AM UTC-4, Robin Vowels wrote: > When we did have more core, we found that IBM's FORTRAN-H was > a very slow compiler, because it was an optimising compiler. That's > understandable. FORTRAN-G was the one we used most of the FORTRAN > offerings. Then we installed WATFOR, which also was possible with the > extra core. COBOL compiler optimizing is a tricky business. I ran tests with the optimize option on and off. Sometimes it did improve performance, but other times not especially. Certain usages require the optimize turned off. I don't know why, but the sysprog had it off for that reason. The Fortran world is tricky. Unlike the business world where a completed program may run week after week for years and thus should be optimized, some sci/eng efforts are research and the program may be run only a few times in production. More likely it might be recompiled frequently as the researcher discovers different things and tweaks his program accordingly. (Situations vary, of course). My compsci prof said WATFOR was a great compiler--compiled fast yet produced decent code. The IBM history says the 1401 could be used as a teststand for the 7090, including Fortran work. But 1401 users told me Fortran took forever to compile on a 1401.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2021-07-14 10:03 +0000 |
| Message-ID | <scmcpt$e6u$1@newsreader4.netcologne.de> |
| In reply to | #218372 |
undefined Hancock-4 <hancock4@bbs.cpcn.com> schrieb: > The Fortran world is tricky. Unlike the business world where a completed program > may run week after week for years and thus should be optimized, some sci/eng > efforts are research and the program may be run only a few times in production. That is one end of the spectrum. The other end is a the program burning millions of Euros of CPU time on a supercomputer cluster. I know one guy who did this for his PhD thesis. And the business world gave us something like Teams.
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-13 15:11 -0700 |
| Message-ID | <7992e487-13a3-4ae2-a5e0-69fb2a7c7d8dn@googlegroups.com> |
| In reply to | #218346 |
On Sunday, July 11, 2021 at 1:32:59 AM UTC-4, Robin Vowels wrote: > When we did have more core, we found that IBM's FORTRAN-H was > a very slow compiler, because it was an optimising compiler. IBM published a "Programmers Guide" alongside its language reference. However, how many people bothered to read it I don't know, but in my travels over the years at different sites I didn't see anyone on the application side check it out. But the Programmers Guide provided valuable tips for coding and setup for performance, efficiency, and maintainability. Unlike the language reference, it was written in a more casual understandable style. Here are examples for COBOL: https://www.ibm.com/docs/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/igy3pg50.pdf https://www.ibm.com/docs/en/ssw_ibm_i_72/rzase/sc092540.pdf PL/I https://www.ibm.com/docs/en/SSUFAU_1.0.0/com.ibm.ent.pl1.zos.doc/pg.pdf I don't know if IBM issued any equivalent publication for Assembler users. All I ever saw was the Principle of Operations.
[toc] | [prev] | [next] | [standalone]
| From | Robin Vowels <robin.vowels@gmail.com> |
|---|---|
| Date | 2021-07-13 21:42 -0700 |
| Message-ID | <3f38d325-e6a8-40d7-9f2f-c387963faea8n@googlegroups.com> |
| In reply to | #218374 |
On Wednesday, July 14, 2021 at 8:11:16 AM UTC+10, undefined Hancock-4 wrote: > On Sunday, July 11, 2021 at 1:32:59 AM UTC-4, Robin Vowels wrote: > > When we did have more core, we found that IBM's FORTRAN-H was > > a very slow compiler, because it was an optimising compiler. . > IBM published a "Programmers Guide" alongside its language reference. > However, how many people bothered to read it I don't know, but in my travels over > the years at different sites I didn't see anyone on the application side > check it out. . Both the LRM and the PG were/are important reference manuals, and at our site were available on the counter for both consulting staff and to users. Consulting staff had to be knowledgeable with both. There were enough multiple copies for consultancy staff to have their own copies. . > But the Programmers Guide provided valuable tips for coding and setup > for performance, efficiency, and maintainability. Unlike the language > reference, it was written in a more casual understandable style. > > Here are examples for COBOL: > https://www.ibm.com/docs/en/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/igy3pg50.pdf > > https://www.ibm.com/docs/en/ssw_ibm_i_72/rzase/sc092540.pdf > > PL/I > https://www.ibm.com/docs/en/SSUFAU_1.0.0/com.ibm.ent.pl1.zos.doc/pg.pdf > > > I don't know if IBM issued any equivalent publication for Assembler users. > All I ever saw was the Principle of Operations.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2021-07-14 00:39 -0700 |
| Message-ID | <ad4bf46e-931a-46a9-a8c5-1103a5134489n@googlegroups.com> |
| In reply to | #218374 |
On Tuesday, July 13, 2021 at 4:11:16 PM UTC-6, undefined Hancock-4 wrote: > But the Programmers Guide provided valuable tips for coding and setup > for performance, efficiency, and maintainability. Unlike the language > reference, it was written in a more casual understandable style. What I remembered of the FORTRAN Programmer's Guide is that it gave technical details of the use of the compiler - things like calling sequences - which were useful for certain advanced programming tasks. I had not noticed that it was an approachable guide to writing better programs, as you describe these books. John Savard
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-20 12:07 -0700 |
| Message-ID | <aec407f0-f5a8-40b0-86bb-c034c7a60059n@googlegroups.com> |
| In reply to | #218390 |
On Wednesday, July 14, 2021 at 3:39:57 AM UTC-4, Quadibloc wrote: > On Tuesday, July 13, 2021 at 4:11:16 PM UTC-6, undefined Hancock-4 wrote: > > > But the Programmers Guide provided valuable tips for coding and setup > > for performance, efficiency, and maintainability. Unlike the language > > reference, it was written in a more casual understandable style. > What I remembered of the FORTRAN Programmer's Guide is that it > gave technical details of the use of the compiler - things like calling > sequences - which were useful for certain advanced programming > tasks. > > I had not noticed that it was an approachable guide to writing better > programs, as you describe these books. It had a lot of info on the compiling and programming environments, but that was useful for all programmers, not just advanced ones. The Guides on bitsavers certainly contain sections on writing better programs as do the modern ones.
[toc] | [prev] | [next] | [standalone]
| From | gah4 <gah4@u.washington.edu> |
|---|---|
| Date | 2021-07-27 22:07 -0700 |
| Message-ID | <a5a69b34-c67f-40cc-9645-51910f5fe8d8n@googlegroups.com> |
| In reply to | #218390 |
On Wednesday, July 14, 2021 at 12:39:57 AM UTC-7, Quadibloc wrote: > On Tuesday, July 13, 2021 at 4:11:16 PM UTC-6, undefined Hancock-4 wrote: > > > But the Programmers Guide provided valuable tips for coding and setup > > for performance, efficiency, and maintainability. Unlike the language > > reference, it was written in a more casual understandable style. > What I remembered of the FORTRAN Programmer's Guide is that it > gave technical details of the use of the compiler - things like calling > sequences - which were useful for certain advanced programming > tasks. > I had not noticed that it was an approachable guide to writing better > programs, as you describe these books. It seems that instead of (usual) a hash table, Fortran H uses six balanced trees. One suggestion in the PG is to distribute variable names over the 1 to 6 characters about equally, for faster compilation. Writing better programs, but not necessarily more readable.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2021-07-29 21:19 -0700 |
| Message-ID | <384585d0-b283-4b77-8f31-f876250d3ee4n@googlegroups.com> |
| In reply to | #218549 |
On Tuesday, July 27, 2021 at 11:07:41 PM UTC-6, gah4 wrote: > It seems that instead of (usual) a hash table, Fortran H uses six balanced > trees. One suggestion in the PG is to distribute variable names over > the 1 to 6 characters about equally, for faster compilation. And here I thought that just meant it used six hash tables. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2021-07-29 21:20 -0700 |
| Message-ID | <fe47e822-61e5-4162-ac04-1ec797082630n@googlegroups.com> |
| In reply to | #218553 |
On Thursday, July 29, 2021 at 10:19:03 PM UTC-6, Quadibloc wrote: > On Tuesday, July 27, 2021 at 11:07:41 PM UTC-6, gah4 wrote: > > It seems that instead of (usual) a hash table, Fortran H uses six balanced > > trees. One suggestion in the PG is to distribute variable names over > > the 1 to 6 characters about equally, for faster compilation. > And here I thought that just meant it used six hash tables. Actually, no more than five hash tables. It would be silly to use a _hash_ table for one-letter variable names. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-07-30 07:57 -0700 |
| Message-ID | <261474323.649349775.986246.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #218554 |
Quadibloc <jsavard@ecn.ab.ca> wrote: > On Thursday, July 29, 2021 at 10:19:03 PM UTC-6, Quadibloc wrote: >> On Tuesday, July 27, 2021 at 11:07:41 PM UTC-6, gah4 wrote: > >>> It seems that instead of (usual) a hash table, Fortran H uses six balanced >>> trees. One suggestion in the PG is to distribute variable names over >>> the 1 to 6 characters about equally, for faster compilation. > >> And here I thought that just meant it used six hash tables. > > Actually, no more than five hash tables. It would be silly to use a > _hash_ table for one-letter variable names. :-) -- Pete
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2021-07-11 02:23 +0000 |
| Subject | Re: why PL/I makes us sad, iBM System/3 FORTRAN for engineering/science work? |
| Message-ID | <scdkn0$1k77$2@gal.iecc.com> |
| In reply to | #218336 |
According to Robin Vowels <robin.vowels@gmail.com>: >Unfortunately, he omitted to provide the REORDER keyword >for the PROCEDURE statement in the case of IBM's PL/I compiler. ... >P. J. Jaliks compared COBOL and PL/I. His PL/I version ran slower by >2-3 times of because of inappropriate variable declarations and >failure to disable fixed-point interrupts. ... PL/I makes it too easy to write bad programs, particularly if you don't know the folklore about what is efficient and what is not. One time I wrote a program that used an array of 12 bit fields and the code from PL/I F was stupendously bad. As I recall, each access converted the value to decimal and back, and no, I didn't do picture formatting or anything like that. I expect that if I'd made them 16 bit fields and just used the low 12 bits it would have been OK, but I ran out of time. -- 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 | Robin Vowels <robin.vowels@gmail.com> |
|---|---|
| Date | 2021-07-10 21:23 -0700 |
| Subject | Re: why PL/I makes us sad, iBM System/3 FORTRAN for engineering/science work? |
| Message-ID | <2306284c-4fe6-4235-8d78-47eb8fc8f20an@googlegroups.com> |
| In reply to | #218344 |
On Sunday, July 11, 2021 at 12:23:30 PM UTC+10, John Levine wrote: > According to Robin Vowels <robin....@gmail.com>: > >Unfortunately, he omitted to provide the REORDER keyword > >for the PROCEDURE statement in the case of IBM's PL/I compiler. ... > >P. J. Jaliks compared COBOL and PL/I. His PL/I version ran slower by > >2-3 times of because of inappropriate variable declarations and > >failure to disable fixed-point interrupts. ... > > PL/I makes it too easy to write bad programs, particularly if you don't know the folklore about what is > efficient and what is not. . I do not believe that to be the case. The PL/I Programmer's Guide contained/contains information about efficient constructs. . The Jaliks example cited is one that was specifically covered in the PL/I Programmer's Guide. . > One time I wrote a program that used an array of 12 bit fields and the code from PL/I F was stupendously > bad. As I recall, each access converted the value to decimal and back, . The conversion to and from BIT strings is via binary, not decimal. . > and no, I didn't > do picture formatting or anything like that. I expect that if I'd made them 16 bit fields and just used > the low 12 bits it would have been OK, but I ran out of time.
[toc] | [prev] | [next] | [standalone]
Page 4 of 7 — ← Prev page 1 2 3 [4] 5 6 7 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web