ISAM is the most highly developed access method in BS2000. It offers a large number of convenient features which are achieved at the cost of increases in the memory overhead and path lengths. For reasons of compatibility and protection against obsolescence, it often happens that files are kept as ISAM files even though their type and application make them typical SAM files (e.g. source programs). Since it is very easy to convert SAM to ISAM, this is not necessary.
However, ISAM is not a pure keyed access method. ISAM functions best with a set of accesses where a keyword is followed by a series of sequential accesses (indexed sequential). The distribution and frequency of the keys and in particular whether they are changed during the life of a file, all influence the number of physical I/O operations required to read a particular record. ISAM should only be used if one or more of the following characteristics are required:
The advantages of ISAM are:
keyed accesses which are largely independent of the distribution of the keys and of any changes which may have been made
efficient sequential reading following keyed access
shareability even when updating
an acceptable deterioration in access performance even after a very high number of single-page extensions
Due to the introduction of ISAM pools, the index areas (partly also data areas) are held in the virtual memory. This makes possible a sharp reduction in the physical I/O operations with indexed-sequential accesses, and leads to marked runtime reductions.
BS2000 automates and optimizes the creation of buffer areas (NK-ISAM pools) for NK-ISAM files which are opened with SHARUPD=YES. NK-ISAM pools then no longer need to be configured.
NK-ISAM permits the use of secondary keys. If, besides the primary key, additional selection criteria per logical record are maintained in the form of secondary keys, a given set of data can be searched and processed in a number of different ways.
Compared to an application without secondary keys, the resource requirements are slightly higher as long as the “index tree” is not changed; if it is changed (e.g. GET-ELIM, GETKY-ELIM, STORE), resource requirements increase sharply.