A COMEDY OF ERRORS

Copyright Dr Alan Solomon (1986-1995)

You've all heard of Artificial Intelligence, and that's been hyped to
death (by the way, all my products have built-in AI already - go prove
otherwise).  This month, I would like you all to join me in a salute
to AS - Artificial Stupidity.  And a small prize will be offered to
whoever spots the most mistakes in what follows.  And at the end
there's a rather interesting question for you to answer.

It started with a phone call from Robin W.  Robin was the chief
accountant at XYZ PLC and he had a problem - he'd lost all his
spreadsheets, and there was, of course, no backup.  "How did it
happen", I asked.  "I was trying to do a backup", he said.  You'd be
surprised how often that happens.

He had the accounts of his PLC in a hundred 123 spreadsheets on an
Amstrad PC1512.  I know, I know, you don't have to tell me, I know.
Anyway.  He recognised the importance of backup, so he was backing
them up by doing a /File Retreive of each spreadsheet, and then a
/File Save onto a floppy.  This gave him a backup, but took rather a
long time, so he had a read of the manuals, and had an idea.  He did
COPY C:*.* A:, which copied about eight spreadsheets, but then the
floppy disk filled up, and the COPY aborted, so that didn't work.

But Robin had True Grit and didn't give up;  he fiddled around at
until he'd created another subdirectory and copied all his worksheets
into that, so at least he had a backup of sorts.  But he recognised
that it wasn't enough, so he went into that subdirectory, and did a
COPY C:*.* A:  to get them onto floppy.  Only a few of the files would
copy, of course, so he deleted those and did COPY *.* again onto
another diskette, until all the files were copied onto floppy disks.

Ten out of ten for ingenuity;  nought out of ten for reading the
manual.  This procedure worked, but as he explained it to me, I could
see the trap.  "So you accidently erased the wrong subdirectory", I
guessed.  Serves me right for being clever;  no, it was MUCH more
complicated.

Some of his files were 200K, but somehow, in the process of copying to
and fro, he wound up with all the longer files having exactly 67584
bytes.  I tried to find out how he'd done that, but he couldn't
remember all the steps he'd taken in creating the subdirectory and
copying the files;  he did say that he'd done it without leaving 123,
using /System (the DOS gateway), but I can't see how he could have
done it even so.  And I thought 67584 is such a funny number - not
65536 (64K) which is round, until I realised that it is 64K plus 2k,
and 64K is one 8086 segment, and 2K is one DOS cluster.  Not that this
explains anything.

Anyway, now all his large files were truncated, so he had a problem,
and naturally when you have a problem, you phone an expert.  The
expert's name was Arthur, and he had just the answer - run Recover.

A lot of people run Recover when they have a problem, and I haven't
ever met anyone who had the problem that Recover really does fix.  In
every case I've seen, Recover made things worse.  Read the DOS manual
if you want to know what it actually does, and try it out on a floppy
disk for a demo.  I asked Robin why he hadn't checked in the DOS
manual before using it, and he said that he had, but it wasn't there.
"So why," I screamed silently to Ahriman the god of computing, "did
Amstrad put it on the DOS disk?".  Being a cautious sort of person, he
tried it on one file first;  he typed RECOVER JULY87PL.WK1.  When
Recover had finished, he did a DIR, and saw that JULY87PL.WK1 had
disappeared completely, and had been replaced by FILE0000.WK1, which
had the same length of 67584 bytes.

So he phoned Arthur again, and Arthur said "That was because you did
it wrong.  You should have typed RECOVER *.*" So Robin typed RECOVER
*.*, and there was a lot of hard disk activity.  When the red light
had stopped flashing, he did another DIR.  He now had 118 files,
called FILE0000.REC, FILE0001.REC, FILE0002.REC - well, I won't bore
you with the whole list.  And all his .WK1 files had gone.  So what do
you do when you have a disaster like that?

Correct - you phone an expert.  The good news was that the expert was
in, and only too happy to give advice.  The bad news was that the
expert was Arthur.  "Arthur said that it was supposed to do that, and
that what I should do is run RECOVER again, and all the files will be
renamed back to their correct names." I closed my eyes, and asked what
happened next.  "I typed RECOVER *.* again, and the hard disk light
stayed on for absolutely ages."

When he next looked at his disk, he had no subdirectories, no DOS
files, no COMMAND.COM and no spreadsheets.  His root directory
contained nothing but FILE0000.REC up to FILE0511.REC.

At this point, Robin was in a state of pure funk.  He must by now have
become totally irrational, because there's no other way to explain
what he did next.  He called Arthur.

