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 disk. This is done for two reasons: to allow current information to be accessed by other concurrent processes, and to ensure that the file will be accurate should the program die suddenly without closing the file (e.g., when a machine's power goes out or the operating system crashes). Note that a Vision file is really only at risk of being damaged 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, particularly on Windows systems. However, using this option means that the file is at risk from the time the first update is made until the time the file is closed. Should the machine die during this period, the file will almost certainly be corrupt. To mitigate this issue, 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 somewhat limits the opportunities in which 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, 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).