There are other MODE DEBUG numbers but you should not experiment with them. But this one is worth documenting because it is for self-protection against network failures.
The standard mode of operation is MODE DEBUG 2. We tell you this so you know what to set it back to if you ever use 34 and want to revert. Of course, the other way to revert is to get everyone out, close the data base, and then remove the MODE DEBUG 34 and let people come back in.
Every once in a while we get the dreaded phone call that goes something like this: "My applications have been running perfectly for the last several years and now all of a sudden everything is failing." Of course everyone is pointing the finger at the developer(s), and in turn it gets pointed at us. So we decided to do something about it, and here is what we did:
Anomoly Detection
Every tree and data block that we output to mass storage contains its own relative location as part of its data. So that when we read a block we can check the block we read to make sure that it is the one we asked for. If it is not, that is what we call an anomolyand that is a network failure. That is, we asked to read block X and we did not get back block X. It happens.
To turn on anomoly detection the command is MODE DEBUG 34. To turn it on for everyone, place this command in your CONFIG
file or in your startup Application Procedure
. Then, this is what will happen:
For every user that has encountered the MODE DEBUG 34, one, and possibly two files will be generated:
XXXXUUU.log -Logs OPENs and messages
XXXXUUU.dat -Logs anomoly data
where XXXX us the first four characters of your data base name,
and UUU is the user number.
These files are generated in the temp directory
. Everyone gets a .LOG file, but a .DAT file only occurs if an anomoly has happened. That is, if you see a
.DAT file, that is the proof of a network failure. Send the content of these files to us for further interpretation.
