CP/M/CPM_CDROM.iso/zsys/znode-12/i/perils.1

Text File | 1993-06-12 | 6.0 KB | 147 lines

             The Perils of Peggy
                  (Part 1)
                     by
                  D.FOWLER2

     It was a dark and stormy night ... uh,
this is a scholarly publication? Sez who?
     I've been messing with computers for six
years. In that time I've learned that things
do go wrong from time to time. I must say
that our Kaypros are extraordinarily
reliable. We've never had a serious
electronic or mechanical problem. Oh, I've
had to vacuum the cat hairs and Oreo crumbs
out of the keyboard occasionally, and I've
cleaned the disk drives once or twice, but
nothing beyond that.
     I can remember only four or five times
when I have had any disk reading problems.
Never have the problems arisen because of the
disk drives, and rarely have they been
serious. Once my Perfect Calc program
committed suicide on me. In my foolish youth
I scrambled a WordStar disk by storing it on
top of my computer, right over the monitor
with its nice strong magnetic field. Data-
wise, Perfect Calc spreadsheets sometimes get
corrupted when one bit flips from 0 to 1 (or
vice versa). I fix those with my text
processor. I had a dBaseII file send a few
letters into italics on me. Again, one bit
had switched from 0 to 1. I added a filter
routine to the command program to get rid of
that problem. Nothing major.
     Think of how fragile our data is. All
that information is stored as tiny bits of
magnetism in a thin coating of "rust" on a
floppy plastic platter. It's read by a
delicate bit of electronics as the platter
spins at 300 RPM a fraction of an inch away.
     Think about it and you get this sudden
impulse to back up your data Right Away.
Because something could go Very Seriously
Wrong. As recently happened to my long
suffering spouse, Peggy.
     She produces an Alumnae Newsletter for
her old summer camp. This year it has to get
out in time to round up everyone for the
reunion up in New Hampshire in June, so she
was really hammering on it. All the various
parts of it, about 45 single spaced pages,
were on one disk (of course). Well, there she
was, churning along on the table of contents
and she went to save her work and right in
the middle of the save, with no warning,
Everything went CRASH! "BDOS ERROR ON B: BAD
SECTOR."
     Naturally, she had been going to back up
the data onto another disk Real Soon Now.
She'd been walking the tightrope without a
net and the rope broke. That's always the way
it is. I've never heard of a disk crashing
just after you have backed things up.
     She did not throw a screaming fit. She
didn't even mutter under her breath. The
silence was frightening.
     When something like this happens, I get
called in (though Super Hacker I am not). A
quick check and I knew we were in trouble.
WordStar floundered like a wounded albatross
when asked to do anything with that disk.
Just asking for a directory of the disk
produced a spastic grunting from any drive it
was in. I got the sinking feeling that
nothing short of an act of God was going to
read that disk, IF the files were still there
at all.
     Feeling somewhat akin to St. George, I
shouldered my nerd pack and ventured into
chaos. My first reconnaissance was with
NSweep. After being prodded past its "Read
Error" message with several <Return>s it
managed to penetrate the wreckage. It did
succeed in listing the files, but could do
nothing with them.
     It was obviously time to bring in the
heavy wrecking equipment. I reached for my
rusty old (7.7) version of DU.
     DU is the ultimate Disk Utility. DU is
to NSweep as a large backhoe is to a shovel.
It is Mr. Goodwrench's Garage, as opposed to
the $8.95 26 piece socket set you bought at K
Mart. It is ... well, you get the idea.
     DU is also to be used VERY CAREFULLY,
because you can easily dig the hole you are
in a great deal deeper, and then pull it in
after you. So, magic wand in hand, cloak of
invisibility enfolding me, brass lantern
lighted and held aloft, I tip-toed in,
constantly on the watch for fearsome Grues.
     DU looks at the designated disk in great
detail. Once you tell it exactly where to
look, by track and sector, you can ask it to
show you what is there with the (D)ump
command. It will display (in hexadecimal
code) every byte in a sector, and (if it is a
text file) a "translation" of it into the
ASCII.
     The first thing DU did when I invoked it
and asked it to look at Track 1, Sector 1,
was make the drive holding the ravaged disk
make a lot of noise, (but good noise, as I'll
explain later). It then informed me, and I
quote: ++ READ failed, sector may be invalid
++. Then it displayed what it had found.
     My worst fears were confirmed. What
should have been the directory of the files
on the disk was trash. Some file names were
legible, but not all. Worse, on the line
below some of the names, where there were
supposed to be file addresses it was
Chernobyl.
     You know, of course, that the directory
track is not there just so when you give your
computer the DIRectory command it can tell
you what you've got. It is there so the
computer can find the files in the first
place. Trash your directory track (or, for
you IBMers, your File Allocation Table (FAT))
and those files might just as well be on the
moon, or on an anchovy pizza, take your pick.
     Baaaadum! Baaaaadum! Baadum,
baadumbaadumbaadum.
     Had Jaws eaten Peggy's newsletter? Will
our Fearless Hero be able to plumb the turgid
depths and retrieve the Golden Treasure?
Will faithful Nurse Stella discover that Dr.
Jameson is dallying with the mysterious
amnesia patient in Room 214, who (unknown to
Stella) is really her half-sister by her step-
father who is Dr. Jameson's evil and
licentious long lost great-uncle? Tune in
next month.

              (To be continued)