The fact that records of SAM and ISAM files are buffered in main memory may result in the loss of updates which were made immediately before file processing was aborted. For ISAM files, this problem can be countered with the WROUT function (see "WROUT function"). However, users should bear in mind that this involves increased time outlay.
If duplicate records (i.e. records with the same key and the same data) are encountered during the recovery of ISAM files, only one record is transferred to the recovery file. This restriction is necessary in order to permit the recovery of ISAM files where block splitting was in progress when file processing was aborted.
If the damaged ISAM file contains several records with the same key(s) but different data, the order in which these records are written into the recovery file may differ from that in the original file.
If the ISAM file to be recovered was encrypted with a crypto password, its encryption attributes are transferred to the recovered file.
If a data block in an ISAM file cannot be recovered (e.g. because internal pointers have been destroyed), this block is written into a separate PAM file. This PAM file is then available to the user, who can attempt to rescue the contents of the blocks which could not be recovered. The file name is S.filename.REPAIR, where “filename” is the file name of the original (damaged) file.
During the recovery of ISAM files, no space is reserved in the data blocks for subsequent extensions.
The time required for the recovery of ISAM files is considerable. In the case of files on private disks, it can become even greater if the user does not provide a recovery file (which already has sufficient storage space allocated).
ISAM files whose index and data sections are stored on different private disks can be recovered only if BUF-LEN=STD/(STD,1) has been defined in the catalog entry.