follmer@hplabsb.UUCP (02/06/86)
I was wondering if anyone out there has some horror stories about the computer industry; crashed systems or lost backups. For example, I heard a story once about a guy who lost a month's worth of code due to some backup problem. This was about 6 in the morning, and apparantly, the guy caught the next plane to Nepal and joined a monastery. This is the best it could be pieced together since he hasn't been heard from since. He just drove to SFO international, put the ticket on his Master Card, and disappeared. Case closed. The guy was pretty upset, but on his way out the door, according to the guard, had a wild grin of calm and happiness, as though he'd won the last round with the machine through some Deux ex machina. Have you heard any similar stories?
mrgofor@mmm.UUCP (MKR) (02/07/86)
In article <14700001@hplabsb.UUCP> follmer@hplabsb.UUCP writes: > >I was wondering if anyone out there has some horror stories about the >computer industry; crashed systems or lost backups. For example, I heard >a story once about a guy who lost a month's worth of code due to some >backup problem. This was about 6 in the morning, and apparantly, the >guy caught the next plane to Nepal and joined a monastery. This is the >best it could be pieced together since he hasn't been heard from since. >He just drove to SFO international, put the ticket on his Master Card, >and disappeared. Case closed. The guy was pretty upset, but on his way >out the door, according to the guard, had a wild grin of calm and happiness, >as though he'd won the last round with the machine through some Deux >ex machina. > >Have you heard any similar stories? At a customer site several years ago (before customers knew about backups) I watched a colleague reverse the order of source and destination devices and back up a brand new 50Mb blank disk cartridge onto the customer's disk pack. The customers had never done a backup (they had had the system for several months). He was somewhat embarrased. Then there was the time I was consulting independently - helping someone add more hardware interface cards to the chassis on an Interdate 6/16. Not having the right tools for a particular job, I had to kluge up a paper clip (the ultimate tool). Unfortunately, this clip got away from me at just the wrong time and fell down the wire-wrap posts on the backplane like a pachinko ball. It managed to fall between th +12v line and a +5v line - shorted out and blew up every board in the computer (just the line drivers, but still...). That, too, was somewhat embarrassing. --MKR
jimm@amiga.UUCP (Jim Mackraz) (02/11/86)
:: the venerable rsmith told a story about a consultant who once worked at a site which had somehow made 'cd' stand for 'clear disk'. Punchline is obvious.
rob@ctvax (02/11/86)
Ed Yourdon used to (maybe he still does?) tell the story of a night shift operator on a PDP-11 with a bunch of RK05 drives, who had a head crash and tried to recover by swapping cartridges. Before he stopped for help, he'd knocked out five drives and eleven cartridges! Then there was the compiler project at CDC many years ago. The whole team got pulled off for a few weeks on a rush job. When they got back to the compiler, everyone thought someone else had saved the sources. The archives had been reaped in the mean time. None of the sources (about one and half man-years of coding) remained.The story goes that someone had kept an OLD listing, which was submitted to the keypunch (I said it was an old story!) department. --Rob Spray ...ctvax!rob
roman@sigma.UUCP (Bill Roman) (02/13/86)
Some years back I was working at the R & D center of a major
company, developing software on a PDP-11. Of course we were all
researchers and scientists and too busy to run backups - but our
little machine was right across the hall from the center's main
computer, and every morning at 4 am the night shift operator came
over, booted the dump utility and backed up our disk. This worked
fine until we had the inevitable disk disaster and lost everything.
No problem, just load the backups... uh, oh.
The dump program was a stand-alone system that bootstrapped itself
from the beginning of the tape. The tapes all booted successfully,
but the utility couldn't find anything on them. What had happened
was this: the operator would select the week-old tape to be re-used
for the latest backup and bootstrap the dump program from it, and
immediately dump onto that tape. The dump program, assuming a fresh
tape had just been mounted, would first write itself to the tape AT
THE CURRENT POSITION, then write directory information and files.
When we went to read the tape, the dump program started by rewinding
the tape, then reading past its boot image. It then expected the
directory - but it found another image, got confused, and gave up.
One of my co-workers sat at the console for what I remember as
hours, single-stepping the dump program until he found out where it
rewound the tape, so he could patch out the offending code. I think
he also wrote out the dump procedure for that operator....
--
Bill Roman {ihnp4,decvax,allegra,...}!uw-beaver!tikal!sigma!roman
Summation, Inc.
18702 142nd Ave NE
Woodinville, WA 98072
(206) 486-0991mjl@ritcv.UUCP (Mike Lutz) (02/14/86)
A few years back, a local company installed an 11/70 with several RM03's.
As this system replaced an 1130, it was quite an event internally, and
a lot of company bigwigs came around for a tour. One VIP had a cup of
Coke; when he was in the machine room, he put it on top of the RM03's,
and then knocked it over with his elbow. The service personnel were
quite impressed by how efficiently the RM03 was as a centrifuge: there
was a nice, thin coating of syrup over all the inside of the drive
(and the pack itself, of course).
--
Mike Lutz Rochester Institute of Technology, Rochester NY
UUCP: {allegra,seismo}!rochester!ritcv!mjl
CSNET: mjl%rit@csnet-relay.ARPArb@ccivax.UUCP (rex ballard) (02/15/86)
In article <672@amiga.amiga.UUCP> jimm@homer.UUCP (Jim Mackraz) writes: >:: >the venerable rsmith told a story about a consultant who once worked at a >site which had somehow made 'cd' stand for 'clear disk'. Punchline is >obvious. In the 'practical jokes department', one wiley programmer set thing up so that the victims 'ls' would mail a love note to the victims boss! (as well as the normal ls) Very interesting when both boss and victim were men. In the 'follow the bouncing VAX department' when a programmer executed a shell script named test from the root directory that read like this: mkdir ./fdir cp ./* fdir . . if test -f file . . And roots .profile contained: date >> /(some path)/.log tty >>& /(some path)/.log (both the cwd of 'test' and the log file were on the same device) system would lock up for lack of i-nodes, lack of space, or lack of processes (whichever came first) and root couldn't log in to fix it. corrective measures have been taken. And of course, there's always the time when two programmers were running 'vi' on the same 20000 line source file and hit the ^Z^Z at the same time.... (thank goodness for rcs/sccs, when will unix provide automatic file locking) Waiting for System 9 - Rex Ballard
greenber@phri.UUCP (Ross Greenberg) (02/17/86)
One of the Major Banks here in NYC had a central machine at the heart
of their EFT (Electronic Funds Transfer) Network. Seems one of the drives
(they had two machines, each doing a hot-backup of the other) went down.
Then one of the night operators got into a fight with the other ("Your
momma!", "Sez..you", "Oh yeah?", etc), and it turned into a shoving
match. One shove ended up against the RP06.
Average latency of a transaction on the system was < 1 minute. They
spent three days recovering the 18 million dollars in transactions
tha were on the disk. And the Cost of Funds at the time were *VERY* high!
--
------
ross m. greenberg
ihnp4!allegra!phri!sysdes!greenber
[phri rarely makes a guest-account user a spokesperson. Especially not me.]sutter@osu-eddie.UUCP (Bob Sutterfield) (02/17/86)
A professor of mine told the story of how to bring down a line printer: Your average line printer has 132 hammers arranged across the width of the paper, with letters, numbers, etc arranged on a band that passes between the hammers and the ribbon, which then strikes the paper. The characters on the band are arranged carefully, based upon frequency-of-use statistics. As the appropriate character arrives at column "c" the hammer is actuated and the impression is made. During the printing of an average line, at any particular moment, only some small "n" (maybe 5) of the hammers are actuated at once. Then the band moves one more character position to the left and another sparse group of hammers are actuated. So on until the line is printed, then a linefeed happens. So, if you knew the pattern of the print band, and sent a line with that pattern all in the right places to be struck at once... then the next line you sent had the same characters in the same order, just shifted one to the left... All 132 hammers operating at once, repeatedly, at x00 lines per minute... The most durable printer they found could stand this abuse for about 1.25 pages. They all ended up shredding the ribbon almost immediately, then finally smoking from the power supply about the same time as the platen was chewed up. Some fun, huh? for the third-shift operator! -- ----- Human: Bob Sutterfield Mail: sutter@osu-eddie.UUCP sutterfield-r%osu-20@osu-eddie.UUCP or: sutter@ohio-state.ARPA sutterfield-r%osu-20@ohio-state.ARPA
cjsgro@watdragon.UUCP (Carlo Sgro) (02/17/86)
From <<Computer Security>> by John M. Carroll:
March 1971: A computer employee in New York, given two weeks notice of layoff,
removed all the labels from 1,500 reels of tape. It cost the
company thousands of dollars in labour to re-identify the data.
December 1971: The Arizona State Finance Centre found that it was unable to
reconstruct a magnetic tape file from punch card backup. Two
thousand cards had been used as Christmas tree ornaments or
paper airplanes.
July 1972: A computer operator in Denver was arrested for repeatedly short-
circuiting with a screwdriver a computer disk drive on the machine
he operated. He claimed he had an overwhelming urge to shut down
computer. His employer spent $500,000 over a two-year period
trying to find the recurring trouble. He was finally caught by
closed circuit TV surveillance.
--
Carlo Sgro
...![ihnp4||decvax||allegra||clyde||utzoo]!watmath!watdragon!cjsgro
"ihnp4 Express: Overnight to the USA or you don't pay!"dta@nvzg2.UUCP (Doug Anderson) (02/17/86)
> > Ed Yourdon used to (maybe he still does?) tell the story of a night shift > operator on a PDP-11 with a bunch of RK05 drives, who had a head crash > and tried to recover by swapping cartridges. Before he stopped for > help, he'd knocked out five drives and eleven cartridges! > > --Rob Spray > ...ctvax!rob I don't know about Yourdon but when I worked for a company in San Antonio, Texas, one of our night shift clerks wiped out 4 RP06 drives and 6 removable packs by doing this on a PDP 11/70. Needless to say the person was chastised. (we were down for 12 hours till DEC got our drives back up. Thankfully we still had a set of backup packs that hadn't been sacrificed to the great Head Crash :~) ). Doug Anderson Every thing I say is false.
rcj@burl.UUCP (Curtis Jackson) (02/18/86)
There is a great way to bring any Unix system (that I know of, anyway) to its knees for quite some time (last time I did it it was almost 10 minutes) with a simple 4-5 line C program. This works regardless of system load; the machine goes completely catatonic (except for separate processors that don't need the main machine for a while, like tty driver boards). If you kick off a shell that infinitely forks these babies, the only way to kill the system in less than about 3 days is to drop it on the floor. The bad thing is that anyone can do it, no special privleges are necessary. I won't post the source for obvious reasons, but it is a wonderous way to get everyone competing for your resources to leave... I have never done it in a working environment, but Man have I been tempted!! Sorry that this isn't a rumor (but only I know for sure, right?), -- The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj ...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj
woolsey@umn-cs.UUCP (Jeff Woolsey) (02/19/86)
Reminds me of a program I wrote years ago to have the opposite effect.
I called it "SLOW". It turned each line of a file
FROM THIS
+T
+ O
+
+ T
+ H
+ I
+ S
It made our 1200 LPM printers run at about 60 cps.
I also remember sending a print file that contained about 1000 logical
end-of-records (and nothing else) to a remote line printer. It took about 5
minutes for it to transmit and print nothing.
--
--
Honk honk! Why, it's Wobbles, the goose!
Jeff Woolsey
...ihnp4{!stolaf}!umn-cs!woolsey
woolsey@umn-cs.csnetlarry@kitty.UUCP (Larry Lippman) (02/20/86)
> There is a great way to bring any Unix system (that I know of, anyway) to > its knees for quite some time (last time I did it it was almost 10 minutes) > with a simple 4-5 line C program. This works regardless of system load; > the machine goes completely catatonic (except for separate processors > that don't need the main machine for a while, like tty driver boards). > > If you kick off a shell that infinitely forks these babies, the only way > to kill the system in less than about 3 days is to drop it on the floor. It works. It happened to me once when one of my first application programs screwed up, resulting in the failure of forked processes to be killed. The application program was running okay, but the system kept getting slower and slowerrrr (the only thing wrong was the failure to kill completed processes). Finally I did a ps, and was horrified to discover the nature of the problem. The processes were forking faster than I could kill 'em, the process table overflowed, and I couldn't even do a ps anymore. Since the parent process was owned by root and spawned by crontab, logging out would not solve the problem. Going to single user mode would not work because the process table had overflowed. Powerdown time... ==> Larry Lippman @ Recognition Research Corp., Clarence, New York <== ==> UUCP {decvax|dual|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry <== ==> VOICE 716/741-9185 {rice|shell}!baylor!/ <== ==> FAX 716/741-9635 {G1, G2, G3 modes} duke!ethos!/ <== ==> seismo!/ <== ==> "Have you hugged your cat today?" ihnp4!/ <==
gnu@hoptoad.uucp (John Gilmore) (02/21/86)
In article <1036@burl.UUCP>, rcj@burl.UUCP (Curtis Jackson) writes: > There is a great way to bring any Unix system (that I know of, anyway) to > its knees for quite some time (last time I did it it was almost 10 minutes) > with a simple 4-5 line C program. This works regardless of system load; > the machine goes completely catatonic... A similar program already exists on *your* system, as you read this! It's called "rnews", and the way it works is probably very similar to that 5 line C program. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa
cem@intelca.UUCP (Chuck McManis) (02/21/86)
> A professor of mine told the story of how to bring down a line printer: > > ... description of how lineprinters work ... > > So, if you knew the pattern of the print band, and sent a line with that > pattern all in the right places to be struck at once... then the next line > you sent had the same characters in the same order, just shifted one to the > left... All 132 hammers operating at once, repeatedly, at x00 lines per > minute... > > The most durable printer they found could stand this abuse for about 1.25 > pages. They all ended up shredding the ribbon almost immediately, then > finally smoking from the power supply about the same time as the platen was > chewed up. Some fun, huh? for the third-shift operator! > Human: Bob Sutterfield This was actually a test performed by the FE's for the IBM 1703 (or 1702?) except that one could download character/chain assignments. Simply define all of the characters on the chain to be the same one and then print it several times. Really shook to floor, and could also bring out marginalities (sp?) in the disk drives. --Chuck -- - - - D I S C L A I M E R - - - {ihnp4,fortune}!dual\ All opinions expressed herein are my {qantel,idi}-> !intelca!cem own and not those of my employer, my {ucbvax,hao}!hplabs/ friends, or my avocado plant. :-}
jans@tekecs.UUCP (Jan Steinman) (02/21/86)
When I worked for a transaction-processing computer company as a Customer Engineer, there was another CE there who was a real screw-up. He was on probation at the time he had to do a head alignment on a 300Mb "washing machine" type drive. Somehow, the drive (and alignment pack) sufferred a head crash during the operation. Later, he indiscreetly told me that he had finished aligning the drive, and had started a format, when he discovered he had forgotten to swap the CE pack with the customer's pack. Knowing he was on probation, he said, "I thought quick, and crashed head zero on the pack!", easily accomplished by poking at head mount with a screwdriver. Little pieces of head zero crashed 12 of the 19 other heads, and destroyed the CE pack. CE pack: $5000 13 heads @ $150 each: $1950 9 hours labor: $900 ----- $7850 vs Cost of re-certifying CE pack: $350. Not really a horror story, but there's a moral there somewhere. :::::: Artificial Intelligence Machines --- Smalltalk Project :::::: :::::: Jan Steinman Box 1000, MS 60-405 (w)503/685-2956 :::::: :::::: tektronix!tekecs!jans Wilsonville, OR 97070 (h)503/657-7703 ::::::
ron@brl-smoke.ARPA (Ron Natalie <ron>) (02/21/86)
> If you kick off a shell that infinitely forks these babies, the only way > to kill the system in less than about 3 days is to drop it on the floor. > The bad thing is that anyone can do it, no special privleges are > necessary. I won't post the source for obvious reasons, but it is a > wonderous way to get everyone competing for your resources to leave... > I have never done it in a working environment, but Man have I been tempted!! > Most UNIX systems these days give a user process limit that is significantly less than infinity or NPROC. -Ron
faigin@sdcrdcf.UUCP (Daniel P Faigin) (02/22/86)
My wife has these stories to tell:
1. We were in the process of installing 3 new Cybers in our
machine room, and had to install umpteen tons of air conditioning
to handle the additional load. One fine Friday, the building
engineer decided to check unit capacity, and cranked all the air
to "FULL ON", locked the controls, and left for a weekend in San
Diego (without his beeper, carrying the only key). About 30
minutes later, our senior operator came flying out of the machine
room, in his parka, screaming "It's 50 degrees and DROPPING FAST
in the machine room!" Al and Al (our matched set of system P/As)
went flying into the machine room and started excercising *every*
drive, trying to generate heat (CDC drives used to crap out at 48
degrees F). No good -- the room temperature kept dropping. They
had to send out a 2 minute message, checkpoint, and bring down
the network (200+ on-line, 19 RJE stations). You should have
heard the uses howl!! (I wonder what ever happened to that poor
slob of a facility engineer).
2. Satellite site, running CDC 3170 with 16 30-Mbyte drives.
Some operator on the graveyard shift dropped a pack. Scared,
he/she/it didn't red-tag the thing. Sometime later, (inevitably)
someone mounted the bad pack. 1 pack, 1 drive down. Not knowing
whether it was the pack or the drive, an operator swapped the
pack with another one, on another drive. By the time it was
over, 30 packs and 14 drives have been trashed (Only the "non-
removable" system drives/packs were safe). CDC warranty only
covered repairs to 1 drive and 1 pack. The whole shift was
canned... It took $$$ and approx. a week to restore/repair
everything.
Daniel Faigin
--
UUCP: {akgua allegra ihnp4 hplabs sdcsvax trwrb cbosgd}!sdcrdcf!faigin
ARPA: sdcrdcf!faigin@UCLA-LOCUS.ARPA --or-- sdcrdcf!faigin@LOCUS.UCLA.EDU
W: SDC, 2525 Colorado MD 91-01; Santa Monica CA 90406; (213) 820-4111 x6393
H: 11743 Darlington Avenue #9; Los Angeles CA 90049; (213) 826-3357ark@alice.UucP (Andrew Koenig) (02/23/86)
The first IBM 2314 disk drive (which comes in units of 8, stacked two high, and looks a little like a pizza oven) reputedly started suffering multiple head crashes a few weeks after being delivered to the first customer. After replaing heds and packs, things worked fine until head crashes started occuring after a few more weeks. Finally, they gave up and took the drive to Poughkeepsie, where they replaced heads and packs again and ran it for several months with no failures. Yet once it went back to the customer, it started crashing after a few weeks. To make a long story short, they started looking for any differences between the customer site and their test lab. They finally found it: the packs sent to customers had quality control stickers on them. After a few weeks, some of the glue would work its way loose and find its way into the heads...
kludge@gitpyr.UUCP (Scott Dorsey) (02/23/86)
In article <1335@osu-eddie.UUCP> sutter@osu-eddie.UUCP (Bob Sutterfield) writes: >A professor of mine told the story of how to bring down a line printer: > >Your average line printer has 132 hammers arranged across the width of the >paper, with letters, numbers, etc arranged on a band that passes between the >hammers and the ribbon, which then strikes the paper. The characters on the >band are arranged carefully, based upon frequency-of-use statistics. As the >appropriate character arrives at column "c" the hammer is actuated and the >impression is made. During the printing of an average line, at any >particular moment, only some small "n" (maybe 5) of the hammers are actuated >at once. Then the band moves one more character position to the left and >another sparse group of hammers are actuated. So on until the line is >printed, then a linefeed happens. >chewed up. Some fun, huh? for the third-shift operator! This is true... There used to be software to allow you to play music on older IBM line printers. It turned out that if all the correct letters were printed on a line (which was used in the 1812 overture software that I coded), the printer would blow a fuse. This isn't good, but it's better than burning out the printer. ------- Disclaimer: Everything I say is probably a trademark of someone. But don't worry, I probably don't know what I'm talking about. Scott Dorsey ICS Programming Lab, Georgia Insitute of Technology, Atlanta Georgia, 30332 ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!kludge
rcj@burl.UUCP (Curtis Jackson) (02/24/86)
In article <1215@brl-smoke.ARPA> ron@brl-smoke.ARPA (Ron Natalie <ron>) writes: >> If you kick off a shell that infinitely forks these babies, the only way >> to kill the system in less than about 3 days is to drop it on the floor. >> The bad thing is that anyone can do it, no special privleges are >> necessary. I won't post the source for obvious reasons, but it is a >> wonderous way to get everyone competing for your resources to leave... >> I have never done it in a working environment, but Man have I been tempted!! >> >Most UNIX systems these days give a user process limit that is significantly >less than infinity or NPROC. Several people seem to think that I meant forking processes infinitely. We have a 25-process-per-user limit here; that isn't what I meant. One trivial process will make our Vax 11/780 *totally* catatonic for almost 10 minutes, and I do mean *totally*. Not slow, I mean apparently dead. What the above refers to is: "Now consider what would happen if someone started off a shell to infinitely fork these things [up to max processes per user, of course]". -- The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj ...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj
network@ucbjade.BERKELEY.EDU (Berkeley Network) (02/24/86)
In article <5027@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes: >To make a long story short, they started looking for any differences >between the customer site and their test lab. They finally found it: >the packs sent to customers had quality control stickers on them. >After a few weeks, some of the glue would work its way loose and find >its way into the heads... Gee, that sounds like the RA81's that DEC is shipping these days. The Hard Disk Assembly (HDA) (Head+Disk Assembly?) is an air-sealed unit, to keep the dust out of the heads (good idea, that!). The final stage of assembly is to glue the two halves of the box together, with disk/heads/etc inside, then evacuate the HDA. Unfortunately, the glue they used has a tendency to crumble inside the HDA. The things can be expected to crash inside the first year of service. Us? We've got 30 or so of the critters :-(. While I'm here, I might as well relate the tale of a VMS site that had secrataries doing backups. Early one morning, they did the backups, and managed to leave the system drive write protected. Since swap and the system logs were all on that, it didn't run very well - seems that processes would hang waiting for something to swap out so they could be loaded. After about 4 hours, performance got bad enough they went into the machine room to see what was going wrong. Besides the write-protected drive, they found 1/2 box of paper under the console, covered with messages of the form: ERROR: Can't write to SYS$ERRLOG. An attempt was made to put said error on SYS$ERRLOG, of course :-). Similar bugs used to crash IBM systems! <mike
moroney@jon.DEC (Mike Moroney) (02/24/86)
>I also remember sending a print file that contained about 1000 logical >end-of-records (and nothing else) to a remote line printer. It took about 5 >minutes for it to transmit and print nothing. That reminds me, I did the exact same thing to remote printers when I was in college, with the same results. The funny thing was, if you sent enough end- of-records, the remote minicomputer controlling the printer (and card reader) would report that the main computer was down! It was fun to tease the operators, start a large listing, then the printer would mysteriously stop, the terminal would report main computer down, then it would pick up exactly where it left off, as if nothing happened (nothing did!). I found out when they increased the baud rate of the lines to the remote sites the time it took to print nothing was baud rate dependant. (!) -Mike Moroney ..decwrl!rhea!jon!moroney
dv@well.UUCP (David W. Vezie) (02/24/86)
On the subject of "practical jokes" I remember a stunt we pulled on
the system manager at the wonderful time between the last 4.1 dump,
and booting 4.2 for the first time. A friend of mine wrote a program
called "slaugher" that would read through the /dev disk device,
find a given inode, and change it from a directory to a file
(or vice versa). We then created a directory in the manager's
home directory called "Twilight_Zone", made some files in it, changed
it to a file, and edited it so that it would act like this:
% cd
% ls
<lots of files> Twilight_Zone
% cd Twilight_Zone (a *BIG* mistake!)
% ls
/etc/passwd /bin/login /bin/su /etc/group
(there were more files than this, but I don't remember all of them)
% dirs
~/Twilight_Zone
% pwd
/
% cd ..
% dirs
~
% pwd
/
% ls
/etc/passwd /bin/login /bin/su /etc/group
(all the files that he saw previously)
We created the files by just editing the directory. We managed the
"Twilight Zone" effect by giving ".." the same inum as "."
Fortunatelly, he was smart enough to not do anything like "rm *"!!!
---
David W. Vezie
{dual|hplabs}!well!dv - Whole Earth 'Lectronics Link, Sausalito, CA
(4 lines, 113 chars)rgale@man.UUCP (Ryan Gale) (02/25/86)
When Security Pacific [I don't work there; just use the machine] was about to
take delivery of their new 3B5, there was rejoicing all around. Delivery was
two months late, and the old machine had about 75% more terminals on it than
it was rated for. Corporate officers flew down for the grand unveiling.
The vanlines truck arrived, and everyone went out to see it being offloaded.
Whereupon the forklift driver miscalculated, and punched cleanly through the
crate containing the CPU. His comments: "Gee, I'm terribly sorry."
--
Ryan Gale
{ihnp4, akgua, decvax} !sdcsvax!man!rgalesimon@simon_pc.UUCP (Simon Shapiro) (02/25/86)
Not really a horror but...
Try this on VMS (yaaachk) version 4.1:
1. Mount RA60 pack
2. Open a file on the pack (keep opened)
3. Dismount the pack from another terminal
4. Try to mount another pack: VMS will tell you "Cannot mount...
... drive already mounted..."
5. So you try to dismount, right? Wrong! VMS says "no drive mounted..."
6. Call DEC service
Depends on your attitude towards life as to how you classify the result of
step 6. Horror story or great joke.simon@simon_pc.UUCP (Simon Shapiro) (02/25/86)
Blowing a fuse reminds me a story about the old Hawk anti-aircraft guided missile: An Israely Air-Force engineer found that if a certain resistor in a missile's "computerized" guidence system was shorted and the operator of the main control pressed the "indicator light test" button, the entire battery (three rockets?) will be fired, aimed at [your guess is as good as anyone else's]. They tried it, it worked!
scco@ur-tut.UUCP (Sean Colbath) (02/25/86)
In article <1462@gitpyr.UUCP> kludge@gitpyr.UUCP (Scott Dorsey) writes: >> Some fun, huh? for the third-shift operator! > > This is true... There used to be software to allow you to >play music on older IBM line printers. It turned out that if >all the correct letters were printed on a line (which was used in the >1812 overture software that I coded), the printer >would blow a fuse. This isn't good, but it's better than >burning out the printer. > >Scott Dorsey >ICS Programming Lab, Georgia Insitute of Technology, Atlanta Georgia, 30332 >...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!kludge An even more amusing (although probably wildly apocryphal) anecdote was related by Ted Nelson in his book Computer Lib/Dream Machines. It seems that way back in the days when the operator's console was a large panel with flashing lights representing the registers and low memory, a sneaky little program was circulated which would mung the registers and low core to make *large flashing words* appear in the lights, ala a Broadway/Times Square billboard. Apparently several night shift operators had nearly had heart attacks when they were nearly dozing off and suddenly secret messages would come scrolling across the control panel... Sean Colbath UUCP: ...allegra!rochester!ur-tut!scco BITNET: SCCO@UORVM
henry@utzoo.UUCP (Henry Spencer) (02/25/86)
Semi-related: a number of years ago, the IBM installation I was at had
some model or other of IBM line printer which had one interesting property:
the fast-formfeed mode of the printer was *very* fast. It could go through
a box of paper very quickly indeed. Putting the printer offline either
didn't help or didn't help quickly enough; I forget. The only fix was to
put your foot in the paper box, which caused the paper to tear.
The operators on this system were renowned for their low intelligence and
general surliness. So one diabolical programmer wrote a peculiar little
program which got run occasionally late at night, when the I/O clerk had
gone home and the operator was handling everything. The program produced
a console message saying "quick, put your foot in the box!", waited a few
seconds, and then put the line printer into fast-formfeed mode. The delay
was calculated so that if the operator, on seeing the message, leaped up
and dashed over to the printer AT ONCE, he could catch it before there was
paper all over the floor...
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryknight@SU-Russell.ARPA (Bob Knight) (02/26/86)
And then there's the old 24xx tape drives from IBM. Turns out if you turned
the maintenance clock off on them, they wouldn't work. More than one site I
worked at had this happen. One was 75 miles from the nearest IBM office.
The CE came down and worked the problem for about 4 hours before thinking
about the clock.
The same site once had an operator who would dismount an application's
disk pack WHILE THE APPLICATION WAS RUNNING and mount a to-be-run application's
pack in its place. Needless to say, the operating system in question didn't
check the VOLID on the new pack when it spun up. However, after the first
two times the operator did this, he was fired and the operating system
modified.
Under TENEX, Dan Lynch put in a hack to the scheduler so that a wheel could
suck up all of the CPU cycles if he/she so wished. Made monitor assemblies
go MUCH faster, since MACRO basically looped in one core page and (almost
never) page-faulted. Some operators were running a system dump one night,
and we fired up such an assembly. The tape drive stopped dead in its tracks
-- normally it really blasted along. The operator saw the lack of activity,
the wheels turned ("Oh, the tape's stopped moving, DUMPER must be done),
and then he went over to the drive and unloaded the tape. Looked really
puzzled when he saw two systems programmers rolling on the floor about ten
feet away.
Bobmeissner@dg_rtp.UUCP (02/26/86)
In article <376@nvzg2.UUCP> dta@nvzg2.UUCP (Doug Anderson) writes: > > I don't know about Yourdon but when I worked for a > company in San Antonio, Texas, one of our night > shift clerks wiped out 4 RP06 drives and 6 removable > packs by doing this on a PDP 11/70. Needless to say > the person was chastised. (we were down for 12 hours > till DEC got our drives back up. Thankfully we > still had a set of backup packs that hadn't been > sacrificed to the great Head Crash :~) ). > In 1 hour, 4 277MB removable drives were trashed here at DG (Westborough). We had a head crash on one, and FS swapped both packs to see what was wrong. While they were taking the first two drives apart, the roached disk was taken to another system to run the AOS/VS equivalent of fsck. Needless to say, when the third drive crashed, field service again swapped packs. I also found out the hard way, that the paper tape labels should not be attached to removable disks. After 1/2 hour, the label flies into the middle of the head assembly.
brahms@spp5.UUCP (Bradley S. Brahms) (02/26/86)
In article <1215@brl-smoke.ARPA> ron@brl-smoke.ARPA (Ron Natalie <ron>) writes: >> If you kick off a shell that infinitely forks these babies, the only way >> to kill the system in less than about 3 days is to drop it on the floor. >> The bad thing is that anyone can do it, no special privleges are >> necessary. I won't post the source for obvious reasons, but it is a >> wonderous way to get everyone competing for your resources to leave... >> I have never done it in a working environment, but Man have I been tempted!! >> >Most UNIX systems these days give a user process limit that is significantly >less than infinity or NPROC. > >-Ron There is another way to deal with something like this that works. Presumably, the process that is doing the forking is running at know higher a priority than anything else. What then can be done is do the following: Renice a su sh to a very high priority. Run a compute bound job at a lower priority than the su sh but higher then the problem process. At this point, the process will not get any run time. You can then do a ps and kill the processes off. Kill the compute bound process and your done. -- Brad Brahms usenet: {decvax,ucbvax,ihnp4}!trwrb!trwspp!brahms arpa: Brahms@usc-eclc The opinions expressed above are my own, and may not reflect those of my employer.
aaronf@copper.UUCP (Aaron Friend) (02/26/86)
Back in the early 60's a field engineer was providing emergency assistance to a site in NYC and had been on site for several weeks. His home base was in Minn. As is normal in this type of work he had been somewhat lax about calling home and checking in with the little woman. One day his wife tracked him down at the customer site via telephone. He was very busy at the time hot on the trail of an intermittent bug and was somewhat abrupt when he answered the phone. She told him "I know that your very busy and I hate to bother you but I have made a decision and I thought that I should share it with you. I've decided that I should have a baby, and I'm going to start on it tonight." at which point she hung up. Needless to say he didn't stay in NYC much longer. Aaron Friend
carlton@masscomp.UUCP (Carlton Hommel) (02/26/86)
Here is a story that had a sad ending for someone other than a hapless operator or programmer. My friend was working on the problem hotline for a service hotline. An night-shift operator called him with the following story. Fred the operator started a several-hour batch job, and went out to see a movie. He got some popcorn. Hot, buttered, popcorn. During intermission, he went back to the machine room to change disk packs. Oops! The popcorn got knocked over. What a mess. Unpopped kernels (corn, that is - not unix) all over the place. Hot butter all over the heads. Well, the thing to do is to scoop out as many of the kernels as possible, and wipe off the heads with a paper towel. Plop in the new disk pack, and no one will know. Cycle the drive up, and... Oh Oh. Terrible grinding noises. Push the off switch! Oops, the grinding got worse. Power it up again? No, now the whole unit is washboarding towards the CPU. I know! I'll pull the plug! *Crackle Sizzle* After my friend John stopped laughing, he told Fred, "I'm sorry, stupidity isn't covered by your service contract," and hung up. John's boss failed to see the humor, and fired him the next day. Carl Hommel
matt@oddjob.UUCP (Matt Crawford) (02/28/86)
Here's one hot off the press: it happened not to "somebody, somewhere", but right down the hall from my office last Tuesday, in the room containing an ELXSI 6400 and a Harris 1200. An electrician was drilling some holes in the floor to attach a new conduit and the drill struck a neolithic hot water pipe. The geyser shot all the way to the ceiling. The floor was a few inches deep and steam was rising from under the movable tiles. Strangely enough, the electrician was standing ankle deep in water right next to a 220V, 100A power socket, but is still living. Wonders never cease. _____________________________________________________ Matt University crawford@anl-mcs.arpa Crawford of Chicago ihnp4!oddjob!matt
ins_ampm@jhunix.UUCP (Michael P McKenna) (02/28/86)
In article <6434@utzoo.UUCP> henry@utzoo.UUCP writes: >The operators on this system were renowned for their low intelligence and >general surliness. So one diabolical programmer wrote a peculiar little >program which got run occasionally late at night, when the I/O clerk had >gone home and the operator was handling everything. The program produced >a console message saying "quick, put your foot in the box!", waited a few >seconds, and then put the line printer into fast-formfeed mode. The delay >was calculated so that if the operator, on seeing the message, leaped up >and dashed over to the printer AT ONCE, he could catch it before there was >paper all over the floor... A reverse situation (I've never actually SEEN this done, but it can be), some laser printers can be put into 'manual' mode by a print request, that is the printer sits there waiting for someone to feed it paper one sheet at a time. Any user could do this, in which case the printer would stop, the operators would wonder what was going on, and the print queue would just get longer and longer... Dwight S. Wilson
gwe@cbdkc1.UUCP ( George Erhart x4021 CB 3D288 RNB ) (02/28/86)
{}{}{}{}{}{}{}{}{}{}
To continue the stream of computer pranks, my roommate my senior year
at Ohio University had a favorite prank. The OU comp. center had a
really nice 1000+ lines per minute printer with the automatic power
openning door. The operators for the machine in the comp. center were
always putting things on top of the printer ... like printouts, pizzas
and an occasional coke. My friend would first check to see if there was
anything on the printer, then run a special program that would send
a print job in someone elses name that printed 5000 lines, one on top
of the other. It would cut the paper in the printer in half at the print
band. This caused the top to automatically raise ... dumping printouts,
pizzas and cokes to the floor if the operator was not watching. Needless
to say, they learned fast ... but it was fun while it lasted.
--
George Erhart at AT&T Bell Laboratories Columbus, Ohio
614-860-4021 {ihnp4,cbosgd}!cbdkc1!gwegwe@cbdkc1.UUCP ( George Erhart x4021 CB 3D288 RNB ) (02/28/86)
[][][][][][][][][][]
I heard a great story while at Ohio University. We had a 370/158 sitting
in the basement of the comp. center. It seems that the city of Athens,
home of OU, was checking the sewer system by setting off smoke bombs
to check for leaks and cracked pipes. Well, it happened that there was
a leak under the 370/158 ... when the smoke started rolling out, a near
by administrator grabbed a fire extinguisher and sprayed the interior.
It took 3 days to get everything cleared/cleaned up.
--
George Erhart at AT&T Bell Laboratories Columbus, Ohio
614-860-4021 {ihnp4,cbosgd}!cbdkc1!gwebzs@bu-cs.UUCP (Barry Shein) (02/28/86)
Re: running jobs that bring the system to its knees. There is another way to deal with getting rid of such jobs. Let's assume the user's login name is 'john', then the following is effective: rm -r ~john ed /etc/passwd /^john:/d w q Try it, you'd be amazed how well it works, especially right after a re-boot (:-). -Barry Shein, Boston University
esf00@amdahl.UUCP (Elliott S. Frank) (03/01/86)
[........................urp!]
As I remember, the index registers on the 7094 [optional feature!]
had a display box that sat on top of the console (a large panel of
flashing lights) and displayed the value of the index registers. Since
the index registers were not required, you could load values into them
to display a message. IBSYS (the "advanced" batch job operating system
for the 7094) did not use the index registers for any useful purpose
[it had to be downwards compatible with those machines that didn't have
index registers], so it loaded the proper bits to display "$IBSYS"
whenever the operating system functions had control of the cpu.
Elliott S Frank ...!{ihnp4,hplabs,amd,nsc}!amdahl!esf00 (408) 746-6384
[the above opinions are strictly mine, if anyone's]kvc@scgvaxd.UUCP (Kevin Carosso) (03/01/86)
In article <143@simon_pc.UUCP> simon@simon_pc.UUCP (Simon Shapiro) writes: >Not really a horror but... > >Try this on VMS (yaaachk) version 4.1: > >1. Mount RA60 pack >2. Open a file on the pack (keep opened) >3. Dismount the pack from another terminal >4. Try to mount another pack: VMS will tell you "Cannot mount... > ... drive already mounted..." >5. So you try to dismount, right? Wrong! VMS says "no drive mounted..." >6. Call DEC service > >Depends on your attitude towards life as to how you classify the result of >step 6. Horror story or great joke. Oh, come now... At least know something about what you're relating before blithely repeating it. VMS marks the disk for dismount but doesn't dismount it 'cause it's got a file open on it. Close the last file and it'll dismount oh-so-gracefully. SHOW DEVICE will tell you it's MARKED for dismount, but not dismounted yet. SHOW DEVICE/FILES will even tell you what files are open so's you can close 'em. I suppose you'd rather have it mung the filesystem 'cause fsck is so exciting to run? Of course, like everything else, VMS has got it's REAL horror stories! Maybe I'll relate a few of those for y'all sometime... /Kevin Carosso scgvaxd!engvax!kvc
blm@chinet.UUCP (Brad L. McKinley) (03/01/86)
I've been reading these from the start and some of them are kinda' entertaining (in a morbid sort of way). I wish I would have thought to save these as I read them but I didn't. If some has been saving these, would they please mail then too me? It's always nice to hear about someone else's misery when you've got a 'panic: no space on dev ...' message on your console.
tedrick@ernie.berkeley.edu.BERKELEY.EDU (Tom Tedrick) (03/02/86)
In article <14700001@hplabsb.UUCP> follmer@hplabsb.UUCP (Stephen Follmer) writes: > >I was wondering if anyone out there has some horror stories about the >computer industry; crashed systems or lost backups. For example, I heard >a story once about a guy who lost a month's worth of code due to some >backup problem. This was about 6 in the morning, and apparantly, the >guy caught the next plane to Nepal and joined a monastery. This is the >best it could be pieced together since he hasn't been heard from since. >He just drove to SFO international, put the ticket on his Master Card, >and disappeared. Case closed. The guy was pretty upset, but on his way >out the door, according to the guard, had a wild grin of calm and happiness, >as though he'd won the last round with the machine through some Deux >ex machina. > >Have you heard any similar stories? I threw out 2 years worth of my work that had taken hundreds of hours of cpu time due to hassles from rude administrators. When they spotted how much time I had been using, they would send me these threatening and hostile messages. I would explain what I was doing, they would apologize and leave me alone. Then after awhile some new guy would go through the same routine. We have all these subsidized research machines that are supposed to be used for research, but when you actually do something (I got much better results for some problems in cs theory than anything that had been published) you become the target for all the negativity of the administrators who suspect someone is taking advantage. I got completely fed up with having to deal with personal abuse and do all my research in my head now. I think I am a damn good researcher, and that bureaucrats have been a serious problem in slowing down the use of computers in cs theory research.
henry@utzoo.UUCP (Henry Spencer) (03/02/86)
I was once told that the operating system for the Burroughs B1700, another
computer well-supplied with lights, displayed a smile in its idle loop.
Its equivalent of the "panic" routine, called to announce a crash, put a
frown into the lights as its last action.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrypatc@tekcrl.UUCP (Pat Caudill) (03/02/86)
The one I like is about the bank in NYC that bought one of the first Burroughs (tube) computers. It was to be installed on the tenth floor and they had to knock a big hole in the wall to get the four ton monster through. Unfortunatly the delivery company knocked it off the pallet while manuvering it through the hole and it landed in the street. Jingle Dingles every where, I think they canceled the warrenty. Also the RCA plant in Ft. Lauderdale had a contractor (working on the weekend) switch the ground return/ and earth neutral lines with two hot lines from the 3 phase power. after they left the computer power supply shorted and the arcking melted it through the raised floor. a small disaster. However the teflon insulation reacted with the hot (molten) metal to form HF gas. When the fire department turend on the sprinklers in desperation hydrofloric acid. The real problem wasnt realised for several days untill stuff started falling apart. They had to completely disassemble every computer being built or tested (about 40 big systems) and wash them and re build. I understand they got a wanderwand car wash system in the parking lot and ran the mainframes thorough that. Then tested everything with litmus paper. Tektronix!tekcrl!patc
guy@sun.uucp (Guy Harris) (03/03/86)
> ...VMS marks the disk for dismount but doesn't dismount it 'cause it's got > a file open on it. Close the last file and it'll dismount oh-so-gracefully. > ...I suppose you'd rather have it mung the filesystem 'cause fsck is so > exciting to run? Ahem. If this was intended as a slam against UNIX, it's misdirected. UNIX will refuse to dismount a file system which has open files on it. (Locally opened, anyway; since Sun's NFS is stateless, a machine doesn't know whether anybody on another machine has files opened on a given file system, and will let you dismount that file system. Then again, since Sun's NFS is stateless, the only effect of that is to cause all subsequent I/O to that file system to get "Stale file handle" errors; the file system isn't corrupted, although if the program's response to such an error isn't to ask that the file system be remounted and keep trying the operation - if the file system is remounted, one of the retries will succeed and the program can take up where it left off - the file it's working on could become corrupted.) Now that we've corrected all errors in these postings, shall we return to posting true horror stories? (Which may not, strictly speaking, be rumors, but are quite entertaining nonetheless; as Ralph Waldo Emerson said, "A foolish consistency is the hobgoblin of small minds.") -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)
barto@celerity.UUCP (David Barto) (03/03/86)
(As told to me by a fellow named "Marv Rubenstein", Back in the days when Cards and tape were the only way....) "I was asked by a fellow, how to read a bunch of cards, which he did not know the format of, but could determine from the data on the card. I told him to read the card to tape unformatted, backup the tape, and then read the data back from the tape to be able to use format specified. He did this, using rewind to backup the tape drive. Needless to say, the tape drive caught fire due to the 'read a card to tape, rewind, read tape, rewind, read a card to tape, rewind ...." -- David Barto, Celerity Computing, San Diego Ca, (619) 271-9940 decvax-\ bang-\ ARPA: celerity!barto@sdcsvax.ARPA ucbvax-->-sdcsvax->!celerity!barto ihnp4--/ akgua-/ "Moderation in all things, including moderation"
suhre@trwrba.UUCP (Maurice E. Suhre) (03/04/86)
In article <2851@amdahl.UUCP> esf00@amdahl.UUCP (Elliott S. Frank) writes: > >As I remember, the index registers on the 7094 [optional feature!] >had a display box that sat on top of the console > The box contained the additional index register lights. The original ones were numbered 1,2,4 and the additional ones were 3,5,6,7. The Fortran compiler would use the extra index registers if you got your loops nested, or used a lot of matrices in them. The only word I ever saw displayed up there was TILT. Maurice {decvax,sdcrdcf,ihnp4,ucbvax}!trwrb!suhre
stassen@spp2.UUCP (Chris Stassen) (03/05/86)
In article <6450@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >I was once told that the operating system for the Burroughs B1700, another >computer well-supplied with lights, displayed a smile in its idle loop. > Henry Spencer @ U of Toronto Zoology Some Honeywell computers make "bird calls" over a built-in speaker when idle. If the computer room sounds like a jungle, then you're certain to get lots of CPU for your jobs. -- Chris
mwm@ucbopal.BERKELEY.EDU (Mike (I'll be mellow when I'm dead) Meyer) (03/05/86)
The NanoData QM/1 (a horror story all by itself) has 16 18 bit registers. These are displayed on the front of the machine so that you have a nice 8 x 36 array of lights (and the lights correspond to the registers in a pattern you'll *never* guess). When idling in the default nanocode, the box displayed "QM1" in nice big letters. Load up the PDP-11 emulation, and it says "PDP." I don't know what the 370 emulation said. We were tempted to make the machine we were building (writing?) spell it's name out - "QMC". Sometimes, I agree with ea!jejones, and think that many programmers could use a cutesypooectomy. <mike
davidh@utrc-2at.UUCP (David M Haynes) (03/05/86)
While working on a project at Litton Systems, I heard of this embarrassing moment. One project (for the military) required that the military supplied technicians be taught how to service the computers they had bought. The lessons were proceeding well with the explicit instructions "Don't apply the power until we check it." Naturally, somebody jumped the gun. Immediately, 120V AC was applied accross the core memory (yes, core, not silicon). The result? A pile of slag and a whopping replacement bill. -david- -- ==================================================================== David Haynes (-david-) "Quick Watson! The debugger!" ..!utzoo!yetti!utrc-2at!davidh ..!utzoo!ecrhub!david ====================================================================
esf00@amdahl.UUCP (Elliott S. Frank) (03/05/86)
[......................................urp!] When I was working at the computer center at Columbia University, we had a 360/91 [limited edition, heavily pipelined, fast floating point, dtl(=VERY VERY HOT, VERY FAST) logic]. One day I noticed little bright colored cloth flags attached to the top of the cpu and I asked one of the resident FE's about them. He said that they were added after an incident elsewhere with another 360/91. The /91 was water cooled -- it had a closed loop system that took about 400 gallons of distilled water. It seems that one evening, the water system on that machine sprang a leak, and dumped the contents of the chilling system under the raised floor. 400 gallons spread over a large machine room is not very deep, so nobody noticed. This was before subfloor water detectors were common, so no alarms were set off. The computer room had enough air conditioning to handle late-sixites/early-seventies(=low thermal efficiency) computer equipment. So the chilled air flow through the machine was enough to keep the thermal sensors in the CPU from shutting it down. The water finally reached some of the subfloor electrical connections, and shorted them out. Unfortunately, they were the connections for the chillers. With no cold air, the ambient in the CPU started to rise. Before the sensors in the CPU could shut the machine down, it literally melted from its own internal heat. After the machine was reconstructed, we (and all of the other /91's) got the cloth flags -- the operators were to check them, and if they were not waving in the breeze, shut the machine down first, and check later.
henry@utzoo.UUCP (Henry Spencer) (03/05/86)
And then there's the old trick of manipulating an IBM 029 keypunch so
that it punches cards which are all holes. Great bookmarks; I still
have a few.
Ideally you want to have a roomful of keypunches on hand, because the
mean time between jams when punching those things is only a few cards.
What would happen if one of them went into a high-speed card reader,
I don't know. The mind boggles.
(For the benefit of the fuzzy-cheeked youngsters in the crowd, punchcards
need a certain amount of mechanical strength to survive machine handling.
All-holes cards are weak and tear easily. Normal punchcards are constrained
to have [as I recall] at most one punch per column in rows 1-7, so that the
central region of the card is mostly solid.)
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henrydoug@terak.UUCP (Doug Pardee) (03/05/86)
> a small disaster. However the teflon insulation reacted with the hot > (molten) metal to form HF gas. When the fire department turend on the > sprinklers in desperation hydrofloric acid. In 1970 ('71?) Fresno State's computer room was the target of a firebomb thrown by some protesting students. The fire department arrived and hosed everything down. The fire damage was negligible. But then the FD decided that since it was electrical equipment, they should be using CO2 extinguishers instead. Either water or CO2 would have been okay alone; but when the CO2 was sprayed on top of the water, it formed carbolic acid [or is it carbonic, I don't remember]. Destroyed all of the equipment, the disks, and the tapes. Took about a year and a half to recreate their records from hardcopy. --- At that time, our CDC CE told of a student demonstration in Canada where a university's CDC 3300 had been wrecked by demonstrators and sold as scrap. A CE reportedly bought the machine after observing that almost all of the damage was bent sheet metal and unplugged connectors. He supposedly set up a service bureau in his home. I'm not sure I believe this story. -- Doug Pardee -- CalComp -- {hardy,savax,seismo,decvax,ihnp4}!terak!doug
drich@bgsuvax.UUCP (Daniel Rich) (03/06/86)
Speaking of doing things to power lines...I remember a story I heard from my circuits professor in Colorado. It seems that they received a computer from the government (I can't remember the make, but it wasn't anything I had heard of before). This computer was a bit of a beast. It ran off of 3-phase power, and had a disk that was between 3 and 4 feet in diameter. Well, several students were involved in setting up the disk drive one night, and when the professor left he told them that they could connect everything, but not to power it up until he checked it over. Well, you know students...they wired it up and turned it on. For those of you who are not to familiar with 3-phase power, if you reverse any 2 out of the 3 wires, the polarity changes. Well, they managed to reverse 2 of the wires, causing the disk to spin backwards. Now, since the heads are designed to float on a cushion of air above the disk, they went down instead of up, and the disk ended up with a nice groove right down the middle. Needless to say, the prof wasn't pleased when he came in the next morning and found his nice new disk turned into so many magnetic shavings....
davis@ucla-cs.UUCP (03/07/86)
I was working in a somewhat large data center not to long
ago. Seems the company thought they could save some money on maintenance
costs by going self service. Well it seems that a year or two later another
great cost savings idea was to hire C.E.'s that had only 6 months training in
the electronics field!!! Well the time came to install a new super
minicomputer, tape cabinet, and disk cabinet. Well they put the new C.E.
in charge of the whole project. He connected the cables from the disk cabinet
to the CPU, then connected the cables from the tape drive to the CPU.
All set! He plugged in the tape drive and then the disk cabinet to A.C. When
he went to plug in the CPU he noticed that the electrical outlet was a
different kind than that of the computer. But this C.E. was smart. He thought
of a way that he could remove the plug and install a plug that would fit in
the outlet. (Then the company would not have to pay for an electrician).
Good Idea except that he switched the HOT and the GROUND wires when installing
the new plug. As we all know computers are well grounded. Well the grounding
also is good in cables that connect to peripherals as well as within the
peripherals themselves. Of course this bright C.E. turned on the disk cabinet,
tape cabinet, and CPU before plugging in the CPU plug. You should have seen
the smoke and sparks when he plugged in the CPU. The tape drive was shot,
the disk cabinet was shot and the CPU was shot!!!!! At least none of the
terminals were connected at the time. It took 4 C.E.s 1 week of constant
work to repair the damage. Ever see a memory board with the chips blown
to kingdomcome?
--
._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Bill Davis - UCLA Center for Experimental Computer Science |
ARPA: davis@LOCUS.UCLA.EDU |
UUCP: (ucbvax,ihnp4)!ucla-cs!davis |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ben@catnip.UUCP (Bennett Broder) (03/07/86)
In article <875@spp2.UUCP>, stassen@spp2.UUCP (Chris Stassen) writes: > In article <6450@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > >I was once told that the operating system for the Burroughs B1700, another > >computer well-supplied with lights, displayed a smile in its idle loop. > > Henry Spencer @ U of Toronto Zoology > > Some Honeywell computers make "bird calls" over a built-in speaker > when idle. If the computer room sounds like a jungle, then you're > certain to get lots of CPU for your jobs. > -- Chris Back when I was an undergrad at Oberlin College, I had the pleasure of working as an operator on their Xerox Sigma 9. The best part of the job was bringing down the machine. The console displayed "Thhhhhhats all Folks!!!", while the processor treated you to a rendition of the Star Spangled Banner on the CPU alarm. -- Ben Broder {ihnp4,decvax} !hjuxa!catnip!ben {houxm,topaz}/
greenber@phri.UUCP (Ross Greenberg) (03/08/86)
A friend of mine relates the following: Seems that CalTech had a very large drum memory in the days before decent-sized disks. Seems that this sucker was about eight feet long, about five feet in diameter and weighed a bloody great deal. Took about an hour to spin up to speed, and about three hours to spin down. Some students calculated what would happen if it threw a bearing, and bounced onto the floor, through the brick wall, down a few flights, across some grassy area, and into a parking lot. Red arrows were supposedly drawn to indicate the destructive path of this monster. -- ------ ross m. greenberg ihnp4!allegra!phri!sysdes!greenber [phri rarely makes a guest-account user a spokesperson. Especially not me.]
mc68020@gilbbs.UUCP (Tom Keller) (03/09/86)
> In 1970 ('71?) Fresno State's computer room was the target of a firebomb > thrown by some protesting students. The fire department arrived and Patently untrue. The firebomb was placed by a student employee of the computing center. No one really knows the reasons, though at the time there had been some vehement objection amongst the business community in Phreasnaugh to the computerization at FSU (now known as CSUF), and one theory which many people adhered to was that a consortium of business owners paid the student to commit the crime. As the student refused to explain his motives, this will most likely remain a mystery. The student did serve (and may still be serving, for all I know) a jail sentence for the crime. -- ==================================== Disclaimer: I hereby disclaim any and all responsibility for disclaimers. tom keller {ihnp4, dual}!ptsfa!gilbbs!mc68020 (* we may not be big, but we're small! *)
jst@abic.UUCP (Shack Toms) (03/10/86)
> And then there's the old trick of manipulating an IBM 029 keypunch so > that it punches cards which are all holes. Great bookmarks; I still > have a few. > [text deleted] > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Its been 15 years since I tried this, but I think I remember that an all holes punched card will remain stable as it falls. That is if you hold it parallel to the floor and let go, it will drop straight down, remaining parallel to the floor. A no holes (new) punch card will flop back and forth as it falls. Probably something to do with aerodynamics, but I dunno what. Shack Toms
gmack@cisden.UUCP (Gregg Mackenzie) (03/11/86)
{}
And then there was the programmer at Contel today (no, it wasn't
me :-) who ran some commands that he found in net.rumor and removed
his directory.
In article <223@bu-cs.UUCP> bzs@bu-cs.UUCP (Barry Shein) writes:
> Re: running jobs that bring the system to its knees.
>
> There is another way to deal with getting rid of such jobs. Let's
> assume the user's login name is 'john', then the following is effective:
>
> rm -r ~john
> ed /etc/passwd
> /^john:/d
> w
> q
Or something like that. He bent over and took it like a man, though. :-)
Gregg Mackenzie
cisden!gmackjr@bbncc5.UUCP (John Robinson) (03/11/86)
In article <1322@decwrl.DEC.COM> moroney@jon.DEC (Mike Moroney) writes: > >>I also remember sending a print file that contained about 1000 logical >>end-of-records (and nothing else) to a remote line printer. It took about 5 >>minutes for it to transmit and print nothing. When MCIMail first went on the air, they charged for hardcopy mail delivery by the character (actually, 5000-character unit). You could mail yourself or a friend a few reams of paper for $1 by sending a file of formfeeds. They fixed their charging when we pointed this out. Also, their password-generator occasionally spits out somewhat racy words (they have the form consonant-vowel-consonant-...-vowel, 8 characters in all). The generator checks for most of the obvious bad ones, but it seems a few must slip by the censors. We suggested that they ought to charge extra for the racy ones, on the grounds that they would be so much easier to remember. This idea was rejected, though its originator got such a password for the thought. /jr
john@moncol.UUCP (John Ruschmeyer) (03/11/86)
In article <1077@terak.UUCP> doug@terak.UUCP (Doug Pardee) writes: > >At that time, our CDC CE told of a student demonstration in Canada where >a university's CDC 3300 had been wrecked by demonstrators and sold as >scrap. A CE reportedly bought the machine after observing that almost >all of the damage was bent sheet metal and unplugged connectors. He >supposedly set up a service bureau in his home. I'm not sure I believe >this story. I believe it. Our Perkin-Elmer (oops, Concurrent) CE's have a habit of collecting equipment that otherwise would have been thrown out as junk. One of them bought an old 16-bit machine (a P-E 7/16) that we long ago had no use for for some very low price. He still talks about converting it to a 7/32 (32-bit machine). I wonder what the garage of an IBM 370 CE looks like :-) -- Name: John Ruschmeyer US Mail: Monmouth College, W. Long Branch, NJ 07764 Phone: (201) 571-3451 UUCP: ...!vax135!petsd!moncol!john ...!princeton!moncol!john ...!pesnta!moncol!john Give an ape control of its environment and it will fill the world with bananas.
moroney@jon.DEC (Mike Moroney) (03/12/86)
I used to punch all the holes out of IBM cards, too. The O29's made awful noises when duplicating them, they often jammed in the process. I used to call my creations "waffle cards". When dropped, they will flop back and forth, but nowhere as much as a new card. (I dug one out and tried it.) For some reason the card reader where I went to school accepted such a card as valid, and interpreted it as a card full of right (left?) parenthesis. When I went to college, I was often *very* cheap. I found a couple of tricks that allowed me to re-use a computer card up to 3 times. We had a CDC Cyber running NOS, and one of the features of its job control language was it would ignore any character after a period on a card. This allowed me to take an old FORTRAN card with a short statement and insert it in the keypunch backwards and type a short control statement. It would ignore the (now backwards) FORTRAN statement when put in a deck backwards. I could then take the same card forward and use it as a record seperator card (special punch that wasn't a valid character, the rest of the card would be ignored, the special punch could be in any column, too.) Another way to save a few cards was a special "feature" of NOS that 2 consecutive colons in certain positions would be interpreted as an end-of-line. Therefore, I could type a short statement, space over, type "::", and start a second statement on the same card. Freaked out a few operators by submitting a few valid 1 or 2 card "decks" when the computing center added as a local mod short versions of common commands. In the dark ages when terminals were very scarce (and used paper, and were often 110 baud) a friend of mine, rather than wait for a terminal to become free to edit a file, would type all the edit commands on CARDS and submit his "edit session" as a batch job! He almost never screwed up the edit, either. -Mike Moroney ..decwrl!dec-rhea!dec-jon!moroney
jlh@loral.UUCP (The Man With No Brain) (03/13/86)
I remember when I was in college one of my teachers had a newspaper clipping on the wall with this story. Seems a large company decided to computerize, and they bought a large computer to do it with. They installed the system in their skyscraper, but to their dismay kept getting 2-3 random crashes a day. For a couple of weeks they had the manufacturer's rep out there, trying this and that, to no avail. The problem? A couple of floors up, a section of the floor wasn't braced properly. Therefore, whenever a lady over a certain weight sat on a certain toilet of a certain ladies room the floor gave a bit and shorted out some of the cabling to the computer. Naturally, by the time the tech could get to the system to find out what happened, the unsuspecting lady had finished her buiseness and the problem was gone. How they found that I'll never know.
fetrow@entropy.UUCP (David Fetrow) (03/14/86)
On my FIRST day as a computer operator I was being shown how to back up the
disk cartridges on an old Prime 300 (some consider that a horror story all by
itself). We had just lost our old CDC 60Meg Washtub so everything was being
done on Pertec 1.5 Meg cartridges. On the Prime these are in a kind of a daisy
chain: Pertec, CDC, Pertec. We backed up weekly, quarterly and yearly.
The fellow instructing me had been out of town for a month (the month the
the quarterly backups WOULD have been made if he'd been there) and forgot
about the unusual arrangement. Without the CDC both the working copy and
the weekly backup of our primary research disk were destroyed.
--
- Dave Fetrow
{ ihnp4, fluke, tektronix, uw-june }!uw-beaver!entropy!fetrow :UUCP
entropy!fetrow@uw-june.arpa :ARPA
fetrow@UWALOCKE :BITNET
74175,1724 :Compuserveron@brl-smoke.ARPA (Ron Natalie <ron>) (03/14/86)
> > I used to punch all the holes out of IBM cards, too. The O29's made awful > noises when duplicating them, they often jammed in the process. I used > to call my creations "waffle cards". When dropped, they will flop back and > forth, but nowhere as much as a new card. (I dug one out and tried it.) > For some reason the card reader where I went to school accepted such a card > as valid, and interpreted it as a card full of right (left?) parenthesis. Actually you are lucky, duplicating cards with multi-puched holes in them on IBM keypunch machines is likely to blow the printhead and wedge the machine even if the print head was turned off. -Ron
crshnider@watnot.UUCP (Charles R. Shnider) (03/14/86)
Here are a couple of interesting, but not too horrible things that happened
while I was on a co-op job with a mining company in Western Canada. The site
had two HP 3000 minis.
We had a program on our system that I think was given to us by an HP system
engineer. The program was called KILROY, and started by displaying a face
drawn in characters on the terminal. The eyes would look both ways, the face
would go away, and the program would give the user "the finger". Well one
programmer decided to install KILROY on an account used by a co-worker to
test out a new system. The program was run automatically at logon. Little
did he know that the system being tested was slated for a demo to *top
management* the next day...........
The HP 2626A terminal has a programmable bell character in it. You can
vary the pitch and maybe the duration of the bell. One of our programmers
spent the better part of a month working with this feature at the expense
of his other work. When the MISmanager came to see how his system was doing,
all he could demonstrate was a program that would play "Happy Birthday" on
any 2626A not logged onto the system.......
We also had a program called TERMLOCK designed to let you secure your
terminal for a few minutes while you stepped out of the room. It would
lock up the terminal until a password was entered to unlock it. A favorite
trick to play on unsuspecting users was the "instant termlock". What you did
was:
1. Log on your session and TERMLOCK it.
2. Find a hapless user that needs to be termlocked.
3. Have someone go into his/her office to distract them.
4. Break into a panel on the wall which connected terminals in the office
to ports on the cpu, and connect your terminal to his/her session, and
his/her terminal to your session.
The user would then go to use his terminal, and would be greeted with
"Enter Password>" even though he had never left his desk. Various cat and
mouse games would then ensue....
Charles R. Shnider
University of Waterloo Waterloo, Ontario
crshnider@watnot.uucptim@unisoft.UUCP (Tim Bessie) (03/14/86)
A fellow I worked with once told me a horror story that happened when he
was working as an operator at MIT.
The system they were using had recently been converted to using a new
type of coated fiberglass disk, to replace the old, heavy metal-platter
kind. No problem there. Well, the system they had this 'Emergency Stop'
plug on it that you would pull when an emergency occurred (they assumed
it was for, say, a flood in the machine room). One late evening, a couple
of the operators were sitting around being bored, and decided to see what
would happen when they pulled 'Emergency Stop.' Immediately after pulling
it, they heard a strange sound in the disk cabinet. Looking over, they
saw an arm emerge from the side of the cabinet, on either side of a platter,
and CLAMP down on the platter. Apparently, this wasn't made for use with
fiberglass platters.
They were picking splinters out of the walls for days.
- Tim
PS. Can anyone tell me what kind of system this was? I don't remember.
--
---
Life is like an onion; you keep peeling off the layers,
and sometimes you weep.
- Carl Sandburg
---------------------------------------------------------------
---> Tim Bessie ----- {ucbvax,dual}!unisoft!tim
---> Unisoft Systems; 739 Allston Way; Berkeley, CA 94710
---> (415) 644-1230 TWX II 910 366-2145cjh@petsd.UUCP (Chris Henrich) (03/14/86)
[]
This disk drive got troublesome hardware glitches,
usually just after the end of the "normal" working day.
Which, for the programmers, was prime time, of course.
The glitches happened just when a very good-looking woman on the
cleaning crew walked past the drive. She usually wore tight
slacks, and a longish blouse... there was friction between the
layers of clothes as she walked, and the static charge
occasionally jumped to the disk drive.
Regards,
Chris
--
Full-Name: Christopher J. Henrich
UUCP: ...!hjuxa!petsd!cjh
US Mail: MS 313; Concurrent Computer Corporation;
106 Apple St; Tinton Falls, NJ 07724
Phone: (201) 758-7288
Concurrent Computer Corporation is a Perkin-Elmer company.larry@kitty.UUCP (Larry Lippman) (03/15/86)
In article <753@abic.UUCP>, jst@abic.UUCP (Shack Toms) writes: > > And then there's the old trick of manipulating an IBM 029 keypunch so > > that it punches cards which are all holes. Great bookmarks; I still > > have a few. > > Its been 15 years since I tried this, but I think I remember that > an all holes punched card will remain stable as it falls. Brings back fond memories when I was an EE undergrad during the mid-60's. The college I attended had a 7094 with a zillion tape drives running IBSYS. All submitted jobs (cards, of course) required a "job card" as the first card in the deck. Each job card had a three digit field which contained the maximum number of cpu minutes that a job could run. All undergraduates were given job cards which were PREPUNCHED for 001 minutes. With a little ingenuity, it was possible to take a piece of card chad and glue the 0 punches shut. Then, using a Wright hand punch, you could set the card for any time you wanted. System accounting was so poor, that this practice was seldom discovered. I knew a lot of fellow students who printed out awfully impressive log and trig function tables this way... And then there was the ``$STOP'' card. A card punched with these five characters and inserted into an unsuspecting student's deck would be recognized by IBSYS and halt the system - much to the displeasure of the computer center. Undergrads were never told about IBSYS JCL commands, unless they got hold of an IBSYS manual... :-) And then there was the IBM 407 accounting machine which was located in the student keypunch room to list program decks. Being of the original hacker generation, I was just FASCINATED by this 2-ton electromechanical beast. I quickly discovered the wiring panel, and spent many a covert hour figuring out what the 407 could be made to do. One particularly fun thing to do was wiring the "emitters", which could be used to print constant text strings in each output line. More than one unsuspecting person listed a deck and had MY risque comments printed in cols 72 through 80. Even more subtle was to use the emitters on the 513 reproducer; this "added" text was never dicovered until after the cards were actually listed. After a year of this nonsense by myself and others, the wiring panel doors were fitted with locks... ==> Larry Lippman @ Recognition Research Corp., Clarence, New York <==[ ==> UUCP {decvax|dual|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry <== ==> VOICE 716/741-9185 {rice|shell}!baylor!/ <== ==> FAX 716/741-9635 {G1, G2, G3 modes} duke!ethos!/ <== ==> seismo!/ <== ==> "Have you hugged your cat today?" ihnp4!/ <==
buck@graffiti.UUCP (Lester Buck) (03/15/86)
This is a story I heard on the Spring '84 DECUS Magic Session tape. A consultant got a desparate call from a large company which develops dog food. "Help. Our dogs are getting fat." he is told. It turns out they run a large kennel with automatic feeding stations run by a Vax and the Vax was regularly crashing for reasons DEC couldn't figure out. Sure enough, he showed up the first time just in the middle of a crash. Pandemonium reigned as technicians ran around trying to reboot the system and the dogs were going wild because whenever the system crashed, all the food servers dumped the food. Since they had had a PDP-11 recently with no problems, and they upgraded the power to handle the Vax, he started looking around at the power system. Sure enough, the cable went through one smart dog's cage. It had a broken sheath, so some simple Pavlovian conditioning had taught this dog that whenever he relieved himself on that one spot, he was fed. They replaced the cable and everything has worked fine since. I'm not sure I believe this, but it makes for a hilarious story on tape. A. Lester Buck ihnp4!shell!graffiti!buck
bzs@bu-cs.UUCP (Barry Shein) (03/15/86)
Ok, my two quickies... Several years ago I was working on a portable real-time system we had custom built (using an LSI-11/1, 4KB, home-brewed O/S.) There were two of them in the universe and were working hard on two separate research studies. Filled my heart with glea when I went to lift mine and out of its guts poured several ounces of coffee...(not me, never found out who.) A couple of years ago I was drinking coffee in my favorite coffee shop (maybe I should just stay away from the coffee!) when their phone rang, they shouted from behind the counter that it was for me, there was an alarm going in one of the machine rooms and I should get right over there. Ran over to find an operator standing there with a finger on the Halon hold button, we had a two zone alarm going so it was about to dump the tanks (I remember the operator looking very pleased at their current career choice). It didn't look like there was any fire, so I began running around pulling up floor tiles (after, of course, disabling the fire system) looking for the offending sensors, 90Db going off in my ears. Suddenly I notice this bad stinging pain in my arm, great I'm thinking, the big one, just what I need to finish a perfect day. Well, it wasn't that bad fortunately someone else in the room noticed the bee on my shoulder... I could go on. -Barry Shein, Boston University
root@cbm.UUCP (03/15/86)
> I believe it. Our Perkin-Elmer (oops, Concurrent) CE's have a habit of > collecting equipment that otherwise would have been thrown out as junk. > > I wonder what the garage of an IBM 370 CE looks like :-) > > John Ruschmeyer Oh well... Not too many years ago I helped a guy Ken ? move his data center from one place to another in North Jersey. He was an ex-Burroughs CE who liked the machines he worked on and bought one from one of his sites when they wanted to get rid of it. The system? A Burroughs 250 - about 8 bays of vacum tubes with a monster motor generator for power supply. He reassembled the system at the new site and had it working about a week later. He later asked one of my friends about the possibility of replacing the core memory with MOS chips, since the core driver tubes consumed so much power. I hope he replaced the system with a mini, but lost touch a while back. SORRY -- THIS IS A TRUE STORY!!! -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbm!grr but no way officially representing arpa: cbm!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
dyer@atari.UUcp (Landon Dyer) (03/15/86)
NBS was running version 6 Unix on a PDP-11/45 with four RL02 packs. It took nearly half a day to backup the system. Half a day to copy four 10 megabyte packs??? The operators (who didn't know any better -- they'd been given a canned procedure) were typing in DD commands to copy from one pack to another. They were using a buffer size of ten BYTES.... -L
mjl@ritcv.UUCP (Mike Lutz) (03/16/86)
Heard this one from a computer salesperson about 17 years ago:
Seems this firm had just purchased a new high-speed printer;
after it's installation, they noticed random form feeds in the
middle of reports that had printed perfectly in the past.
Multiple trips by CE's, replaced electro-mechanical parts, etc.,
but no solution. Finally the manufacturer sent out an engineer
to try to figure out what was going wrong.
WELL -- it seems that this printer's paper stacker was on *top* of
the printer rather than behind it: just over the front panel with
all the standard control buttons. It so happened that one of the
women operators was well-endowed, and when she went to retrieve
listings, well, a certain button got pushed and Voila! Blank
pages in the next report!
--
Mike Lutz Rochester Institute of Technology, Rochester NY
UUCP: {allegra,seismo}!rochester!ritcv!mjl
CSNET: mjl%rit@csnet-relay.ARPAcarl@proper.UUCP (Carl Greenberg) (03/17/86)
A bulletin board service in Oakland, CA, (Sunrise Omega-80) lost a drive when an ant walked across one of the disk drive heads as it was stepping.. Smeared the disk, the drive wasn't too good either, and the board was down for several weeks.. Carl Greenberg
okunewck@gondor.UUCP (Philip E. OKunewick) (03/17/86)
In article <118@graffiti.UUCP> buck@graffiti.UUCP (Lester Buck) writes: >...some simple Pavlovian conditioning had taught this dog >that whenever he relieved himself on that one spot, he was fed. >They replaced the cable and everything has worked fine since. > >I'm not sure I believe this, but it makes for a hilarious story on tape. > Well, it's a great story, but I'm not so sure... Back when she was a little girl, my mother's cousin had a problem with a certain dog that came around habitually to water one of their trees. This was not considered acceptable. To remedy this, her cousin set a metal plate at the base of the tree (right in the target zone) and drove a ground stake in. He then climbed the tree with wires connecting the plate and ground stake to an old style telephone crank generator. (For those of you who haven't ever played with them, these little babies will put out 90 volts on a good day.) Surely enough, the dog came around to make his appointed rounds. He lifted his leg, started to go, and the fella in the tree cranked like crazy. Now, when you consider that salty water is a very good conductor of electricity... Legend has it that it only took one dose of this conditioning, and that dog never came back to that tree again. (There is also the old story about the farmhand who relieves himself on an electric fence...) ---Duck
jhh@ihlpl.UUCP (Haller) (03/17/86)
At my school, the EE department was having their PDP 11/45 placed under a service contract. Their maintenance costs were very high on a per call basis. To give an idea, in the initial upgrading before being put under contract, they threw out the old backplane because of the high number of un-applied ECOs. The big problem they ran into was a glitch in the power supplies that only happened during disk accesses (sometimes). After much searching (at per call rates), they found that a ground strap was not attached, and when the RK05s in the frame did a full cylinder seek, the ground strap would swing into one of the power supply terminals, shorting it for a brief period. John Haller
jackg@tekchips.UUCP (Jack Gjovaag) (03/18/86)
Speaking of 7094s, I once worked at an installation that had two of these. The "console printer" on these computers was a large machiine that looked (and maybe was) a 407 accounting machine. The 7094 didn't have any kind of internal clock but the 407 did and its patch panel was wired up so every time a line was printed on it, the time was appended at the right margin. Thus elapsed time of a job could be determined by looking at the time printed when the $JOB card was printed and when the EXIT message was printed. Someone found out, however, that the timer did not advance while printing was in progress, so the times were a little inaccurate. To get a free run on the computer, all you had to do was keep the 407 continually busy and the timer would never advance. A program could issue a print to the printer every so often (not very often due to the slowness of the printer) and never be billed for a cent. It did drive the operators crazy though because everytime a line was printed on the 407, they went over to look to see if it was telling them something significant to the running of the job.
sutter@osu-eddie.UUCP (Bob Sutterfield) (03/19/86)
In article <2034@gondor.UUCP>, okunewck@gondor.UUCP (Philip E. OKunewick) writes: > In article <118@graffiti.UUCP> buck@graffiti.UUCP (Lester Buck) writes: > >... > >whenever he relieved himself on that one spot [power cable], he was fed. > > ... > lifted his leg, started to go, and the fella in the tree cranked [a > generator] like crazy. > > Now, when you consider that salty water is a very good conductor of > electricity... There are regular legends about winos in Chicago electrocuting themselves - something about the third rail on the El. But isn't this a bit far afield from computer horror stories? -- ----- Human: Bob Sutterfield Mail: sutter@osu-eddie.UUCP sutterfield-r%osu-20@osu-eddie.UUCP or: sutter@ohio-state.ARPA sutterfield-r%osu-20@ohio-state.ARPA
rfrye@netexa.UUCP (Rob Frye) (03/19/86)
Not a computer horror-story, really, but a friend of mine in the
Human Engineering field tells of a particular typewriter repairman
who was well known for fixing some of the strangest typewriter
problems rather quickly. The prime example was one day a female
secretary complained that her typewriter was occassionally putting
extra spaces between letters and words for no apparent reason.
He showed up, with an assistant and toolkit, and asked the secretary
to demonstrate the problem. She sat down and started typing, and
sure enough, the extra spaces appeared.
The repairman said she could go get a cup of coffee, and it would
be solved as soon as she got back. She did, and the assistant
started pulling out various tools, but the older guy didn't need
them. He went over to her chair and lowered it an inch or two.
When asked, he just said "watch". She came back, was asked to try
again, and lo and behold it was fixed! No extra spaces! Why?
The chair was too high, and as she leaned over the typewriter,
the rather-well-endowed secretary's bust kept hitting the space
bar as she typed...
Same friend also has a tape DEC has made of one of their early
design failures of the Rainbow and its disk drives. It is
affectionately known as "Debbie does DEC" and involves two
rather "techno-peasant" types trying to use the Rainbow and
instruction manual and end up wedging the floppy disk between drive
and cover (a small opening there in early design). DEC redid
both the equipment and the manual, but kept the tape [which was
to have been a training film!] as an example of poor human engineering.
--
--->
--
"You can Telenet, but you can't tell it much."
Rob Frye, NetExpress Inc.
{seismo,rlgvax}!hadron!{netex,netexa}!rfryemrgofor@mmm.UUCP (MKR) (03/19/86)
A while back I was the tech support person for a minicomputer OEM. Our customers were located all over the SF Bay area, we were located in Sunnyvale. Since the customers were spread around, I usually tried to diagnose and fix problem over the phone. One day a Berkeley customer called me to complain that there were sparks and bad smells coming from the computer. I assured him that that was ridiculous - computers don't generate sparks. He said that it sure did - every time he tried to plug in his modem. I told him to try it again while I was on the phone, so I could try to diagnose the problem. He laid the phone's handset on the table rather than putting me on hold (it wouldn't reach over to the computer, but it was in the same room). Things were quiet for a few seconds, and then I could hear a loud yelp that made its way across the computer room and through the phone. He came back on the line and said the computer had bit him. Clearly, this was an on-site job - not something I could diagnose from his description - so I drove up to Berkeley. When I got there, I saw the flat ribbon cable that connected the modem to the terminal interface - the power wire was on the edge, and for the whole length of the cable the plastic insulation had melted off, leaving the bare wires. Hmmm, I thinks to myself, what could cause such a thing? I whipped out my handy-dandy volt-o-meter and tested the outlets to which the various pieces of equipment had been connected. All were 110 volts - looked good. It finally occurred to me to check the polarity of the sockets - and sure enough - they were wired wrong. It was a very old building, and whoever had done the latest wiring in the computer room was obviously no fan of consistency. The modem and the computer tried to share a common ground, but in reality there was a whopping potential difference between them, and when they were hooked up, sure enough, the computer generated sparks and bad smells - something computers are not generally supposed to do. -- --MKR "The majority of the stupid is invincible and guaranteed for all time. The terror of their tyranny, however, is alleviated by their lack of consistency." - Albert Einstein
mrgofor@mmm.UUCP (MKR) (03/19/86)
Okay, one more computer "horror" story - this one's kind of cute. We were trying to sell a $60,000 system to a family-run company whose "computer expert" was in his 60's. We had a program called "Biosum" that would calculate the biorhytms for two people and add the sine waves together and tell you how compatible the two people are. The day of the biggest demo, the customer brings in his mother (head of the clan) to see what the company is going to be shelling out their money for. The customer wanted to show his mother something fun on the computer, so we fired up Biosum. Unfortunately, the mother had been born in the 1800's, and you know how sloppy BASIC programmers are when it comes to date conversions - especially 18 year-old programmers who think "20 years ago" qualifies as ancient history. When the program asked for her birthdate and she typed it in (she was just starting to get a thrill out of the machine), the program crashed very ungracefully. Talk about embarrassing... They bought the system anyway, but I don't think the matriarch ever really liked it. -- --MKR "The majority of the stupid is invincible and guaranteed for all time. The terror of their tyranny, however, is alleviated by their lack of consistency." - Albert Einstein
jr@bbncc5.UUCP (John Robinson) (03/19/86)
In article <733@petsd.UUCP> cjh@petsd.UUCP (C. J. Henrich) writes: > The glitches happened just when a very good-looking woman on the >cleaning crew walked past the drive. Reminds me of the Arpanet site that used to crash frequently right around the end of the day. Seems the cleaner plugged the floor buffer into a convenient 100AC outlet - the one inside the IMP cabinet. /jr
jr@bbncc5.UUCP (John Robinson) (03/19/86)
In article <140@atari.UUcp> dyer@atari.UUcp (Landon Dyer) writes: > >NBS was running version 6 Unix on a PDP-11/45 with four RL02 packs. >It took nearly half a day to backup the system. Half a day to copy >four 10 megabyte packs??? We once had an 11/34 running V6 from a DecTape. Type date at it and it spun its tape for 30 seconds before answering you. /jr
carl@hpcnof (03/19/86)
> Speaking of doing things to power lines...I remember a story I heard from > my circuits professor in Colorado. It seems that they received a computer > from the government (I can't remember the make, but it wasn't anything I > had heard of before). This computer was a bit of a beast. It ran off of > 3-phase power, and had a disk that was between 3 and 4 feet in diameter. > <amusing anecdote regarding trashing a disc>... The machine was a Librascope, down in the fifteenth basement of the Engine Center. The way I heard it, they managed to trash TWO discs and their drives before they figured it out. But you know how rumors are. Carl "Do I hear 3? 4?" Dierschow Hewlett Packard - Colorado Networks Division
rcj@burl.UUCP (Curtis Jackson) (03/20/86)
>In article <118@graffiti.UUCP> buck@graffiti.UUCP (Lester Buck) writes: >...some simple Pavlovian conditioning had taught this dog >that whenever he relieved himself on that one spot, he was fed. >They replaced the cable and everything has worked fine since. > >I'm not sure I believe this, but it makes for a hilarious story on tape. > I'm not so sure, either. One of my neighborhood friends great tricks was to say, in the presence of a new kid who wanted to be part of the group, "Yeh, ol' Fred bet me I couldn't kill the engine on his minibike without touching it, so I won the bet by pissing on the spark plug." Those new kids never did figure it out the easy way.... -- The MAD Programmer -- 919-228-3313 (Cornet 291) alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd allegra ]!burl!rcj ...![ ihnp4 cbosgd decvax watmath ]!clyde!rcj
MW9@PSUVM.BITNET (03/20/86)
OH, thought I'd throw in my two sense. :-)
During my short internship at DEC I heard a guy who'd just come
back from a call. This problem had been bugging them for months.
It was one of those "it has to be a blue moon in a month with an
r in it and you have to jump and and down, singing Ave Maria, while
running your program" to get the bug to appear kind of deals.
Well, after three months they decided to replace the machine (a pdp-11).
As they were taking it out, they noticed a mouse had chewed through the
wall behind the machine, and for some reason, the machine had no back.
The mouse voiced several comments about being displaced for it's
nice warm home (and toilet), but eventually left. The people got a new
pdp. With a back.
Shheeee....
-------
"Science does not remove the Terror of the Gods." -Bob
Michael S. Weiss
The Pennsylvania State University
MW9@PSUVM.BITNET
<* The opinions expressed by me do not reflect those held *>
<* by my school nor those of my employer. (If I had one.) *>
hsu@eneevax.UUCP (Dave Hsu) (03/20/86)
In article <2034@gondor.UUCP> okunewck@gondor.UUCP (The DUCK) writes: > >Back when she was a little girl, my mother's cousin had a problem >with a certain dog that came around habitually to water one of their >trees. This was not considered acceptable. > > ... > >Surely enough, the dog came around to make his appointed rounds. He >lifted his leg, started to go, and the fella in the tree cranked like >crazy. > >Now, when you consider that salty water is a very good conductor of >electricity... > > > ---Duck Salty? Did anyone say salty? 8-( -dave -- David Hsu Communication & Signal Processing Lab, EE Department <disclaimer> University of Maryland, College Park, MD 20742 hsu@eneevax.umd.edu {seismo,allegra}!umcp-cs!eneevax!hsu ARPA n. [acronym for Advanced Research Projects Agency.] An agency of the U.S. Department of Defense established in 1968 to test its defenses against misuse and piracy in the large-scale distributed processing environment. -Stan Kelly-Bootle, "The Devil's DP Dictionary"
kamath@reed.UUCP (Sean Kamath) (03/20/86)
In article <2034@gondor.UUCP> okunewck@gondor.UUCP (The DUCK) writes: >In article <118@graffiti.UUCP> buck@graffiti.UUCP (Lester Buck) writes: >>...some simple Pavlovian conditioning had taught this dog >>that whenever he relieved himself on that one spot, he was fed. >>They replaced the cable and everything has worked fine since. >> >>I'm not sure I believe this, but it makes for a hilarious story on tape. >> >Surely enough, the dog came around to make his appointed rounds. He >lifted his leg, started to go, and the fella in the tree cranked like >crazy. > >Now, when you consider that salty water is a very good conductor of >electricity... > ---Duck This does sound more like it. It seems that when my boss was working with a carnaval (I don't quite remember this exactly) there was this dog that was rather obnoxious (sp?). Well, carnavals have massive power needs, and it seems that they connected their 1/2 foot trunks at these junction boxes that looked like fire-hydrants. Yup. That dog went howling off never to relieve himself on one of those again... (BTW I think they ran huge voltages (7000?) with small amps? Right? Wrong? It didn't make sense to me...) sean kamath ihnp4!tektronix!reed!kamath
brianu@inmet.UUCP (03/20/86)
A place that I used to work at was experiencing a high incidence of tape
I/O errors. About 1 tape in 10 would have errors for no discernible reason.
(tape was clean, sometimes brand new). Finally we started tagging the tapes
with a red sticker when it had this problem. After a while it became apperent
that all the tapes were stored on the bottom rung of the tape racks. It seems
that the night cleaning crew would come in once a week and polish the floors
with their power waxing machines...
====================================================================
Gen: And do you mean to say that you would deliberately rob me of
these the sole remaining props of my old age, and leave me to go
through the remainder of life unfriended, unprotected, and alone?
Pirate: Well, yes; that's the idea.
Brian Utterback Intermetrics Inc.
733 Concord Ave. Cambridge MA. 02138. (617) 661-1840
UUCP: {cca!ima,ihnp4}!inmet!brianu
Life: UCLA!PCS!Telos!Cray!I**2koko@uthub.UUCP (M. Kokodyniak) (03/21/86)
> The modem and the computer tried to share > a common ground, but in reality there was a whopping potential difference > between them, and when they were hooked up, sure enough, the computer > generated sparks and bad smells - something computers are not generally > supposed to do. This reminds me of a nasty accident I had in the Power Electronics Laboratory. I had a terminal connected to a 6809-based microcomputer board. The board was in turn connected through an interface, driver circuit and isolation transformer to an SCR power module. The module was connected directly to the 117-volt line, which was protected by a 50-amp breaker. In the course of debugging the circuit, I had connected an oscilloscope -- isolated, of course -- to the circuit. I connected one channel, with its ground wire, to some point in the power circuit. I had other channels of the scope connected to the microcomputer interface. I understood that the microcomputer ground now became hot, but this was okay since the microcomputer power supply and terminal were both isolated -- or so I thought. Then I turned on the 50-amp breaker switch to energize the power circuit. BANG!!! A large current, enough to pop the 15-amp breaker supplying the computer and terminal, went from the power circuit, through one set of scope leads, through the scope, through another set of scope leads, through the computer ground trace, through the ground wire in the RS-232 cable and into the terminal. The goddamn terminal had its RS-232 signal ground strapped to the earth ground in the 117-volt line. The current blew a trace on the computer board. When it finished off that path, it proceeded to find the path of next lowest resistance -- the line driver and receiver chips in the computer board and the terminal. All four chips, plus some TTL chips in the terminal, were burned out. But one of those chips had a hole blown right through it! I could see remains of the substrate through the hole. Fortunately, the 15-amp breaker tripped before anything else was damaged. But the 15-amp breaker was slightly damaged -- it tends to stick a little upon turning on. (I left my mark in the lab.) All of this goes to prove that that third wire in the line cord does not always promote safety. In this case, it created a hazard. From now on, I will always use a ground cheater for terminals when working in that lab. Michael Kokodyniak, University of Toronto
hutch@hammer.UUCP (Stephen Hutchison) (03/25/86)
Folks... The volume of "horror stories" in net.rumors has been pretty high lately. Since they aren't really rumors, although some are certainly folklore, we probably ought to move them somewhere else. I suggest we move them to net.misc which is the appropriate place for miscellaneous things. As a move in this direction, I've set my "followup-to:" line to point to net.misc so that any followup articles will go there. Assuming you are running fairly recent news software. Hutch (If you must flame me, send it by mail please)
crs@lanl.ARPA (Charlie Sorsby) (03/25/86)
> All of this goes to prove that that third wire in the line > cord does not always promote safety. In this case, it created a hazard. > From now on, I will always use a ground cheater for terminals > when working in that lab. I believe the purpose of the third wire in the line cord is to cause any such unintended currents to flow through stuff in the "innards" of the equipment rather than through some unsuspecting external HUMAN. It seems to have done so! ;-) -- The opinions expressed are not necessarily those of my employer, the government or your favorite deity. Charlie Sorsby ...!{cmcl2,ihnp4,...}!lanl!crs crs@lanl.arpa
tuba@ur-tut.UUCP (Jon Krueger) (03/26/86)
In article <118@graffiti.UUCP> buck@graffiti.UUCP (Lester Buck) writes: >Sure enough, the cable went through one smart dog's cage. It had a >broken sheath, so some simple Pavlovian conditioning had taught this dog >that whenever he relieved himself on that one spot, he was fed. That's operant, or instrumental, or Skinnerian, conditioning. Not Pavlovian. It would be Pavlovian if, say, the VAX crashed now and again all by itself, and flashed lights and sounded bells immediately prior to crashing. Sorry to be picky. My code used to control experiments of both types.
faunt@spar.UUCP (Doug Faunt) (03/28/86)
In article <6466@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >And then there's the old trick of manipulating an IBM 029 keypunch so >that it punches cards which are all holes. Great bookmarks; I still >have a few. > > >(For the benefit of the fuzzy-cheeked youngsters in the crowd, punchcards >need a certain amount of mechanical strength to survive machine handling. >All-holes cards are weak and tear easily. Normal punchcards are constrained >to have [as I recall] at most one punch per column in rows 1-7, so that the >central region of the card is mostly solid.) >-- > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,linus,decvax}!utzoo!henry Don't talk about youngsters, children. 029's were the NEW keypunches, and we had a 024 in the computer room for duping COLUMN-BINARY cards, which could legitimatley ((SP?)I don't think so, but the spelling checker likes it) have all holes punched in a column. There were also ROW-BINARY cards that contained 24, 36-bit words per card, with 8 columns for sequence punching. Sequence punching was rather like backing up your diskette today. The joys of BCD.
davep@hammer.UUCP (Dave Patterson) (03/28/86)
In article <391@geowhiz.UUCP> schuh@geowhiz.UUCP (David Schuh) writes: >In article <2050@gondor.UUCP> okunewck@gondor.UUCP (Philip E. OKunewick) writes: >> >>Cany anybody out there think of one word that means 'Computer Horror Stories"? >> >> ---Duck UN*X :-) David Patterson {ucb or dec}vax!tektronix!hammer!davep uucp address davep@tektronix csnet address davep.tektronix@rand-relay arpa address ------ The opinions expressed above blah blah blah