|
HP OpenVMS Systemsask the wizard |
|
The Question is: When is data in a sharable image that's installed as writable written to disk? I've written a small program that links to a very simple shareable image that's installed as writable. Does a write to the sharable remain in memory until some significant condition is met to force the new data to be flushed to the sharable image file on disk? Is there any VMS command that allows me to monitor disk I/O on the shareable image file? The Answer is : In short, no. You cannot control when data is written, what order it is written or monitor when it occurs. Shareable image writable data is managed by the virtual memory paging mechanism, so there is no direct means for controlling or observing its behaviour. Indeed, OpenVMS does its very best to avoid writing the data out to disk -- caching data in host memory (for reasons performance) is a goal of the OpenVMS virtual memory management subsystem. If you terminate all processes that have mapped the shareable image, and uninstall the image, then OpenVMS will (eventually) flush the underlying global section(s) out to disk. Writable global sections can be very fast, but one of the costs of that speed is loss of direct control of the data. If you need that level of control, then don't use a writable shareable image. Instead, you should create a writable section yourself ($CRMPSC) and request updates when required ($UPDSECW). But note that this is potentially an expensive operation, as it involves selective flushing of the modified page list by SWAPPER. Again, this is a speed/control tradeoff. If you were to implement complete control over the time and sequence of updates to disk, you would find your code would be no faster (and probably much slower) than using RMS files with global buffers - since that is essentially what RMS does for you! The OpenVMS Wizard strongly discourages the use of writable shareable images. Why? While these are and can certainly be functional, this coding technique often leads to maintenance and support and upgrade problems -- position-dependent constructs tend to be far more difficult to support than position-independent constructs. The OpenVMS Wizard would strongly encourage the use of RMS Global Buffers or of global sections -- and would particularly encourage using position-independent coding constructs. Details of global sections and of example code are available at the Ask The Wizard area. Yet easier and cluster-capable is the RMS global buffer mechanism -- RMS global buffers provide cluster-wide data coherency, and performance. (By the time you write and debug your application -- and deal with the cache coherency and interlocking -- you might have been better off with RMS or middleware.) For various related coherency and caching and interlocking discussions, please see Ask The Wizard topics (1661), (2681), (6984) and (7383).
|