We have had a number of instances recently where checking the ROCK for a given ISAM file returns a number of allocated records. However, when this file is opened and then read, there are no records found/listed, or the number found is less than reported via the ROCK. Dumping the file, also finds no records or less than reported.

It may be a 'red herring' but these 'ghost' records might be causing further problems when accessing the file, but i can't be sure or quantify this.

1) Is it that the file is corrupted in some way preventing the access to the records, or is it that the ROCK is corrupted generating a false allocation count?
2) Which allocation count should be the more reliable?
3) Is it possible to clear the ROCK if that is the incorrect count?

I have created a one time link to an example of such a case - https://send.firefox.com/download/905553b696d1fda2/#cYRLiIUt40L6e7himc_9rQ

I may need to scrape some cobwebs off in order to get in the ISAM frame of mind...

In general with ISAM files, we trust the IDA file more than the IDX. You can read the IDA just like a regular data file, with the only complication being how to detect which records are in use and which are free. Fortunately, as long as your real data is non-null in the second byte, you can determine whether a record is free (or more precisely, if it is in the free chain) by testing the second byte for zero. The reasoning here is that the free records are linked in a chain, with the 1st 4 bytes being the link to the next record in the chain (using filebase 1). The byte order is AMOS/M68, i.e. 2301, so as long as their are fewer than 2**24 records in the file, we can count on the high byte (position 2) being zero, whereas for normal data, we can probably count on the opposite.

So I guess my first step would be to scan this IDA and count up the valid records. If that doesn't match the ROCK, then I would trust the IDA and assume the ROCK got corrupted. qx

In terms of fixing it, the usual approach would be to use ISMDMP to dump the file and then ISMBLD to rebuild it. (It looks to me like this is an original-format file, i.e. ISAM 1.0 rather than ISAM 1.1, and according to the update counter, there have been over a million updates, so perhaps it's about time for a rebuild.) But, the one weakness of the dump/recreate/load approach is that it relies on the index to dump the records. If the index is corrupt, you may end up losing records that would otherwise be recoverable from the IDA.

So if your scan suggests that there are valid in-use records that don't appear in the dump, then it may be better to copy the original IDA to another data file, then recreate the IDX/IDA pair, then reload it by scanning the saved data file and using the ISAM #ch calls.

OK, thanks. I'll investigate further on that basis.