razzell@ubc-vision.UUCP (Dan Razzell) (05/07/86)
What is the purpose of DUMP periodically repeating its prompts to
mount a new tape, ask for retry, etcetera? Seems redundant to me, and not
in the spirit of Unix, to nag the user in this way and fill the terminal
with verbiage. I've seen this technique elsewhere (eg. VMS BRU,) which
might historically explain, but not excuse, its adoption in Unix.
If calling attention is all that's needed, why not just beep the terminal?
It might be necessary to put out a carriage return along with the beep to
keep the terminal buffer from overfilling.
On the same subject, DUMP's prompt lines are too long; couldn't they be
trimmed to 80 (or even 72) characters to avoid ugly wrapping?
The machine room environment is noisy enough without adding visual noise,
n'est-ce pas? :-)
--
______________________________________________________
.^.^. Dan Razzell <razzell@vision.ubc.cdn>
. o o . Laboratory for Computational Vision
. >v< . University of British Columbia
______mm.mm___________________________________________ggs@ulysses.UUCP (Griff Smith) (05/08/86)
> What is the purpose of DUMP periodically repeating its prompts to > mount a new tape, ask for retry, etcetera? Seems redundant to me, and not > in the spirit of Unix, to nag the user in this way and fill the terminal > with verbiage. In our center, the user is an operator. A mild reminder that (s)he has taken too long seems appropriate. The entry on the log file generated by the backup script is also useful for monitoring speed of service. ... > On the same subject, DUMP's prompt lines are too long; couldn't they be > trimmed to 80 (or even 72) characters to avoid ugly wrapping? I would rather have a clear command to the operator than a cryptic comment intended for a wizard. The carriage on our operator's hard-copy console is 132 wide; wrapping is no problem. Are we talking about the same program? Most of the output from "dump" is 60 characters or less. > -- > ______________________________________________________ > > .^.^. Dan Razzell <razzell@vision.ubc.cdn> > . o o . Laboratory for Computational Vision > . >v< . University of British Columbia > ______mm.mm___________________________________________ -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs ( {allegra|ihnp4}!ulysses!ggs )
libes@nbs-amrf.UUCP (Don Libes) (05/11/86)
In <1252@ulysses.UUCP> Griff Smith <ggs@ulysses.uucp> writes: > In <138@ubc-vision.UUCP> Dan Razzell <razzell@vision.ubc.cdn> writes: > > What is the purpose of DUMP periodically repeating its prompts to > > mount a new tape, ask for retry, etcetera? Seems redundant to me, and not > > in the spirit of Unix, to nag the user in this way and fill the terminal > > with verbiage. > > In our center, the user is an operator. A mild reminder that (s)he has > taken too long seems appropriate. The entry on the log file generated > by the backup script is also useful for monitoring speed of service. Saying you can track operator speed through the number of dump's nags is not a good enough reason. A reminder is a reminder...if the operator is going to ignore one, your operator has a problem. Needless to say, these message annoy me, but for a different reason...they cause important information (particularly kernel and driver messages) to scroll off the screen. And this brings me to the real subject. We have various systems with an assortment of console devices, namely 1) Decwriter, 2) VT100 and 3) Sun monitor. They each seem to have drawbacks. For example with (3), when the server crashes (in a severe enough way), it clears the screen and/or does not log the panic. Sometimes it reboots (or a user reboots it, or power goes off momentarily and it autoreboots) and we lose this information. (2) is slightly different. The Sun never clears the VT100's screen, however, messages scroll off much quicker, since it is only 24-lines. (And with >80 character "mild reminders", this occurs all too quickly.) (1) has the obvious problem that sometimes you really need to do editting on the system standalone, and you are reduced to line-editting. I wouldn't mind being able to leave a Decwriter on the console but be able to switch to a standby crt (cheap $), but the Sun will crash if we disconnect the console. Maybe I should build a switch just on the receive data line? Is this incredibly stupid? What do other people do? Has anyone considered using a PC? This would enable you to keep logs of what really appeared on the console, plus you could keep it on disk indefinitely. Of course, you still have the problem of powerouts affecting the PC. I'm really starting to lean towards the Decwriter, even though it sounds grotesque. Don Libes {seismo,umcp-cs}!nbs-amrf!libes
chris@umcp-cs.UUCP (Chris Torek) (05/11/86)
In article <138@ubc-vision.UUCP> razzell@ubc-vision.UUCP (Dan Razzell) writes: >What is the purpose of DUMP periodically repeating its prompts to >mount a new tape, ask for retry, etcetera? I always thought it was so that one could turn dumps over to `operators' with somewhere from little to no knowledge of the system itself. We like to have those who can program to do so, rather than run dump. (Unfortunately, good `operator' types are hard to find; we stick wizards-in-training on dumps.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
bzs@bu-cs.bu.edu (05/16/86)
(are we nitpicking yet?) I use dump a lot, so do my operators (a lot more, at least two or three times a day), I've never heard dump being too verbose come up in a conversation and we bitch about everything if for no other reason than to maintain human contact. I think the complaint that it wastes paper is a red herring, computing centers use massive amounts of paper and shortening out a few lines of messages from Dump would be the last place I would look to economize, hey, I've got students running off resumes like they were on the Times' best sellers' list. A decent preview for TeX would probably save the lives of millions of trees in America...need I go on? I think it repeats itself simply because on a paper console it's easy to lose a prompt if you walk away for awhile. The nature of a dump is that the tape can take a fairly long and indeterminate amount of time to spin. The nature of consoles is console messages, that's what it's there for, no? If you did dumps in my shop on a CRT I would tell you to go use the paper console, we save our console logs and if I go back to a dump tape and it isn't right I want to look up the dump that was done to see what went wrong if possible. A dump here is critical and treated like a banking transaction. I think this is a non problem, why don't you write a filter that removes what you don't want to hear and say 'dump |& filter' or something like that and see if it's any better? Finally, you try to use 'employee relations' as a possible point of contention. Although it certainly would be possible to harass a person with a program they have to use (keystroke counting is a notorious example for data-entry clerks) I doubt very much this even approaches that. Why don't you just offer to go for coffee once in a while and leave it at that. He thinks we are trivializing his complaints, I think it's a trivial complaint and regret having written this much. Maybe switch this to net.unix or even net.cog-eng as that's the realm you are in, changing the strings in a program is not a terribly wizardly issue, is it? (prompts, strings whatever.) -Barry Shein, Boston University