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

Text File | 1993-06-12 | 8.6 KB | 218 lines

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

     When last we saw our hero, he was
diddling Faithful Nurse Stella, while her
erstwhile paramour, Dr. Jameson was dallying
with her half-sister ...
     Ooops, wrong plot line.
     Let's see. In our last, suspense laden
episode Peggy, the Light of my Life, had lost
her camp Alumnae Newsletter in a litter of
tumbled bits and bytes. Our dauntless disk
diver had descended into the dolorous deeps
in a desperate dip to discern the dimensions
of the disastrous debacle.
     Oh oh. Watch that alliteration.
     Anyway, it turned out, at the very
least, that the directory track was succotash.
     Reentering the data was feasible, but
not practical. Much of it had been
painstakingly extracted from letters and
journals sent to Peggy by her Faithful
Friends. Time, for our delectable heroine,
was in short supply. The deadline was bearing
down on her like a runaway D&H locomotive.
She was in the midst of three big projects.
     It was all up to me. I was going to have
to troll the brinery deeps for those files.
     The first thing I had to do was to see
if they were still there. Using DU, unrolling
a metaphorical string behind me so I could
find my way back out, I tip-toed delicately
through the disk to see what lurked in the
labyrinth.
     A few spot checks revealed that (so far)
the damage was limited to the directory
track.  Everything else looked sound.
     But the files were scattered in bits and
pieces all over the place. That, of course,
is the way a computer works. It looks for the
first free space in which to put a file.  If
the space isn't big enough to take the whole
file, it'll stick a bit there, another piece
in the next available slot, and log in the
directory where the bits and pieces are
located.
     Complicating the hunt, Peggy's single largest
file had been worked on several times.
Pieces of old versions lurked as decoys
amongst the new. To DU and me they all looked
the same. Adding to the confusion were
fragments of even older files moldering like
the mummies in Raiders of the Lost Ark, files
that had long ago been erased (marked on the
directory track as no longer needed, freeing
up the space for re-use) but still on the
disk. Well, I consoled myself, at least the
data was still there.
     So, I dug out a rusty old spear from my
armory called DOCTOR.COM. (I think I got it
from a buddy way back in his TRS 80 days.
And we know how long ago THAT was!)  The Old
Physician was supposed to be able to copy,
track by track, from a damaged disk to a
fresh one. He was not supposed to unscramble
the scrambled track, but it would (I hoped)
give me a backup disk to muck around in
without risking the main disk.
     Sadly, either senility had weakened his
healing skills, or else a Grue got the good
DOCTOR. He plodded along until he hit Track
28 and then started myopically insisting he
was getting "Hard Errors". DU had already
told me track 28 was in perfect shape. So
much for DOCTOR.
     Obviously it was time to update my
armament.  Trashed disks being a common
hazard, the CP/M software library on GEnie
had a half dozen utilities to deal with the
problem. I took a chance on a couple, and
added the updated version (8.9) of DU to my
shopping list.
     After downloading, un-librarying and
uncrunching and the like, I studied what I
had.
     DIRREP21, it turned out, was useful only
if you had made a backup copy of your
directory ahead of time. So much for THAT one.
     REPAIR.COM's documentation said it could
be used to recover from a trashed directory
by allowing me to assemble the file fragments
and move them to a new disk under new names.
Just what I needed!  So, I printed out its
documentation (only 2 pages, and reasonably
lucid), cranked it up and told it to go to
work on the disk in drive B.
     Over the years I have heard my TEAC disk
drives make many different sounds. They whir.
They purr softly. They grunt, chuckle and
clack. Sometimes I get a disk that ticks.
Nice, workman-like sounds.
     Drive B sounded off like a coffee
grinder encountering a pound of rivets. I
dislocated my elbow reaching for the reset
button.
     So much for THAT program. I frisbeed the
disk across the room. If the window had been
open it would have wound up in the pond.
     I was left with only that one copy of
the lost files to work on, and my new,
improved, turbo-charged, tail-finned and
chrome trimmed version of DU. Like it or not,
I was being upgraded from the band-aid and
iodine division into open skull neuro-surgery.
     DU has a raft of talents in addition to
showing what is in each sector on a disk. A
list, with minimal explanation, of DU's
commands would take up two single spaced
pages.
     For one thing, you can use it to change
individual bytes. Just for fun I've used it
to change WordStar's opening menu to be more
cheery on a bleary morning. Hacker fun.
     Theoretically, by plugging the right
bytes in, I could reconstruct the ruined
Directory Track that was the source of all
our problems. All I needed was an intimate
understanding of how addresses are coded, and
to determine the address of every piece of
every needed file on the disk.
     Now, the former I understand (I think).
Files are stored in Groups (identified by
hexadecimal numbers) of eight Sectors. There
are ten sectors per track, and 40 tracks on a
single sided disk (which this was). And then
there's something called Logical Extents, and
...
     Well, you get the idea. And hey, we're
talking getting addresses for fragments of
files scattered in 128 (hexadecimal) groups
over only 400 (decimal) sectors. And of
course, if I messed up ...
I didn't waste much time on that approach.
     An alternative was to suck a sector of
file at a time up into RAM (another of DU's
talents) and then unload it on to a new disk.
A sector holds 128 bytes, about one long
sentence. Of course, I had no idea just how
big any of the files were supposed to be.
Fortunately, files are stored in a logical
numerical sequence. DU's (M)ap command gave
me a chart of the group numbers under which
the files might be stored, but the map came
from the bad directory track.
     Ah hmmm. And I thought Exxon had trouble
in Prince William Sound.
     Well, there seemed nothing to do but to
go for it. I could tell DU to go to a Group
(the G command), (Y)ank it Sector by Sector
into memory, then (L)og on to a new disk in
drive A and (S)ave it. Tedious and
painstaking, but feasible.
     And anyway, it was the only avenue still
open to me.
     I automated the pickup stage by stacking
DU's commands: D (to display one sector); Z20
(take a nap for two seconds, Turkey, so I can
read the display); then, unless I stop you,
(Y)ank it into RAM; + (step forward one
sector); and repeat (/). The whole command
looked like this:

                D;Z20;Y;+;/.

     As you've no doubt astutely observed, DU
uses the semi-colon to separate commands. To
speed the process up I tried Z10, but things
moved by too fast, making me dizzy.
     By keeping track of the sectors before
they were slurped up, I hoped to hit "C" to
stop the process when I reached the end of
that section of the file and before I ran out
of runway.
     Once I got a chunk of file in RAM, I
would give it a name and unload it on to a
brand new disk. Since not all the groups
holding the file were contiguous, I would
wind up with each one of Peggy's files in
several little heaps, but, if I was lucky, at
least it would all be there - I hoped. I was
still flying partly blind, thanks to the
unreliable map off the directory track.
     Well, there was nothing to do but take a
deep breath, and go for it.
     Mirabile Dictu!  It worked!  I looked on
the new disk and, Captain, there be files
here!
     The battle was more than half won. Next
I simply used my text editor (VDE, of course)
to check the heaps out and reassemble them in
the right order.
     The patient was in surgery for about 6
hours, but after a full data transplant he
made a complete recovery.
     Backing up your data is like fastening
your seat belt when you get behind the wheel -
-you should always do it. Two minutes spent
backing up those files in the first place
would have avoided the whole problem. But
then, I wouldn't have had anything to write
about for the last two months, either.

        Keep the Faith, fans.