HP OpenVMS Systems

Writable Shareable Images? (COMMONs)

» close window

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).
 
 

  

     

     
answer written or last revised on ( 17-JUN-2002 )
     
» close window