HP OpenVMS Systems

C and RMS writes, I/O caching, flushing?

» close window

The Question is:

 
Hello,
I am writing a C program in OpenVMS. In my program, I have to open a
 file(file_no = fopen("SEQNUM.DAT", "r+")) and update it frequently in order to
 keep track the sequence numer.
 
As for better performance, I try to avoid "fflush(file_no)". However, I find
 that if the program is closed by stop/id=xxx, the opened SEQNUM.DAT will not
 be updated and it is blank.
 
Is there any option value can be set to "fopen" in order to ensure the lastest
 update to the file will be output to it for the abnormal close of the program?
 
Thanks a lot.
Helen
 

The Answer is :

 
  Please see the OpenVMS FAQ for how to open a file for shared access,
  an approach which may well address some of your local requirements.
 
  OpenVMS Alpha has been modified in more current releases to better
  flush the contents of open files upon process deletion.  In older
  releases, you can perform fflush and fsync calls when programming
  in C.  With RMS calls, $flush and related can be used.
 
  You can also cache the index value in a lock value block.
 
  As for ensuring the value, you will have to flush it to disk.
  There can be multiple layers of caching, including caches in
  controllers and storage devices -- flushing the data to disk is
  a comparatively open-ended question, and the implementation can
  and does depend on specific requirements.
 
  DECdtm or similar can be used to ensure consistency across multiple
  files, as can RMS journaling.  If you require the data be written
  to disk, you will want to use fflush and fsynch, or RMS calls.
  Better, use indexes that are derived from a GUID value or other
  such approach, as these do not require sequential issuance.
  Alternatively, use RMS calls to locate the last index value in
  use, and compare it with the largest index; this will allow the
  application to self-heal.
 
  Databases are also commonly used for this, as well -- like DECdtm
  and journaling, a relational database can be used to unite the
  database write(s) associated with the operation and the index
  incrementation operation into a single transaction.
 
  Without additional application requirements, the OpenVMS
  Wizard would initially consider a GUID-based approach, or
  the write and the use of $flush (or fflush and fsync) and
  the recovery-related logic discussed above.
 
  Use of STOP/ID triggers a $delprc call and a hard exit and
  can, as documented, result in inconsistent application states
  and/or data loss.
 
  Prior to the enhancements mentioned above, $delprc is akin
  to a power failure or other similar condition, and can cause
  information or EOF marks at the end of the file to not be
  flushed out.  Cache synchronization is not maintained.
 
  Options here include use of $forcex (or the DCL command
  STOP/EXIT on recent OpenVMS versions such as V7.3-2) or the
  use of interprocess communications; the application-specific
  implementation of an application exit or shutdown command.
  (This can be generalized, of course, and tied into the OpenVMS
  system shutdown and/or network shutdown mechanisms, such that
  the application detects the shutdown and reacts appropriately.)
  Use of fflush/fsync or of $flush or a trasanactional design is
  also available, as well.
 
  For programming information, please see topics including
  (1661), and please see the Programming Concepts manual.
 
 

  

     

     
answer written or last revised on ( 2-AUG-2004 )
     
» close window