Disk drives deteriorate with time and once in while it happens that a disk block becomes unusable. Depending on the operating system, attempts to read or write such a bad disk block will cause an error message to appear. Under DOS, the following message is generated:
DATA READ ERROR. Abort, Retry, Ignore?
The larger a file is, the larger is also the probability of one day ending up with such a bad block. Since EMME/2 data base files tend to be on the large (or even very large) side, it's not surprising that a bad block occur occasionally there as well. If this ever should happen to you, here is some advice on how to make the best out of a sad story:
If you have a recent backup of the data base (which you always have, don't you?), the solution is easy. Erase the data base file, invoke a disk test utility (such as Norton's DT utility) which flags the bad block as such and prevents it from further use, and finally restore the backup of the data base.
But what if you do not have a recent backup? Or if the bad block appears just as you are in the middle of a backup? In this case, it is important not to attempt to "repair" the block too quickly, but first to find out where within the data base the bad block is located. Since "repairing" the bad block most likely results in a loss of data somewhere, this information is crucial in order to assess what elements of the data base were lost and, if at all, what can be done to salvage the data base.
The easiest method to determine the position of the bad block within the EMME2BANK file depends on the operating system used and the debugging tools which are available. Unfortunately, for a PC running DOS, there is no standard DOS command available to locate the position of the bad block. The following little C-program CHKFILE reads the standard input in blocks of 512 bytes and prints the byte offset for each block read:
main() { /* CHKFILE.C - use Turbo-C to compile */
char buf[512]; long l=0,i;
while((i=_read(0,buf,512))>0) printf("%ld\\n",l+=i);
}
When this program is called with the command "CHKFILE <EMME2BAN", it will read the data base file. The last number printed before the disk error message appears is the needed byte offset of the bad block.
Now that the position of the bad block within the file is known, the output of the "dim" command in the main menu and of the "list file directory" in module 1.11 are needed. Once all this information is known, call us (or even better use telefax) at INRO Consultants or the EMME/2 Support Center for assistance. We can then determine where exactly in the data base the damage has occurred (such as a particular scenario or matrix) and suggest ways how to bring the data base back to normal with minimal data loss. Of course, there is no guarantee that the effects of a bad block can always be repaired. But if the above suggestions are followed, chances are very good that most of the data base can be saved.