What's the "Scroll Lock" key on my computer for?

Cecil's Columns/Staff Reports
21

Yes, and I have said that the 3270 does not have a Scroll Lock key that I can find on it, and that the mainframe/PC combo statement as-written is not correct. This is true.

But can I quote from something you wrote in this very thread?

Where is the Scroll Lock key? Can you show me an example of it, or reference? You’re picking apart what I wrote, and that’s cool and needed. But you need to either defend this statement or withdraw it. Where I get confused or make a mistake, I admit it. I expect no less of anyone responding to me.

Yes, it was explained in this thread what I meant, and it will be corrected. We do nonetheless have Macs with PC keyboards where the Scroll Lock key acts in that way. I even provided a link to an example…

No, I’m sorry, I take exception to this. The quote at hand is “You can make a program monitor a specific location in your computer’s hardware so it can do something cool (or lame, depending on your point of view) when the SysReq key is pressed.”

What is misleading about that? I ask you again, yes or no, is it your contention that one cannot make a DOS program (such as a TSR) that hooks to INT 15H and performs an action when the SysRq key is pressed? I admit I did not know about the “master plan” you assert lies for the SysRq key from IBM, but had I known about it still would have written what I wrote, because the article was meant to be a summary-level article on the other keys.

Is it not correct to say that one can make a program monitor a specific location in the hardware (INT 15H) and do something based on the hook to that interrupt?

Um, no. “DIR” and other system commands may do that. But using Windows or DOS system commands and watching the disk light is not a good test. And in any event, my statement was thus:

“where pressing this key while the DOS window is active can (depending on the program) pause program execution”

I very specifically added the “depending on the program” because I personally have a few programs I’ve written or helped develop (from the late days of DOS and from OS/2) that do what I described. I know execution stops because the output file from my program, which is a continous log of operations, does not increase in size, and because a process that takes 30 seconds to run will happily sit suspended for hours or days if I hit the key, until I hit “SPACE” or some other key.

It does this in both MS-DOS and OS/2 DOS.

I really don’t feel I’m in error on this point.

This is an odd thing to say, especially when you appear to know so much about the earlier days of computing. Few willingly hits CTRL-C or CTRL-Break, it typically is done when you are forced to kill the program due to misbehaviour or during debugging. That’s kind of the whole point of the keys. I have to hit those keys nearly every week to stop a bad feedwater heater model or turbine model when it gets stuck in a non-convergent loop.

Again, you are not reading what I’m saying. The quote at hand is this:

I said that they “have found use for it” - is that wrong? I don’t think it is. Or is it the term “operator” that gives you trouble? Well, other people do call it an “operator.” I’m sorry to use Google for this, but you give me no choice of finding an available online reference:

In Lisp:

http://www.fas.harvard.edu/~lib51/documents/handouts/style.pdf

In Python:

http://www.lib.uchicago.edu/keith/courses/python/class/5/

If calling it an “operator” gives you a headache I can at least understand that, as some people would not properly refer to the Lisp implementation as an “operator”. I think that might be unnecessarily nitpicky, however, but that’s only IMO.

Well, George, I’m sorry to be blunt as well, but in case you haven’t been actually reading what I’ve written here (which it seems you haven’t), let me reiterate to you that I said that getting the actual facts out are the most important thing. In fact, what I said was:

And I firmly believe this. So you can either show me my “hubris” and example of me doggedly sticking to a wrong assertion, or kindly get stuffed.

I still dispute several of your facts, and you have not (for the second time) defended the claim that you yourself made about the Scroll Lock key, which seems at least as large an error or point of confusion as I made. I suggest that you write up and create an article and publish it on Toasters, Touch Lamps, and then on the origin of the Scroll Lock key, and submit it to the Straight Dope, and if they find it better I’m sure they will give it the consideration it deserves.

I took this question because it seemed simple and straightforward based on the facts available, and I also had “original sources” in the form of users of 3270s as well as some 3270s around as reference. If the facts available are wrong or jumbled, then that’s good that it gets out in the open, and we need to make sure they are correct, because Cecil deserves the very best from those who try to write for him. The true facts are the facts, and there’s no use crying or whining about who’s right or hurt feelings etc. But your behaviour in such threads as the touch lamp one, which I did follow, was combative, contemptuous to the author Q.E.D. and his efforts, and in no manner helped you get your point across. And if you’re going to make side-remarks about “intellectual honesty” and me, you really are a bit off base, for while I have a long history of being right on many subjects, I also have an equally long history of being wrong on some and admitting to it.

