Memory mapping is a file access technique that works very well under Unix. Under Windows, it only makes sense in read-only applications, and even there, the "local copy" option (covered in a subsequent topic) makes more sense. So it is for all practical purposes only of interest under Unix. The concept is to map a disk file onto a memory address space, such that it can be accessed via memory operations rather than disk operations. The file doesn't have to fit entirely in memory, because the demand paging system (otherwise associated with virtual memory) takes care of swapping pages in and out of memory as needed.
It may appear that this is hardly different that ordinary disk caching, in which frequently accessed disk blocks are held in memory to minimize physical disk accesses. However, there is significant performance difference between accessing a cached disk record via a disk service call and accessing a memory record. Disk service calls require a context switch from user to supervisor mode, even if the data is in cache, whereas memory access calls do not. Such context switches are relatively expensive operations, being perhaps hundreds of times slower than ordinary instructions. So even though reading a disk record from cache and reading the equivalent data directory from memory may both appear to be "lightning fast", the difference can become significant when you have a lot of little disk accesses.
If memory mapping is so wonderful, you might ask why we don't just use it all the time. The answer would be that it can cause memory to be used inefficiently, which can have an adverse impact on the system performance. The recommendation would be to only use memory mapping with reasonably small files that are heavily accessed in specific programs. Good candidates would be any custom (non-ISAM) index files, or any small file whose records are accessed multiple times in a particular program. (ISAM files are not generally good candidates except perhaps in certain individual programs and when the files are not too large, because there is no convenient way to map the index without the data.)
The worst candidates examples are large files that are accessed sequentially or sporadically, with little repetitive access to the same records. For example, it would be a bad idea to memory map a customer master file probably in the customer maintenance program. Such a program is not likely to be disk-bound, and the amount of memory spent mapping the file would be better spent on other uses, like ordinary disk caching
Memory mapping must be activated within individual programs, and applies only to files opened after the memory mapping option is turned on, so in addition to identifying heavily accessed files, you would need to identify specific programs that were disk-bound in order to benefit from it.
Memory mapping is activated within a program using xcall ASFLAG,16. Once this call is made, any file subsequently opened within that program (other than for sequential access) will be memory mapped. The implementation therefore consists of inserting a subroutine ASFLAG,16 into selected programs just prior to opening the file(s) that you want to memory map. You can either rearrange the file opens to put the one(s) you want to memory map last, or you can insert a subsequent XCALL ASFLAG,0 to clear the memory map flag after the intended files have been opened. No other changes are needed in the program; A-Shell will automatically convert the relevant disk operations to memory operations for you.
It is safe to allow a mixture of simultaneous memory-mapped and traditional I/O to any given file under Unix.
