The MASS-UPDATE option of the OPEN verb can provide significant performance benefits under some circumstances. Several issues come into play, however, when you are deciding whether or not to use MASS-UPDATE. Currently, the MASS-UPDATE clause affects only the systems that use Vision.
Normally, when Vision updates a file, it immediately writes all of the changed information to the disk. This is done for two reasons. One is to allow current information to be accessed by other concurrent processes. The other reason is to ensure that the file will be accurate should the program die suddenly without closing the file. This could happen if the machine's power went out or the operating system crashed. Normally, the only time that a Vision file risks being damaged is during an update to the file.
The MASS-UPDATE option changes this strategy. It allows Vision to retain information in memory until the file is closed. This allows Vision to be much more efficient on MS-DOS machines It can result in two or three times the normal file performance. Using this option, however, means that the file will be at risk from the time the first update is made until the time the file is closed. Should the machine die during this time, the file will almost certainly be corrupt. However, Vision writes enough information to disk to ensure that the file can be rebuilt using vutil.
The MASS-UPDATE option also requires that the entire physical file be locked against other updaters because the disk version of the file is not always accurate. This may limit circumstances where MASS-UPDATE can be used.
Generally, programs might use MASS-UPDATE if they heavily update a file. For many such programs, the fact that the file is at greater risk is not really an issue. For example, many posting programs cannot recover from an incomplete run. This is because the program cannot tell where it left off in the process. This is particularly true for programs that update several files at once, because it is usually not clear which file got updated last. For these programs, it is usually necessary to go to a backup of the affected files when the program dies. These programs are obvious candidates for MASS-UPDATE because it does not matter if the files are corrupt after a program failure, since they are just going to be restored from backup. Furthermore, these programs benefit the most from MASS-UPDATE because they do a lot of updating.
Interactive programs, however, make poor candidates for MASS-UPDATE. Usually the volume of updates is low (at least for the time frame the program runs in). Furthermore, interactive programs are often killed or left running overnight by their operators, thus increasing both the risk to the file and the inconvenience of the file lock that MASS-UPDATE implies.
To summarize, then, MASS-UPDATE is appropriate for programs where the implied file lock is useful, the volume of updates is large, and where a system failure would usually require special attention for recovery (either restoring from backup or rebuilding the files).