So let’s just go point by point here, without making more manifestos about how much I’m letting Cecil down and how sub-par the Staff reports are of late in your opinion, and make sure we can either find agreement on the outstanding points of contention, or else will reach an educated impasse.

22

WHY DIDN’T YOU MENTION THE MAIN THING:
“Print Screen”, “Scroll Lock”, and “Pause” should (obviously) NOT be put into keyboards anymore. Arguing about computer’s and OS’s so ancient that 1% of the pop uses them is silly. Their functions are long gone, and any rare case where they are needed could be easily handled by Ctrl-P or some other specific hack. Sam with the Insert key (which thankfully at least Microsoft DID remove from their keyboard so it wouldn’t get accidentally hit and go into overtype more. Of course, if you DO want it, overtyper mode can be got in other ways.)

These keys are RIDICULOUSLY being designed into 2003 made keyboards. WTF for?!? Even on keyboards that are meant to take up less space (or space is at a premium.) 99.9% of the time, you could dust PS, SL, and Pause for fingerprints and not find any.

We took the crank off the front of the car, lets do away with these ancient, unused and confusing keys.
[And please-- don’t point out the extremely rare cases where they are still used: obviously, their function can still be had via ctrl-this or that (and besides-- if someone IS using an ancient system? It stands to reason they have an old keyboard as well that still has the keys.)

23

I hate to jump into the middle of a firefight, but…

You’re right, and so is George.

In DOS, you have complete access to all the hardware. You can trap INT15H and do what you like.

In a real OS (not DOS!), the OS has complete control over the hardware, and user-level programs (i.e. a word processor, command line, etc) can only access what the OS will let them access.

IBM intended SysRq to be used by a VM, which you can think of as a light-weight “meta OS”. On startup, the VM grabs control of all the hardware, and then loads whatever mix of OSes you want. Each of these OSes think they are playing with the hardware, but they aren’t - the VM is managing everything. When you press SysRq, the VM sees this and knows that you want to make a request to the VM itself. The SysRq is not passed on to whatever OS is active at the time.

So George is right, in that the intent for SysRq was that it would be a priviledged key that would be handled by the VM, and no mere user program (or even OS0 would be able to access it, even if the program were running in DOS.

And you are right, in that if you aren’t running a VM and you are using DOS, you have complete access to all the hardware, including SysRq.

24

I agree. Microsoft should come out with a simplified keyboard, with only the keys you’ll use all the time. Something like this: http://pauillac.inria.fr/~xleroy/stuff/ctrl-alt-del.jpeg

25

I agree. OTOH, I’m also of the opinion that every backward-comptability issue since DOS 2.0 was released should have been handled by Microsoft saying, “Get with the program – literally”.

The gripping hand is that if you think Bill Gates is the Antichrist in our timeline, you should get a peek at the pitchfork-and-torch-bearing mobs that would have descended upon Redmond in that alternative history.

26

PrtSc is used in Windows XP (at least). It puts a snapshot of the screen (if unshifted) or current window (if shifted) into the clipboard.

Pause is used in Windows XP. It still does in the command window what it always did in DOS.

Scroll-Lock is used by many programs, some of them even to enter a shift-lock mode.

SysRq is, at a minimum, used by 3270 emulators.

A keyboard without any of these keys is a broken keyboard.

27

Well, I use print screen all da time. :: so there.

I find it all very interesting and informative.

I find the attitudes of a few insulting and overbearing and no matter how correct they are, I seem to tune them out.

Learn a lesson in teaching and being a class act from Una…

28

I want a button that sends a heavy-duty electric shock backwards through email to the senders of spam. Call it “JstDsrt” … but I suppose that thread belongs in a different forum.

29

Ok, I had a “senior moment” when I suggested the 3270 had a “Scroll Lock” key.
That sentence should have been much more explanative, and in subjunctive mood, something like: "If the 3270 had a Scroll Lock key, it still could not do anything locally to the screen, as the 3270 had very limited internal logic-- it could, at most, send the keypress back to the mainframe; then perhaps the mainframe program could reformat it’s output to somehow “Scroll Lock” the output.

---------------------------------------------------- Next point:

“What is misleading about that? I ask you again, yes or no, is it your contention that one cannot make a DOS program (such as a TSR) that hooks to INT 15H and performs an action when the SysRq key is pressed?”

I’m sure you know, there are a bazillion of statements that are logically TRUE, but either useless, tautologies, or very bad ideas:

“You can set up a trap for the SysReq key”: TRUE, but useless info, as in DOS you have access to each and every bit of every I/O port. Doubly useless too, as in newer OS’s all the BIOS calls are trapped and simulated by the underlying OS, which often returns subtly different information that the original BIOS call, often info that lets the old DOS program multi-task better.

“You can go swimming in San Francisco Bay”: TRUE, but you’ll probably perish with all the tanker traffic, the 37 degree water, the rip-tides, the rocks…

So your SysReq statement, while at least half-true, would be considered I suspect, by many a knowledgeable and disinterested observer, as being less than helpful. No personal dig intended-- you’re not responsible for IBM’s softpedaling of this feature, or various BIOS book re-writers similarly losing bits of crucial background information.

Another way to judge your SysReq explanation: Pls judge if this is a fair analogy.

Let’s say Ford comes out with a new model SUV with a new button on the dash labeled “ST. EJC.” It’s there, with some wires that go off to a main connector plug, but dead-end there. Not many people read the car’s manual that states that this button is for a rarely ordered special feature, an ejection seat. A few car magazines and books put this info, in watered down form in their publications, saying something a bit less specific, such as “This is a rarely-used button, usually not hooked to anything”, with a little information lost in the translation.

Now you come along, read this watered-down info, expand it a bit by saying “You can hook up this button to whatever you want, like to turn on your sub-woofer”

The information has undergone a slight dilution at each step. You really can’t blame anybody for this, it’s just the way the research and writing process works. But I suspect many people would be dissatisfied with losing the CRITICAL bit of information, that this might be a VERY dangerous button to mess with!

“where pressing this key while the DOS window is active can (depending on the program) pause program execution”

It does NOT pause program execution! See below.

"I very specifically added the “depending on the program” "

It has nothing to do with the program. It’s part of the CON: console driver, perhaps tweaked a bit by Windows.

What really happens is when you press Pause, the keyboard handler (part of DOS) sets a flag in the low-memory BIOS area at 0040:0000, then the next time your program writes to the CON device (which is the standard way programs are supposed to display text), the CON driver sees the pause flag and then loops internally until the pause flag gets cleared.

In a DOS box under Windows, it gets much more complicated, as Windows can’t have the CON driver spinning it’s wheels, so Windows has some super-clever code that can tell when the CON driver is looping, and the Windows does a very high-level “task-switch” to let other programs run for a time-slice.

To complicate things even more, your more sophisticated DOS programs would try to bypass the CON driver and handle the screen and keyboard directly. To handle this case, Widows has some really-super-spiffy code that does a statistical analysis, whereby it totes up how often a program has touched the screen and keyboard, how often the program has gotten a “keyboard keys are all up”, and then Windows task-switches away from any program that seems to be wasting time in a keyboard polling loop.

Soo the bottom line is, the “Pause” key does NOT stop the program, it stops program OUTPUT, but it does not stop program execution. If your program is generating output at that instant, and it’s directed to the screen, AND it is doing so thru the old and clunky CON driver, then your program will be effectively paused, but not due to any explicit pause that’s detected or handled by either the program itself or the CON driver. Also any interrupt hooks in your program will continue to run unimpeded. And to muddle things further, Windows XP has a Huge COn output buffer, so your program can generate many screens of output, can continue running for a LOOOONG time, before the actual screen output gets sent to the final CON handler, which only then might pause execution of your program. Whew.
Also the “Pause” key has NOTHING to do with a particular program, it’s all handled at the CON driver level, and sometimes faked out by Windows.

I’m surprised you didnt take the hint from my DIR demo suggestion. But, nothing personal, but you seem to have but a faint acquaintance with the way programs, DOS, the BIOS, and Windows are layered. It would be much safer at your level of expertise to add a few qualifiers, like “As far as I know”, or “It seems to me”, or “without any direct knowledge of the internals…”. Much safer than making categorical statements that are easily shown to be incorrect.
Regards,

grg88

30

grg88,

Your information is interesting, but does not explain why my DOS programs pause when I hit the Pause key. When I hit Pause, not only does screen output stop, but program execution does as well. How did I verify this? By running my program, hitting Pause, waiting a half hour, and hitting Space to resume execution.

When my program in question runs, it runs for about 15 seconds and generates about 200 characters of text, in the form of 9 diagnostic messages. When I hit “Pause” after message 5, about 6 seconds have elapsed. If I go away from the computer and return half an hour later, then hit Space, the program resumes, running for about 9 seconds more. It does not take a 2GHz Windows machine 9 seconds to dump the remaining 100 or so characters of text to the screen. And temporary files written to disk remain OPEN during that entire time, and unfilled with data. I cannot edit the contents because the file “is in use” according to windows, but I can “TYPE” the contents to another file and verify that they are not completed. Thus, it is not a case of the Pause button stopping just output, it is stopping program execution as well.

I’m not saying I disagree with your statements above, because I am uncertain if we are talking about the same situation. Let me recap:

Normal Operation: Program runs 15 seconds, generates 9 diagnostic messsages to the screen. During this time it also writes an 80kb file to disk throughout.

Pause Operation: Program runs 6 seconds, generates 5 messages, and Pause is pressed. Program does not generate further screen messages, and the log file remains open, thus not hitting the code that closes said file. If I wait half an hour or so and return, the program picks up, runs about 9 seconds more, generates the rest of the screen messages, and closes the logfile.

So what exactly am I missing here? The effect as I see it is to pause program execution because of the following criteria:

  1. Output to the screen stops.
  2. Output to the logfile on disk stops.
  3. The logfile is held open by Windows.
  4. The total program execution time, as observed whilst off-Pause, is identical (or as identical as can be observed)

So screen output stops, disk output stops, the program does not finish executing, it is only outputting about 200 characters of text so it’s not filling the CON buffer…what’s happening here? It’s as Paused as Paused can be from my viewpoint.

I still await your comment back on CTRL-BREAK. I can assure you that it does kill the programs in each and every DOS window I bring up on NT and XP. What exact line do you claim must be added to config.sys to do this? The Config.sys on the machine I"m using right now which allows me to use CTRL-BREAK contains only the following:

DEVICE=C:\CDROM\IBMTPCD.SYS /R
rem DEVICE=C:\CDROM\IBMTPCD.SYS
DEVICE=C:\DOS\SETVER.EXE
DEVICE=C:\DOS\HIMEM.SYS
DOS=HIGH
FILES=30

Which of these lines, exactly, is the one you claim needed to be added in order for CTRL-BREAK to work? I see two CD driver lines, SETVER to load the DOS version table, the high memory driver lines, and a files statement.

I think we need to explore each of the points you brought up in detail. I also think we need to address exactly what you feel was wrong about the use of backquote in Lisp and Python as well.

You’ll be pleased to note that I have sent to Ed a re-written article which should be more correct, and to answer the question more directly and avoid the quagmire of the origin of most keys, focusing on their function under the PC realm. I certainly have no desire to have incorrect information out there, and thus several things (and a couple of typos) have been changed. However, there are some outstanding issues here.

I can see why you feel that the SysRq explanation is lacking, but in the context of the question and the level of detail demanded by the questioner I feel it is nonetheless a correct answer. You will, of course, disagree with this, and I would expect no less. I do not agree with your assessment of the Pause key action, I do not agree with your claim that CTRL-BREAK requires special code in the Config.sys to work, and I await further discussion on why what was written on the backquote was incorrect.

I didn’t take your hint, as you term it, because I did the testing myself, and found your explanation lacking. And I still find it lacking, as well-intentioned and detailed as you have made it.

And I’m not an expert on the layering of DOS, Windows, and BIOS, this is true. All of those people were unavailable due to a huge Teletubbies convention in Leeds.

31

Ok, I was a tad unclear in explaining the intricacies of the Pause key. Let’s see if I can explain it this way.

If you have a program that is not writing to CON, the pause key will NOT affect the program’s running in any way. If it was busy computing 100 digits of Pi per second, after you press the Pause key, it will still be computing 100 digits of Pi per second. That’s what my “DIR /S C:\fo.foo” example was all about. You can press Pause and the DIR command keeps humming away. The fact that “DIR” is an “internal command”, part of COMMAND.COM, doesnt make any difference in the semantics of Pause. Any command, or program is going to act mostly the same, pace the odd program and the Duke Nukem’s that rip out the BIOS and DOS keyboard handler code by the roots and handle every keypress themselves.
If instead you have a program that periodically writes to CON, (not PRN, the pseudo-pinter device, not directly to the screen, not drawing characters either to the graphics memory either, it has to be a clean and direct write to CON thru the int 21h system call),
then the Pause key MIGHT stop the output. Then depending on the number of layers of output buffers that DOS, DeskView, and Windows have added to the CON driver, if and when those buffers fill up, eventually the program WILL effectively be stopped. It’s like when the school crossing guide walks out into traffic, perhaps a few blocks ahead of where you’re guy watching at an Internet cafe. You may notice far fewer cute guys driving by. Nobody is intentionally adding uglies, it’s just an indirect effect of the school crossing guide blocks away. In roughly the same niderct ways, nobody is stopping your program from running, it’s just unable to proceed because it’s trying to write to CON, and CON can’t return to your program as it has a mandate to print those characters before returning to your program.

About config.sys, you’re being confused by Windows/XP rather complex way of defaulting. Windows/XP has a default set of config.sys commands hiding away somewhere. Do a google on “config.sys break” to get several references on how this option is supposed to work. I suspect if you add BREAK=OFF to your CONFIG.SYS, hen you’ll see a difference. “Command prompt” windows are intentionally not called “MSDOS prompt” anymore, as finally in NT/XP/2000 there is no old COMMAND.COM anymore, t’s a totally rewritten and mostly back-compatible CMD.EXE, which is not required to obey all the old CONFIG.SYS options faithfully.

Regards,

grg88

32

grg88

I will review your points later today and see if they make more sense to me upon your further explaination. I believe I understand you, but I think the only way I can test it with the particular program in question is to re-compile my program to not print any output to CON at all and then see if it pauses. I do not believe I have any DOS programs still that do not write any messages to the CON. I have some OS/2 ones, but we really don’t want to be mixing operating systems at this point, do we? OS/2 interfaces with the BIOS very differently than Windows does, which is one thing I do know about the relationship between the BIOS and the OS.

Actually, the config.sys I printed from earlier was from laptop #2, which is Windows NT 4.0.

I will add, however, that you are incorrect in that there is in fact a “command.com” in c:\winnt\system32, and a “cmd.exe” in C:\winnt\system32 as well. It is a different size and timestamp than my DOS 6.2 command.com. And I can change which one I ise by changing the “comspec” system variable in NT.

Windows XP also features both of these files, as my laptop #4 which has only XP Pro on it does contain both a “command.com” (located in C:\windows\system32) and cmd.exe (also located in C:\windows\system32). In fact, oddly, I was just on a site yesterday on “XP Tips and Tricks” which noted that both command interpreters do still function in Windows XP, with the older “command.com” included for backwards compatibility.

It is true that the default command shell is “cmd.exe”, if that is what you meant. But “command.com” still exists, and does still run, and I did test-run my application within it just now to make certain of that.

Here is one of numerous links that show that both command.com and cmd.exe are part of even the newest Windows XP.

http://www.ntfaq.com/Articles/Index.cfm?ArticleID=39566

33

“I will review your points later today and see if they make more sense to me upon your further explaination. I believe I understand you, but I think the only way I can test it with the particular program in question is to re-compile my program to not print any output to CON at all and then see if it pauses.”
There’s a shortcut that usually works, without recompiling, just run the program with:

>myprogram >out.txt

That usually results in the output going to out.txt instead of CON.
The file system driver has no concept of pausing file writes,
so this should get the pause key out of the loop.

You should notice your program then runs to completion even with the dang Pause key pressed.

And you’re right, there is a old DOS compatible COMMAND.COM in Win NT/XP/2000. That was not an issue I think. What’s different is the default shell is different, with different start-up defaults.

And I should say your research would be just fine in a less precise field, or a less precise forum. if your research was in the areas of Law, Politics, Sports, Chiropractic, Economics, Pop Culture, Art History, or Fashion, there a certain amount of creative interpretation is expected, and exactitude isnt even in the top 10 requirements. But when you choose the unforgiving area of Computer Science, and TSD as the forum, you gotta expect a much higher standard.
Regards,

grg88

34

<< But when you choose the unforgiving area of Computer Science, and TSD as the forum, you gotta expect a much higher standard. >>

I don’t pretend to understand more than about three words in each post here, but I do understand that the HISTORY of computers is NOT a “precise field.” There were dead ends, there were aborted attempts, there were what-ifs, and there were lots of bits that come into play. We’re not talking about what IS, but about what WAS, and there are several different (equally valid) versions of what WAS. It’s not a linear history.

So, settle down. No insults are permitted in this forum. Discussion and debate, related to a Staff Report, fine. But no personal insults. Period.

35

It seems like it should from the way you describe the handling of it, but I am seeing the same behaviour as I noted before. I will have to do some further testing with other programs to find out why, or to see if perhaps this application is trapping the Pause key (I admit I do not know if that is possible, but it’s another thing to check). They are all FORTRAN programs designed to be run from the command line, and as such may trap several keys for operability. I honesly don’t know yet. In any event, I think we can at least agree that a DOS program which has screen output like this (which is probably almost all of them) will be effectively halted during execution when the Pause key is pressed, as I demonstrated above.

Thank you for your comments. As I said repeatedly, all I’m interested in are the facts, as are the rest of the Straight Dope team, and we don’t have hurt feelings over being confused, mistaken, or wrong on any points. But sometimes the “facts” are not very unambiguous, as has been seen here. If we make a mistake, and someone shows us that we have, and we fix it, then I see that as a good thing.

If by “research” you mean my general level of research abilities, then I suggest you stick around and read my next Staff Report when it is posted. I think it’s safe to say that I expect to see your comments when it goes up.

36

I think He still uses an Amiga. And, hoo boy!, is He ever ticked off that He doesn’t know what the hell y’all are talking about. :wink:

37

The pedantic arrogance of many computer geeks regarding their field is perhaps understandable, since so many of them probably have absolutely nothing else whatsoever to crow about in life. But the insults and just plain nastiness put forth by certain members in this thread are ghastly. Reading some of the sludge in here gave me a distinct feeling of being transported back to the adolescent “I know more about computers than you do!” wars so common on nerd BBSes in the '80s. And I strongly suspect that a couple of the posters here are carrying the stain of that legacy in their psyches. (“Atari suckz! Commodore rulez!” “No, Commodore suckz! Apple rulez!” “Windows sux! Linux rulz!” “You suk! I rule!”) Obviously, for some geeks, regardless of age, the eagerness to “prove” how much they know and what “experts” they are completely trumps all standards of politeness and civility generally expected in decent society.

Whatever minor flaws or misstatements may have appeared in the article by Una Persson cannot possibly excuse the virulence of some of the responses.

And as a matter of fact, the respondents who have been most bilious and vehement (and verbose) in their condemnations and “look how smart I am!” self-trumpeting have all been wrong about some point or other somewhere in their retorts, in addition to being mean-spirited, nit-picking and extremely rude. As a professional computer geek, I’m ashamed to see my alleged peers behaving like ill-mannered, undisciplined, attention-starved children.

Una, regardless of the petulant pickiness (and prickliness) of those who have the social graces of spoiled ten-year-olds, I thought you did a good job of covering your points in a manner well-suited to the layman (who, after all, the article was aimed at), and whatever minor errors might have appeared were quite unimportant in the context of what you were trying to convey.

38

I don’t blame people for being frustrated with the wrong information being posted in an early article. There were serious problems with the origin claims I made regarding the 3270 keyboard (by “serious problems”, I mean, it was WRONG). My sources were unreliable on this, and the article has been fixed to reflect the better information available. Some of my sources have since been beaten; others have had their manhood insulted via e-mail.

There has been frustration expressed in other Staff Reports of late as well. I feel that a less adversarial approach would be much better for complaints on any Staff Report in the future. I think I can speak for anyone who writes Staff Reports in that we are people who uniformly want the best information possible to be out there, both comprehensible and readable by the widest audience.

As I said, the latest article has now been updated to fix things that were found to be wrong, to make some language much less ambiguous, and to fix a couple of typos that were remaining. It is a much better article on many levels, and at least for the computer novice/mid-level user provides a decent level of explanation without going into the deep, deep parts behind the scenes.

My next article has a hardcopy reference for every single point in it, and is having every single line reviewed by angry, bitter, cranky, even openly hostile fellow Engineers, and thus the result should be more “Cecil worthy”.

39

What a lovely display of both anti-intellectualism and blatant hypocrisy in a single post!

40

Well, opinions vary. Some will think this is all a tempest in a teapot. Others may see it as a spirited and vigorous debate on accuracy in media, accurate reporting vs. stream-of-conciousness, versimilitude vis-a-vis existentialism. We all come at this from various backgrounds, viewpoints and expectations. A certain amount of disagreement inevitable.

IMHO the discussion’s been quite civil, at least compared to the spittle-fests that go on in the really techie newsgroups. I see no incivility in pointing out major bloopers, especially if one concedes that to bloop is human, we all have brains that are excellent at putting related facts together, and sometimes tying very unrelated factoids into a neat little story, plausible, but in the whole, quite misleading.