Acu4GL and Record Locking

Acu4GL provides semi-automated ways to handle transaction logging based on the setting of the COMMIT_COUNT environment variable. You can also directly alter your source code to deal with this issue. Individual users determine how much work they wish to do to conform to the Oracle transaction management system by choosing the method that best fits their needs and resources. The following methods are listed in order of increasing amount of work:

COMMIT_COUNT = 0 (Default)

When you set this variable to zero (0), the run time system tracks the number of logical locks that are currently in effect. When the number of logical locks reaches zero, the run time system assumes that a transaction is complete and issues a COMMIT statement.


When you set this variable to a nonzero value, the run time system tracks the number of WRITE, REWRITE, and DELETE operations, until the value of COMMIT_COUNT is reached, at which time the run time system issues a COMMIT statement. The READ, START, and READ NEXT operations do not count toward this total, because the run time system is tracking data-altering operations rather than logical record locks. The disadvantage of this method is that when a COMMIT is issued, any record locks held by the run time system are released.


No commit is issued by the Connector. When COMMIT_COUNT is set to 1, two alternate ways to perform a commit or rollback are available:

  • Call your Oracle query tool with COMMIT WORK or ROLLBACK WORK.
  • Use the COBOL verbs COMMIT and ROLLBACK, available in Acu4GL for COBOL.

COMMIT_COUNT is set to -1 automatically when you use the transaction management facilities available in ACUCOBOL-GT. A COMMIT WORK is, however, issued on exit from the run time system (for example, on execution of a STOP RUN).


This method forces a COMMIT to be sent to Oracle. It can be used in conjunction with other modes of COMMIT handling. For non-ORACLE files, this is equivalent to the UNLOCK ALL verb.

Explicitly Coded Transactions

This method provides the greatest flexibility in that transactions are specifically tailored for the user's application. This method also requires the most work for traditional COBOL programs in which transaction modules may not be clearly defined.