Article View: comp.arch
Article #1652Editor & System Performance (was Re: What is a Mainframe?)
From: Clay Phipps
Date: Tue, 25 Jul 1989 15:53
Date: Tue, 25 Jul 1989 15:53
54 lines
3372 bytes
3372 bytes
In article <2968@scolex.sco.COM> seanf@scolex.UUCP (Sean Fagan) writes:
>In article <164@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes:
>
>>Most of the massive I/O bandwidth on mainframes is wasted
>>due to stupid software. They can copy files at 3 Mbytes/sec,
>>but even with only one user, editing is faster on a PC.
^^^^^^^^^^^^^^^^^^^^^^^^^
The claim made in the last clause excerpted is consistent with my experience.
>FSE, under NOS on a Cyber, was quite fast,
>for what it was used for, and for what it did.
>It had the advantage of being a full-screen editor
>without needing to respond to each and every keypress.
No. FSE *did* need to respond to each and every keypress,
as far as I'm concerned, but it obviously didn't,
because a programmer hurriedly moving the cursor around the screen
could make FSE lose track of its place. Although it's further back for me
in the mists of time, I don't recall the SPF editor under IBM MVS/TSO
ever losing its place, although it could take its sweet time to refresh
your screen.
>Helped system load a *lot*.
I'm sure that it must have, but it transferred a load
from the Cyber to the programmer, who had to compensate
by placing mental "idle loops" into editing activity.
The reason is that with FSE, the screen could make you believe
that you and the Cyber knew where you were when you didn't, allowing you
to delete or modify lines where you saw the cursor, then later find out
that the changes affected some nearby lines where the cursor didn't seem to be.
That's what I call "error-prone". I don't need an editor that helps me
to make errors.
On the other hand, although the SPF screen would freeze when the system load
increased, it could make you impatient, but it never misled you.
My 4.77 MHz PC, operating as a stand-alone computer with an SPF-style editor,
never lost my or its place, and it was plenty fast. Note that although
I am not a touch-typist, I do type in the hunt-and-peck style fairly rapidly.
A system like FSE that allows users to make errors with blinding speed,
is not something for Cyber fans to be bragging about.
[Is this topic still really "comp.arch" ? Our news-feed has been unreliable,
so I'm not certain where this thread came from or is going to.]
--
[The foregoing may or may not represent the position, if any, of my employer, ]
[ who is identified solely to allow the reader to account for personal biases.]
Clay Phipps
Intergraph APD: 2400#4 Geng Road, Palo Alto, CA 93403; 415/494-8800
UseNet: {apple,ingr,pyramid,sri-unix}!garth!phipps
EcoNet: cphipps
Technical Details
Message-ID:
<3138@garth.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!unix!garth!phippsReferences:
<125@ssp1.idca.tds.philips.nl> <20752@winchester.mips.COM> <27637@lll-winken.LLNL.GOV> <164@bms-at.UUCP> <2968@scolex.sco.COM>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!unix!garth!phipps From: phipps@garth.UUCP (Clay Phipps) Newsgroups: comp.arch Subject: Editor & System Performance (was Re: What is a Mainframe?) Summary: Making editing errors with blinding speed is not an example to emulate. Message-ID: <3138@garth.UUCP> Date: 25 Jul 89 15:53:22 GMT References: <125@ssp1.idca.tds.philips.nl> <20752@winchester.mips.COM> <27637@lll-winken.LLNL.GOV> <164@bms-at.UUCP> <2968@scolex.sco.COM> Reply-To: phipps@garth.UUCP (Clay Phipps) Distribution: comp.arch Organization: Intergraph APD, in semiarid Palo Alto, CA Lines: 54