The Question is:
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.
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.