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 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2021-07-10 13:30 -0400 |
| Message-ID | <scclfg$aj8$1@dont-email.me> |
| In reply to | #218337 |
Robin Vowels <robin.vowels@gmail.com> writes:
> On Sunday, July 11, 2021 at 12:33:00 AM UTC+10, Robin Vowels wrote:
>> On Friday, July 9, 2021 at 7:51:50 AM UTC+10, Quadibloc wrote:
>> > On Friday, July 2, 2021 at 5:29:34 PM UTC-6, Charlie Gibbs wrote:
>> > > Forget about COBOL -
>> > > to the CS weenies, uttering its name was an even worse profanity
>> > > than GOTO. There wasn't even a COBOL compiler on the system.
>> > > (If you were desperate, you could submit a compile request for
>> > > overnight batch, where the operators would run it under OS/360
>> > > emulation.) Needless to say, RPG did not exist. Period.
>> .
>> > Although it's unfortunate that the PL/I compiler was not efficient,
>> .
>> Some have claimed this, and have compared run times for various
>> languages including FORTRAN and PL/I. A. B. Tucker ("Programming
>> Languages") is one.
>> Unfortunately, he omitted to provide the REORDER keyword
>> for the PROCEDURE statement in the case of IBM's PL/I compiler.
>> The PL/I programs ran slower than they should have.
>> .
>> I investigated claims by D. J. Kewley, who compared run times of FORTRAN,
>> Pascal, and PL/I programs. The PL/I version did not use COMPLEX data types,
>> whereas the FORTRAN version did. Modifying the PL/I version program to use
>> COMPLEX and REORDER gave a 47% increase in execution speed.
>> .
>> 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.
> .
> R. H. Prins criticized IBM's Enterprise PL/I compiler for
> optimising poorly. He subsequently retracted that criticism when
> he discovered that he had been compiling the program with OPT(0) --
> that is, with no optimisation !
The last place I worked had a lot of PL/I, had very firm customer
commitments for CPU use and actively worked with IBM to keep the PL/I
compiler efficient. I'm not aware of any issues with mainframe PL/I
efficiency being lacking.
--
Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2021-07-10 13:29 -0700 |
| Message-ID | <176167b0-b42b-4cec-8275-54946a15ab22n@googlegroups.com> |
| In reply to | #218338 |
On Saturday, July 10, 2021 at 11:30:26 AM UTC-6, Dan Espen wrote: > The last place I worked had a lot of PL/I, had very firm customer > commitments for CPU use and actively worked with IBM to keep the PL/I > compiler efficient. I'm not aware of any issues with mainframe PL/I > efficiency being lacking. Although I think the post here was talking about the time it took to compile, not the efficiency of the generated code. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2021-07-10 17:13 -0400 |
| Message-ID | <scd2i9$3dq$1@dont-email.me> |
| In reply to | #218341 |
Quadibloc <jsavard@ecn.ab.ca> writes: > On Saturday, July 10, 2021 at 11:30:26 AM UTC-6, Dan Espen wrote: > >> The last place I worked had a lot of PL/I, had very firm customer >> commitments for CPU use and actively worked with IBM to keep the PL/I >> compiler efficient. I'm not aware of any issues with mainframe PL/I >> efficiency being lacking. > > Although I think the post here was talking about the time it took to > compile, not the efficiency of the generated code. Yeah, I couldn't really tell what was meant. I remember we made quite a stink about a new compiler version where the compiler slowed down a lot. At first IBM said it's not important, the compiler needs more time to generate better code. Soon after, they fixed the problem. Other than that, I don't remember the PL/I compiler being any slower to compile than the other languages we used HLASM, C. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Robin Vowels <robin.vowels@gmail.com> |
|---|---|
| Date | 2021-07-10 22:32 -0700 |
| Message-ID | <33d3b4cc-9a0c-4f1e-9eaf-5ee53315b080n@googlegroups.com> |
| In reply to | #218341 |
On Sunday, July 11, 2021 at 6:29:37 AM UTC+10, Quadibloc wrote: > On Saturday, July 10, 2021 at 11:30:26 AM UTC-6, Dan Espen wrote: > > > The last place I worked had a lot of PL/I, had very firm customer > > commitments for CPU use and actively worked with IBM to keep the PL/I > > compiler efficient. I'm not aware of any issues with mainframe PL/I > > efficiency being lacking. . > Although I think the post here was talking about the time it took to > compile, not the efficiency of the generated code. . I do not have to hand comparative listings of FORTRAN and PL/I compilations and executions. OTOMH they were comparable. However, PL/I-F ran well in our 128k S/360. (It needed only 64K) What didn't run was IBM FORTRAN-H, which needed 256K. . What also didn't run was FORTRAN-E, that was so full of bugs that we had to withdraw it, and eventually we had to drop the entire OS (Release 13) and go back to Release 11. The next OS that we installed was Release 15 (or was it 16?), by which time 1100 bugs had been corrected !! . 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.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-07-11 12:46 -0700 |
| Message-ID | <1202309560.647725363.701114.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #218346 |
Robin Vowels <robin.vowels@gmail.com> wrote: > On Sunday, July 11, 2021 at 6:29:37 AM UTC+10, Quadibloc wrote: >> On Saturday, July 10, 2021 at 11:30:26 AM UTC-6, Dan Espen wrote: >> >>> The last place I worked had a lot of PL/I, had very firm customer >>> commitments for CPU use and actively worked with IBM to keep the PL/I >>> compiler efficient. I'm not aware of any issues with mainframe PL/I >>> efficiency being lacking. > . >> Although I think the post here was talking about the time it took to >> compile, not the efficiency of the generated code. > . > I do not have to hand comparative listings of FORTRAN and PL/I > compilations and executions. OTOMH they were comparable. > However, PL/I-F ran well in our 128k S/360. (It needed only 64K) > What didn't run was IBM FORTRAN-H, which needed 256K. > . > What also didn't run was FORTRAN-E, that was so full of bugs > that we had to withdraw it, and eventually we had to drop the entire > OS (Release 13) and go back to Release 11. The next OS that > we installed was Release 15 (or was it 16?), by which time > 1100 bugs had been corrected !! > . > 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. > May have been “15-16”. IIRC one release was so late they bundled it with the next release and shipped them together. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2021-07-11 13:58 -1000 |
| Message-ID | <87h7h0ies0.fsf@localhost> |
| In reply to | #218346 |
Robin Vowels <robin.vowels@gmail.com> writes: > What also didn't run was FORTRAN-E, that was so full of bugs > that we had to withdraw it, and eventually we had to drop the entire > OS (Release 13) and go back to Release 11. The next OS that > we installed was Release 15 (or was it 16?), by which time > 1100 bugs had been corrected !! os/360 release 13 was 1st (2nd?) with MVT ... we had skipped from release 11 directly to 14 ... then to combined release 15/16. boeing huntsville had got a duplex 360/67 for tss/360 to drive 2250 graphic CAD work ... tss/360 never came to production fruition ... so they tried running os/360 MVT (as two separate 360/65s) ... but as mentioned here http://www.garlic.com/~lynn/2011d.html#73 the primary justification for moving all 370s to virtual memory was that MVT storage management was so bad ... that regions typically had to be four times larger than actually used (typical 1mbyte 370/165 was nominally limited to four concurrent regions) ... going to virtual memory (16mbyte virtual address space) could increase the number of regions by factor of four with little or no paging. MVT storage management disaster increased the longer jobs ran ... and long running 2250 graphic CAD work was nearly impossible. So boeing huntsville added some virtual memory support to MVT (starting with release 13) ... didn't do any paging ... the amount of virtual memory was same as real storage ... but it addressed the enormous MVT storage fragmentation problem for longer running jobs ... being able to reorg addressable memory to create contiguous storage locations (aka part of the same reason motivating moving all 370s to virtual memory). first os/360 sysgen I did after being hired fulltime at the univ was release 9.5 (mentioned upthread). Then for release 11, I tore apart stage2 sysgen deck and reorganized all the cards to optimize placement of files and pds members for optimized arm seek (and PDS directory multi-track search) ... and stared doing as much as possible new system build in production job stream (instead of stand-alone starter system). Most notable thing I remember about release 15/16 is formating disk, you could specify the cylinder location for vtoc (instead of always cyl0, requiring seek to vtoc/cyl0 for any file lookup) ... allowing placement of vtoc in the middle of files on both sides ... cutting avg arm seek distance for high activity vtoc operations. Then before I graduate, Boeing hires me fulltime into a small group in the CFO office to help with formation of Boeing Computer Services (move all dataprocessing into independent business unit to better monetize the investment, including offering services to non-Boeing entities). I thot Renton datacenter was possibly largest in the world ... something like $200M-$300M in 360s (majority fortran engineering/scientific work) ... when I was hired, 360/65s were arriving faster than they could be installed, boxes constantly being staged in the hallways around the machine room. Machine room did have one 360/75 that did some classified work. When classified work was running there was black rope around the perimeter of the system complex with guards stationed at corners ... and heavy black velvet cloth draped over the front console lights and the 1403 printer front window and rear stacker. -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-13 15:03 -0700 |
| Message-ID | <648b3c44-a86b-434d-91e5-3ce32796c5ean@googlegroups.com> |
| In reply to | #218359 |
On Sunday, July 11, 2021 at 7:58:45 PM UTC-4, ly...@garlic.com wrote: > http://www.garlic.com/~lynn/2011d.html#73 > the primary justification for moving all 370s to virtual memory was that > MVT storage management was so bad ... that regions typically had to be > four times larger than actually used (typical 1mbyte 370/165 was > nominally limited to four concurrent regions) ... going to virtual > memory (16mbyte virtual address space) could increase the number of > regions by factor of four with little or no paging. I don't have my S/360 history handy, but wasn't a foundation to these problems the focus on Future System instead of upgrading System/360? If I recall correctly, they suddenly realized FS wasn't gonna work and S/360 was obsolete so they rushed out S/360 with some improvements, but not a lot. First was the S/3x5 series, then later the improved S/3x8 series which I think was a lot better. An old boss told me virtual storage was not a big deal. It offered a little improvement, but came with a cost. First, the operating system was a lot more complete. Second, it was very easy to go too far creating paging problems, or even thrashing where the system would grind to a halt. It seemed to me in S/370 days demand for service exceeded computer horsepower to provide it. Online processing was a resource hog in both CPU, memory, and disk. We could handle five terminals on our S360-40 under MTCS. But 500 terminals on our 158 was another story, basically it was too much. We'd upgrade, but as soon as we upgraded we added another application.
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2021-07-13 18:19 -1000 |
| Message-ID | <87tukxil2m.fsf@localhost> |
| In reply to | #218373 |
undefined Hancock-4 <hancock4@bbs.cpcn.com> writes: > I don't have my S/360 history handy, but wasn't a foundation to these > problems the focus on Future System instead of upgrading System/360? > If I recall correctly, they suddenly realized FS wasn't gonna work and S/360 > was obsolete so they rushed out S/360 with some improvements, but not > a lot. First was the S/3x5 series, then later the improved S/3x8 series > which I think was a lot better. motivation for 370/165 (and all other 370s) to virtual memory took hold before FS took over the company. Initial OS/VS2 release 1 was SVS ... little different from running MVT in a CP67 16mbyte virtual machine ... except MVT built the virtual address table and was able to do page faults (but not efficiently or optimized, since they expected little or no page faults) ... biggest issue was fitting CP67 CCWTRANS into EXCP/SVC0 channel program processing ... which created a copy of the passed channel program replacing CCW virtual addresses with real. part of discussion from archived post (from bit.listserv.ibm-man, could also be found in the google newsgroup archives) http://www.garlic.com/~lynn/2011d.html#73 Of course, the estimates for OS/VS were based on a misperception. The Kingston estimate for OS/VS2 Release 1 (SVS) had an estimate for the work needed for Release 2 (MVS), but it was couched as release 1 cost plus a delta - in other words, the same cost as release 1 plus some more. Since the Kingston resources were being redeployed to FS, that meant that there weren't going to be enough people to do both. Since MVS was supposed to be the glide path for FS (which would be OS/VS2 Release 3), this was unwelcome news. xxxxx and yyyyy modified the plan to reuse some of the SVS resources plus people transitioning from OS/360. Bob Evans did his part by cutting a year off the MVS development schedule. ... snip ... I continued to work on 360/370 all through the FS period ... even periodically ridiculing what they were doing, which wasn't exactly a career enhancing activity (lot of stuff was never really worked out ... just pie-in-the-sky waving hands). long winded discussion of FS ... including when it finally imploded, quick&dirty 3033 and 3081 efforts were kicked off in parallel http://www.jfsowa.com/computer/memo125.htm Note that 370 virtual memory architecture had a whole bunch of features ... however the 165 hardware people complained that if they had to implement all the architecture features ... it would delay virtual memory announce by six months ... as a result features were dropped to get 370/165 virtual memory back on schedule ... and other platforms that had already implemented the full architecture had to remove the dropped features and any software developed that used the dropped features had to be rewritten. Future System disaster in the 70s ... from Ferguson & Morris, "Computer Wars: The Post-IBM World", Time Books, 1993 .... reference to the "Future System" project 1st half of the 70s: ... and perhaps most damaging, the old culture under Watson Snr and Jr of free and vigorous debate was replaced with *SYNCOPHANCY* and *MAKE NO WAVES* under Opel and Akers. It's claimed that thereafter, IBM lived in the shadow of defeat ... snip ... Major motivation for Future System was clone controllers ... an objective was to make the interfaces so complex that the clone makers wouldn't be able to follow ... some folklore was that 37x5 telecommuncation box was one of the few that tried to still meet the FS objective (with VTAM & NCP). Note, during FS, internal politics were shutting down 370 projects ... and the lack of new 370 products during the FS period is credited with giving the clone processor makers (like Amdahl) their market foothold (effort to thwart clone controllers enabled clone processor makers). clone trivia: At the univ. I had taken a two semestor hr intro to fortran/computers ... then within a year, univ. hires me fulltime to be responsible for ibm mainframe system (306/67, but ran as 360/65 with os/360). Then three people from science center came out in jan1968 and installed cp67 and univ. let me play with it on weekends. Original terminal support had 2741 & 1052 terminal support with automagic terminal type identification. Univ. had tty 33s and a 35 ... so I added tty/ascii terminal support and extended automagic terminal type support to tty/ascii. I then wanted to have single dialin phone number for al terminals ... single "hunt group" https://en.wikipedia.org/wiki/Line_hunting didn't quite work ... IBM took shortcut in the terminal controller, why it was possible to change the terminal type port interface with the SAD CCW ... couldn't change the line speed (aka work for leased lines). This help prompt the univ. to do a clone controller project ... build a channel interface board for a Interdata/3 programmed to emulate a ibm telecommuncation controller ... with the addition of being able of doing dynamic line speed determination. This was then updated with an Interdata/4 for the channel interface and clusters of Interdata/3 handling the ports. Interdata starts selling it as a clone controller and four of us get written up (for some part of) IBM clone controller business. Perkin-Elmer buys Interdata and continues to sell the box under their own logo. -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2021-07-13 18:50 -1000 |
| Message-ID | <87pmvlijnc.fsf@localhost> |
| In reply to | #218373 |
undefined Hancock-4 <hancock4@bbs.cpcn.com> writes: > It seemed to me in S/370 days demand for service exceeded computer > horsepower to provide it. Online processing was a resource hog in > both CPU, memory, and disk. > > We could handle five terminals on our S360-40 under MTCS. But 500 > terminals on our 158 was another story, basically it was too much. > We'd upgrade, but as soon as we upgraded we added another application. OS/360 systems had huge setup/teardown overhead ... including each file open/close was enormous overhead (I discuss in more detail in the FORTG->WATFOR in this thread). It was why CICS was so popular ... it tried to require all its resources at startup (including large blocks of storage where it ran its own storage allocation algorithms) ... including doing all file open at startup ... and then trying its best to make minimum use of OS/360 ... mostly excp for doing actual file i/o. mid-70s, I also started to pontificate that while systems were getting faster ... disk performance wasn't increasing as fast ... as well as there being huge amount of bloat. In the early 80s, I was writing that relative system disk performance had declined by an order of magnitude from early 360 days to the early 80s (i.e. disks got 3-5 faster while rest of system got 40-50 times faster). Disk executives took exception and assigned the division performance group to refute my claims ... they came back after a few weeks and basically said I had slightly understated the problem. They then respun the analysis for a (IBM user group) SHARE presentation on how to configure disks to improve system throughput.... 16Aug1984, Share 63, B874. old posts with some intro/summarry http://www.garlic.com/~lynn/2002i.html#18 http://www.garlic.com/~lynn/2006f.html#3 http://www.garlic.com/~lynn/2006o.html#68 I had compared a 360/67 with 768kbytes memory, 2314 disks and 2301 paging device ... to 3081 with 32mbytes, 3380 disks and 2305 paging devices ... even thot processor and memory increased 30-50 times, the number of users only increased four times (which was about the change in number of random access from 2314 to 3380), if disks had kept with up the rest of the system, number of users should have increased by factor of 30-50 times ... instead of only four times. trivia: previous post in thread mentions univ. hires me fulltime. along the way Univ. library got ONR (office naval research) grant to do online catalog ... some of the money went to getting IBM 2321 datacell. Effort was also selected to be betatest site for the original CICS product ... which was added to my tasks. Took awhile but shot a problem where CICS didn't document it had hardcoded some BDAM file options and it turned out the library had created BDAM files with different options ... and CICS would fail on startup not able to open the files. lots of CICS history, gone 404 but lives on at wayback machine http://web.archive.org/web/20050409124902/http://www.yelavich.com/cicshist.htm and http://web.archive.org/web/20071124013919/http://www.yelavich.com/history/toc.htm -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | undefined Hancock-4 <hancock4@bbs.cpcn.com> |
|---|---|
| Date | 2021-07-16 11:33 -0700 |
| Message-ID | <3b92dabe-71e7-4100-93a4-d7332235699en@googlegroups.com> |
| In reply to | #218388 |
On Wednesday, July 14, 2021 at 12:50:21 AM UTC-4, ly...@garlic.com wrote: > mid-70s, I also started to pontificate that while systems were getting > faster ... disk performance wasn't increasing as fast ... as well as > there being huge amount of bloat. In the early 80s, I was writing that > relative system disk performance had declined by an order of magnitude > from early 360 days to the early 80s (i.e. disks got 3-5 faster while > rest of system got 40-50 times faster). Disk executives took exception > and assigned the division performance group to refute my claims ... they > came back after a few weeks and basically said I had slightly > understated the problem. They then respun the analysis for a (IBM user > group) SHARE presentation on how to configure disks to improve system > throughput.... 16Aug1984, Share 63, B874. old posts with some > intro/summarry Not sure if this is comparable since it's the Univac 90/30 (sort of S/370 equivalent), but I had the machine to myself on a weekend and ran some tests of multi-programming performance. Our machine had the equivalent of 3330 drives. They were top loaders and we could look down through the glass and watch the head action. One thing was obvious--having multiple programs use the same drive was a performance disaster. The disk drive ran like an overloaded washing machine, shaking like crazy and the heads went in and out. Run time was bad. But even running two programs simultaneously using two separate drives was slow. Indeed, it'd be faster (wall clock) to run the two programs sequentially rather than simultaneously. I'm not sure why that was, perhaps the disk channel was shared among the drives, perhaps the CPU or supervisor couldn't handle multi-programming very well (even though supposedly the OS could handle up to five regions and we had plenty of memory). (We had tape drives that seemed pretty fast, but we did nothing on tape except backups). I know others here who used the Univac 90/30 were very positive on them, and I knew of other sites that loved them. But my observation wasn't as positive. As mentioned, I have no idea of the price/performance, other than Univac was supposedly a lot cheaper than the equivalent powered IBM mainframe, especially a new one. So, perhaps as a low end machine, equivalent to a S/370-125 (not virtual) it could do the job economically. We were speaking of optimization. The output of the 90/30's COBOL compiler had the assembler and it was definitely not optimized, and I don't believe the machine even offered that option. (I don't know about other Univacs). My impression was that because the 90/30 was a byte oriented machine, like S/360, it didn't really fit in Univac's product line of word oriented machines. For instance, a lot of Univac's programmers attempted to do stuff not allowed on byte machines, like having spaces in a numeric field and attempting to load an ISAM file by inserts, not a copy. Here's the system brochure: http://bitsavers.org/pdf/univac/series_90/Univac_90_30_System_Brochure_Mar74.pdf Bitsavers has a few manuals: http://bitsavers.org/pdf/univac/series_90/
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-07-16 22:40 +0000 |
| Message-ID | <sct1tm12nqr@news2.newsguy.com> |
| In reply to | #218425 |
On 2021-07-16, undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote: > On Wednesday, July 14, 2021 at 12:50:21 AM UTC-4, ly...@garlic.com wrote: > >> mid-70s, I also started to pontificate that while systems were getting >> faster ... disk performance wasn't increasing as fast ... as well as >> there being huge amount of bloat. In the early 80s, I was writing that >> relative system disk performance had declined by an order of magnitude >> from early 360 days to the early 80s (i.e. disks got 3-5 faster while >> rest of system got 40-50 times faster). Disk executives took exception >> and assigned the division performance group to refute my claims ... they >> came back after a few weeks and basically said I had slightly >> understated the problem. They then respun the analysis for a (IBM user >> group) SHARE presentation on how to configure disks to improve system >> throughput.... 16Aug1984, Share 63, B874. old posts with some >> intro/summarry > > Not sure if this is comparable since it's the Univac 90/30 (sort of S/370 > equivalent), IIRC the non-privileged instruction set was bit-for-bit identical with that of the 360/50. The 370 instructions came later, with the System 80 line. > but I had the machine to myself on a weekend and ran some tests of > multi-programming performance. Our machine had the equivalent of > 3330 drives. They were top loaders and we could look down through > the glass and watch the head action. Ah, you had the 8430s - lucky guy. Most sites I worked on originally had 8416s (28MB/spindle), which looked much like the 8430, complete with the glass top. These were later replaced by the 8418 - twice the capacity, but an opaque lid meant you couldn't watch the heads thrash anymore. (I did, however, find a display on the front panel which showed the length of the current seek, and could identify problems that way.) > One thing was obvious--having multiple programs use the same drive was > a performance disaster. The disk drive ran like an overloaded washing > machine, shaking like crazy and the heads went in and out. Run time > was bad. > > But even running two programs simultaneously using two separate drives > was slow. Indeed, it'd be faster (wall clock) to run the two programs > sequentially rather than simultaneously. I'm not sure why that was, > perhaps the disk channel was shared among the drives, perhaps the CPU > or supervisor couldn't handle multi-programming very well (even though > supposedly the OS could handle up to five regions and we had plenty > of memory). The supervisor was pretty disk-bound. It spent a lot of time rolling transient code into and out of memory, and many system utilities had lots of overlays. This is no doubt a consequence of trying to squeeze too much programming into too little memory. Salesmen were constantly low-balling memory requirements, and customers who scrimped and got 128K of memory soon wound up shelling out the bucks to go to 192K. I found that if the jobs weren't too disk-bound (a bit of clever design helped here), three concurrent jobs was the point of diminishing returns. You also had to watch out for CPU-bound jobs (e.g. sorts). OS/3 did not time-slice jobs of equal priority, so if one of your jobs was CPU-bound (or went into a loop), other running jobs of equal or lower priority came to a screeching halt. A later release of OS/3 added a sysgen option to change the default priority to something other than the lowest possible value; that way you could run most jobs at default priority, while specifying a lower priority for CPU-bound steps. > (We had tape drives that seemed pretty fast, but we did nothing on tape > except backups). > > I know others here who used the Univac 90/30 were very positive on them, > and I knew of other sites that loved them. But my observation wasn't as > positive. As mentioned, I have no idea of the price/performance, other > than Univac was supposedly a lot cheaper than the equivalent powered > IBM mainframe, especially a new one. So, perhaps as a low end machine, > equivalent to a S/370-125 (not virtual) it could do the job economically. They must have done something right - they sold a lot of them. > We were speaking of optimization. The output of the 90/30's COBOL > compiler had the assembler and it was definitely not optimized, and I > don't believe the machine even offered that option. (I don't know about > other Univacs). > > My impression was that because the 90/30 was a byte oriented machine, > like S/360, it didn't really fit in Univac's product line of word oriented > machines. It didn't try; it was a totally different product line. > For instance, a lot of Univac's programmers attempted to do stuff > not allowed on byte machines, like having spaces in a numeric field > and attempting to load an ISAM file by inserts, not a copy. Ouch. I remember watching a machine doing that. It was running so painfully slowly that I found it faster to cancel the job and re-write the program. > Here's the system brochure: > http://bitsavers.org/pdf/univac/series_90/Univac_90_30_System_Brochure_Mar74.pdf > > Bitsavers has a few manuals: > http://bitsavers.org/pdf/univac/series_90/ I'm just finishing up scanning the wall of OS/3 (90/30 and System 80) manuals that I was issued when I worked at Univac. I'll be uploading over 300 documents (3.5GB) to Bitsavers Real Soon Now. -- /~\ 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 | Robin Vowels <robin.vowels@gmail.com> |
|---|---|
| Date | 2021-07-16 23:13 -0700 |
| Message-ID | <ad00c448-1e86-4ebc-9318-9dc19ea377bfn@googlegroups.com> |
| In reply to | #218425 |
On Saturday, July 17, 2021 at 4:33:27 AM UTC+10, undefined Hancock-4 wrote: > On Wednesday, July 14, 2021 at 12:50:21 AM UTC-4, ly...@garlic.com wrote: > > mid-70s, I also started to pontificate that while systems were getting > > faster ... disk performance wasn't increasing as fast ... as well as > > there being huge amount of bloat. In the early 80s, I was writing that > > relative system disk performance had declined by an order of magnitude > > from early 360 days to the early 80s (i.e. disks got 3-5 faster while > > rest of system got 40-50 times faster). Disk executives took exception > > and assigned the division performance group to refute my claims ... they > > came back after a few weeks and basically said I had slightly > > understated the problem. They then respun the analysis for a (IBM user > > group) SHARE presentation on how to configure disks to improve system > > throughput.... 16Aug1984, Share 63, B874. old posts with some > > intro/summarry > Not sure if this is comparable since it's the Univac 90/30 (sort of S/370 equivalent), > but I had the machine to myself on a weekend and ran some tests of multi-programming > performance. Our machine had the equivalent of 3330 drives. They were top loaders > and we could look down through the glass and watch the head action. > > One thing was obvious--having multiple programs use the same drive was > a performance disaster. The disk drive ran like an overloaded washing machine, > shaking like crazy and the heads went in and out. Run time was bad. > > But even running two programs simultaneously using two separate drives > was slow. Indeed, it'd be faster (wall clock) to run the two programs > sequentially rather than simultaneously. I'm not sure why that was, perhaps > the disk channel was shared among the drives, perhaps the CPU or > supervisor couldn't handle multi-programming very well (even though > supposedly the OS could handle up to five regions and we had plenty > of memory). . 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. . > (We had tape drives that seemed pretty fast, but we did nothing on tape > except backups). > > I know others here who used the Univac 90/30 were very positive on them, > and I knew of other sites that loved them. But my observation wasn't as > positive. As mentioned, I have no idea of the price/performance, other > than Univac was supposedly a lot cheaper than the equivalent powered > IBM mainframe, especially a new one. So, perhaps as a low end machine, > equivalent to a S/370-125 (not virtual) it could do the job economically. > > We were speaking of optimization. The output of the 90/30's COBOL > compiler had the assembler and it was definitely not optimized, and I > don't believe the machine even offered that option. (I don't know about > other Univacs). > > My impression was that because the 90/30 was a byte oriented machine, > like S/360, it didn't really fit in Univac's product line of word oriented machines. > For instance, a lot of Univac's programmers attempted to do stuff not allowed > on byte machines, like having spaces in a numeric field and attempting to load > an ISAM file by inserts, not a copy. > > Here's the system brochure: > http://bitsavers.org/pdf/univac/series_90/Univac_90_30_System_Brochure_Mar74.pdf > > Bitsavers has a few manuals: > http://bitsavers.org/pdf/univac/series_90/
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-07-17 19:12 +0000 |
| Message-ID | <scva2r01gb4@news4.newsguy.com> |
| In reply to | #218438 |
On 2021-07-17, Robin Vowels <robin.vowels@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... -- /~\ 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 | Robin Vowels <robin.vowels@gmail.com> |
|---|---|
| Date | 2021-07-17 21:33 -0700 |
| Message-ID | <819c3d24-c0f5-48b5-998c-6bb6a5bd00e9n@googlegroups.com> |
| In reply to | #218446 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-07-18 15:20 +0000 |
| Message-ID | <sd1grk014qp@news3.newsguy.com> |
| In reply to | #218448 |
On 2021-07-18, Robin Vowels <robin.vowels@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. And rather than just sorting the work files and printing reports as successive steps, another shop standard was to kick off separate jobs to sort and print each one. Now _there_ was thrashing for you - just moved to the job scheduler. I wrote one such system for them, and found that the entire job would take about 20 minutes just to schedule, let alone run. I said to hell with their standards, wrote it in a sane fashion, and got test runs through in a minute or two. They were furious, of course, but I pointed out that they were perfectly free to change it back to their time-consuming way once I was finished testing. -- /~\ 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-20 12:05 -0700 |
| Message-ID | <c770534d-3aba-4287-b69a-d656257e9bb0n@googlegroups.com> |
| In reply to | #218457 |
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. 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. 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. 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. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2021-07-21 05:29 +0000 |
| Message-ID | <sd8bc2$k47$1@newsreader4.netcologne.de> |
| In reply to | #218479 |
undefined Hancock-4 <hancock4@bbs.cpcn.com> schrieb: > 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. 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 :-)
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-07-21 17:14 +0000 |
| Message-ID | <sd9klb01v2d@news3.newsguy.com> |
| In reply to | #218491 |
On 2021-07-21, Thomas Koenig <tkoenig@netcologne.de> wrote: > undefined Hancock-4 <hancock4@bbs.cpcn.com> schrieb: > >> 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. > > 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 :-) I wrote a utility that would take a record size and generate a table of optimum blocking factors for a 2311 or 2314 drive. My memory has faded somewhat too, but I suspect you were working with neither of them. :-) I seem to recall that 1680 was a good block size for 80-byte records on the 2314. -- /~\ 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-23 12:19 -0700 |
| Message-ID | <8a1d5cf8-ecb7-41c0-be9b-1699cbbaaee1n@googlegroups.com> |
| In reply to | #218493 |
On Wednesday, July 21, 2021 at 1:15:18 PM UTC-4, Charlie Gibbs wrote: > I wrote a utility that would take a record size and generate > a table of optimum blocking factors for a 2311 or 2314 drive. > My memory has faded somewhat too, but I suspect you were > working with neither of them. :-) I seem to recall that > 1680 was a good block size for 80-byte records on the 2314. Another challenge was allocating space for VSAM files, which could be trickier than sequential or even older ISAM files. I don't think the parameters of the IDCAMS programs, like control interval sizes, were automated and more a guesswork. Indeed, it seemed to me many programmers didn't care for VSAM, preferring to use databases (i.e. DB2, IMS, etc). But VSAM had a lot of advantages, including performance since it had a lot less overhead than a formal database system. Our 90/30 had ISAM.
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-07-24 21:35 +0000 |
| Message-ID | <sdi12l0663@news3.newsguy.com> |
| In reply to | #218528 |
On 2021-07-23, undefined Hancock-4 <hancock4@bbs.cpcn.com> wrote: > On Wednesday, July 21, 2021 at 1:15:18 PM UTC-4, Charlie Gibbs wrote: > >> I wrote a utility that would take a record size and generate >> a table of optimum blocking factors for a 2311 or 2314 drive. >> My memory has faded somewhat too, but I suspect you were >> working with neither of them. :-) I seem to recall that >> 1680 was a good block size for 80-byte records on the 2314. > > Another challenge was allocating space for VSAM files, which could > be trickier than sequential or even older ISAM files. I don't think > the parameters of the IDCAMS programs, like control interval > sizes, were automated and more a guesswork. > > Indeed, it seemed to me many programmers didn't care for > VSAM, preferring to use databases (i.e. DB2, IMS, etc). > But VSAM had a lot of advantages, including performance > since it had a lot less overhead than a formal database system. > > 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. -- /~\ 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]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web