Date   : Sat, 14 Jan 1984 13:52:00 EST
From   : Eric Stork <STORK@mit-mc>
Subject: RESETT for dBASEII; Function #37 of BDOS

A few days ago, I submitted to the net a trick for POKEing an ass'y
routine from dBASEII and a specific illustration that I had
successfully used to solve a problem for a friend's accounting
system.  The illustration POKEd a routine utilizing BDOS Function #37
(reset an individual disk) and then CALLed that routine with a RETurn
to the dBASE .CMD file.

Jerry Pournelle has vigorously warned against using BDOS function #37.
His warnings are reproduced below. For me, it worked. But Jerry may be right.

Two more points:
       1.  At the end of Jerry's warning notes, a note from
           Bruce Conroy suggesting an alternate way of
           resetting dBASEII disks.  I have not tried, but
           will next time I need this function.

       2.  If someone from DRI reads this and can shed more light on
           the validity of the concerns that Pournelle has about
           BDOS Function 37, I for one would be eager to know
           what he/she has to say.

Eric

**************************************************************
Date: 14 January 1984 04:35 EST
From: Jerry E. Pournelle 
Subject:  Use of dBase RESET function.

I warn you: use of DR CP/M Function 37 "reset disk" can be
hazardous to your disk directory.  The exact sequences that can
trigger the bug are not known; but it exists, it's real, it
jumps out and bites you, and you cannot know that it won't since
we don't know how it does it.

You are warned.


Date: 11 January 1984 06:07 EST
From: Jerry E. Pournelle 
Subject:  *** SOMEWHAT IMPORTANT on dBase2 **

Your RESETT fix for Dbase 2 uses CP/M function 37 Reset Disk.

DO NOT USE THAT FUNCTION.

Function 37 has a serous bug, undocumented, that can cause CP/M
to write over the directories OF ALL DISKS it can get at,
including the A: disk, hard disks, memory drive disks, etc.  We
do not know precisely what triggers the bug; it takes a
reasonably complex pattern of disk changes and resets; but it
DOES THE JOB.  I know of three casees in which 10 megaByte hard
disks had to have their files reconstructed sector by sector
because they were bitten by CP/M FUNCTION 37.
       You must use RESET SYSTEM even though that logs you on
to the A: drive (and takes longer).  I repeat, DO NOT USE
FUNCTION 37.  You will regret it if you do.

J E Pournelle


Date: 12 Jan 1984 1555 PST
From: Bruce L. Conroy 
Subject: Use of dBase RESET function.

     Although  there are some funny effects in dBase's RESET 
command I have found it to be 100% reliable under several 
versions of dBase if:

     a)   Any files on the disk to be changed are closed 
(this is merely good practice in any event,)

     b)   The disk is changed, then

     c)   The command RESET (not RESET B) is given.

     In particular, this sequence avoids the following 
anomolies:

     a)   RESET B or RESET B: or any similar command seems 
to have no effect whatever.

     b)   As long as a data file is open, there is an 
unpredicable amount of data in memory, which is not on disk. 
If the disk is changed at this point these data are lost, 
unless

     c)   There is a file of the same name on the new disk, 
in which case, the extra data are stuffed into that file,
resulting in the loss of the integrity of both data files.
**************************************************************