COMMIT Statement

General Format

COMMIT TRANSACTION

General Rules

1. When this statement is executed, all locked records owned by the current run-unit are unlocked.
2. COMMIT also causes a request to be made to the host operating system to flush all buffers to disk. The exact effect of flushing disk buffers depends on the host operating system. Some systems do not ensure that buffers are fully flushed when the COMMIT verb finishes. For example, UNIX only schedules a flush, which occurs over the next few seconds. VAX/VMS already flushes after each write (except for locked files).
3. You can prevent the buffers from being flushed to disk by using the FLUSH-ON-COMMIT line in your runtime configuration file.
4. The function of COMMIT depends on whether or not it ends a transaction. The following rules describe how transaction management operates with Vision and relative files. For other file systems linked with the runtime, each system's native mechanism for transaction management is invoked. See the Acucorp interface document for the specific file system for more details.
5. When ROLLBACK is enabled in the FILE-CONTROL entry for a file, the record and file locking rules are extended for that file. Every record updated as part of a transaction is locked until that transaction is committed or rolled back. The COMMIT verb removes these locks. Record locks applied when the file is read are kept until the end of the transaction, if ROLLBACK is enabled for the file.

   Record locks are held during a transaction in order to prevent another process from updating the records in a way which might make rollback impossible. Note, however, that a record may be deleted during a transaction, and another process is allowed to write a record with the same record key to the file. If this happens, and duplicates are disallowed on that record key, then the ROLLBACK will fail with a duplicate key error.

6. During a transaction involving Vision or relative files, a CLOSE of a file that is locked, or that has locked records, is postponed until the transaction is committed or rolled back.

   If the same physical file is opened again within the transaction, even if a different logical file (different SELECT) is used, the postponed CLOSE is canceled. Note that the mode of the original OPEN is retained. (For example, if the file were originally OPEN I-O, and if the CLOSE were canceled, then an OPEN OUTPUT on the same file within the same transaction would not empty the file.) When the second OPEN is encountered, the file position is reset to the beginning so that a READ NEXT would read the first file in the record. CLOSE is handled in this special way so that record locks are held--these locks are necessary for rollback.

7. COMMIT locks the log file, checks its integrity, then writes the changes and unlocks the log file. The log file is specified with the filename_LOG or LOG_FILE configuration variable. See Multiple Log Files in the ACUCOBOL-GT User's Guide for more information.
8. There is an implicit COMMIT before a STOP RUN or before the end of the program, unless the STOP_RUN_ROLLBACK configuration variable is set to 1. Then, an implicit ROLLBACK occurs.