ISAM-A is an all-around better system than ISAM. It's faster, more robust, offers more features, and is easier to use. One significant feature is the ability to go backwards (e.g. GET'PREVIOUS) as well as forwards through the indexes. 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.0, 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.0. 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.0, 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.0, 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.

The other limitation relates to non-standard manipulation of the data file. Although ISAM 1.0 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. A simple example would be a case where, in order to go beyond the 512 byte record size limit in ISAM 1.0, you would add a "side-car" data file which essentially shared an index with the main data file. This kind of situation is easily dealt with during conversion by just combining the side-car files into one, larger, data record. In more exotic cases, 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.0).