Arthur, of course, knew exactly what to do.  You run CHKDSK /F, he
said, that'll fix the problem.  Robin, still in a state of complete
terror about what his boss would do to him when he found out, ran
CHKDSK /F.  Normally, this would have screwed his disk up beyond all
recognition, creating a million FILE0000.CHK files all over the place.
But because he already had the maximum of 512 files in his root
directory, CHKDSK was powerless except to get rid of some cross-linked
files.  CHKDSK reported back that it couldn't create any files (disk
full), so guess what Robin did next?

It's a bit like snakes and rabbits - the rabbit is so terrified, it's
frozen to the spot, and can't run away.  Doctors get a similar effect
- even if the medicine tastes awful, you still swallow it because you
have confidence in the doctor, and have no idea what else you might do
to cure the disease.  The ever-resourceful Arthur had a solution to
this problem in his bag of tricks;  you reboot by switching off and on
again.

Robin, of course, did what Arthur told him - he switched off, waited a
few moments, and switched on again.  The Amstrad, of course, would not
boot, on account of COMMAND.COM now being called FILE0000.REC.  But
when you have a hard disk Amstrad that cost over #1000, and you have
all the accounts of a PLC on it, and a totally unsympathetic boss, it
is quite terrifying to think that you've managed to screw up the
computer so much that you've broken the hard disk.  Whimpering
slightly, Robin did the only thing he could in these circumstances
(well, I suppose seppuku would be an honourable alternative).  He
called in an expert.  Arthur.

At this point, Arthur came up with the first good idea he'd had so
far.  "Your hard disk is damaged", he said.  Robin almost suppressed a
slight anguished moan.  "You need someone who can fix damaged hard
disks.  Go to Doctor Solomon."

Robin phoned me up, and told me his story.  "Yes," I said, "I can get
your spreadsheets back, and maybe even get them back with their
original sizes, not truncated." I knew that all the pieces of file
would be there somewhere on his hard disk, and it would be simply a
matter of finding them, sorting out which pieces belonged to which
spreadsheet, and building them back into files.  I suppose "simply"
isn't really the word, but you can see how it's possible, with care
and patience.  And I've done this sort of thing before, so I know a
few short cuts, and have a few good software tools.

Robin came round with his Amstrad within the hour.  I got the story
from him in detail, and wrote it down in my log book.  I had to leave
the room a few times, because it doesn't do to fall about laughing in
front of someone who is facing the sack because he's lost all his
company's accounts.  I had a think about what I'd do, and how I'd do
it, and I gave him a no-fix-no-fee quote.  He accepted it immediately
- I guessed he'd got his boss to agree in advance.  Then I said that
it would take me a week.  "Can you do it in two days?", he said.
"No." I said.

I never try to rush a disk quack.  Rushing is usually what gets people
into the hole in the first place, and what I'm doing requires deep
thought, great concentration and I move quite slowly.  File-stitching
on Lotus spreadsheets is especially tricky - one wrong cluster and its
"Part of file is missing".

Robin explained.  "It's got to be done in two days, because I need the
computer to do the work on." I suggested buying another Amstrad
(that's the first time I've ever suggested to anyone that they buy an
Amstrad).  He countered with a suggestion that I lend him a computer.
I suggested that he should ask his dealer to do that.  Blank look.  I
guess his dealer was Dixons.

Robin put his cards on the table.  "Its my boss", he said.  "He thinks
the whole thing is my fault, and he won't even pay for a data
recovery.  And he won't wait for a week;  it's all got to be finished
this week."

I felt sorry for Robin, I really did.  He was in a terrible hole, and
he was willing to spend his own money if I could dig him out of it.
Against my better judgment, I agreed to have a go for two days.

That was really stupid of me.  After two days work, I was really
getting somewhere - I'd mapped out his disk, worked out what was where
and why, and I'd even recovered a couple of small files.  But there
was still a lot of work to do to get a full recovery, and there was
very little I could show Robin when he came back.

We packed up his Amstrad, and I sent him away, refusing to take any
money, as I hadn't done anything useful for him.  Robin won't be able
to recreate 118 spreadsheets within a week - not a chance.  I think
his boss will sack him, as he sounds like a nasty old scroat.  But
here's the question for you, and you'll need to think very carefully
before you answer, because it's a deeper question than it looks.

Who made the biggest mistake, and what was it?  If you want my
opinion, the biggest mistake was made by someone who isn't named here,
and in fact I think it was made by someone who wasn't even
mentioned here, but who certainly must exist in a big company like XYZ.

Alan Solomon