|
HP OpenVMS Systemsask the wizard |
|
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.
|