ISAM-A Pros and Cons
Updated May 2021
ISAM-A is an all-around better system than ISAM. It's faster, more robust, offers more features, and is easier to use. On the ease-of-use front, particularly noteworthy is the fact that all of the index maintenance is automatic. In other words, when you create or update a record, all keys are updated for you. It is even possible to add and delete indexes to existing files, without even recompiling the programs that access them (provided you don't delete an index that is being used to access the file). On a similar note, the ISAM-A ISMUTL utility allows you to verify and rebuild indexes without having to provide the index configuration specs or dump and reload the file. In ISAM 1.x, all index operations must be manually and explicitly handled by the program.
The above mentioned advantages notwithstanding, ISAM-A does have a couple of limitations which can impede the easy migration from ISAM 1.x. The most significant is that ISAM-A does not allow synthetic keys. In other words, there will always be one key entry in each index for each record, and it will match the data in the record. In ISAM 1.x, it was possible to add multiple keys for a single record in a single index, or to have data records with no keys, or for keys to be formatted differently than in the data record. For example, for an alphabetic name index, in ISAM 1.x, you could have the data in upper and lower case but fold the keys to upper case. In general, these kinds of issues can be dealt with during conversion by a combination of adding fields to the data record to match the desired keys, and/or by creating additional files just to use the indexes (i.e. effectively ignoring the data). Note that in the latter case, although it is possible to store record numbers and to access ISAM-A files by record number, this should be highly discouraged. Instead, if you want to create a synthetic index, link it to the main file by means of field which is a unique key to the main file.
One scenario in particular to be aware of is when a particular index only needs to contain keys for a small subset of the overall records. For example, consider a product file indexed by SKU, but a small subset of products also have an alternate product # that you want to index on. If you create a secondary index on the alternate #, you may end up with an index that has thousands of empty keys (for all the products that don't have an alternate #). That wouldn't be a problem for adds, lookups, or sequential reads, but it would be inefficient for updates and deletes (since locating the key would require scanning a very long chain of duplicates). You may be able to hack around the problem by populating the empty keys with dummy values that can be easily distinguished from real ones. But ISAM 1.x probably has the advantage in this kind of scenario, since you can add just the keys you need.
The other limitation relates to non-standard manipulation of the data file. Although ISAM 1.x provides operations for adding and deleting records, some developers either bypassed them or extended them, taking advantage of the fact that the data files were accessible as ordinary random files. In such case, you may need to rethink your file design. It is worth noting, though, that these "limitations" of ISAM-A are essentially the same kinds of "limitations" you will find in any relational database, which are the "price" for gaining access to many advantages, such as the ability to have a single, generic index verification/rebuild utility that works on all files (as opposed to a motley collection of specialized rebuild programs that would be needed to handle all these "tricks" under ISAM 1.x).
