phipps@garth.UUCP (Clay Phipps) (07/25/89)
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
hascall@atanasoff.cs.iastate.edu (John Hascall) (07/26/89)
In article <3138@garth.UUCP> phipps@garth.UUCP (Clay Phipps) writes: >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. > [...Cyber editors are: fast xor correct...] To get decent screen I/O performance out a typical mainframe takes some doing (but it obviously can't compete with memory mapped PC screens for a single user). Our NAS 9160 (an IBM-alike) uses two UVAXIIs as terminal/editing front-ends as below (there is also a VS2000 which does the same for telnet sessions): +------------+ +--------+ | | channel | | | NAS 9160 +=========+ uVAXII +~~~~~~~ fiber to campus backbone | | | | to serial terminal lines +------------+ +--------+ and each uVAX supports 90 terminal seesions (the capacity of the fiber link) each doing full-screen editing as fast as you can type. The uVAX takes care of all the cursor stuff and just reads/sends lines/pages over the channel as it needs. John Hascall (at least this topic is *hopefully* swinging back toward architecture)