COBOL COMMIT

The COMMIT statement in COBOL is used for transaction control and ensuring data integrity in database operations.

Overview and Purpose

COMMIT is a crucial statement for maintaining data integrity in COBOL applications that work with databases. It marks the successful completion of a transaction by permanently saving all changes made since the last COMMIT or transaction start. This ensures that related data modifications are treated as a single atomic unit, preventing partial updates that could leave the database in an inconsistent state. Understanding when and how to use COMMIT is essential for building reliable, enterprise-grade applications.

Basic COMMIT Usage

1
2
3
4
5
6
7
8
9
EXEC SQL
    UPDATE CUSTOMER 
    SET BALANCE = BALANCE - :WS-AMOUNT
    WHERE CUSTOMER-ID = :WS-CUSTOMER-ID
END-EXEC
 
EXEC SQL
    COMMIT
END-EXEC

This example shows a basic COMMIT operation after updating a customer balance. The UPDATE statement modifies the database, but the changes remain temporary until the COMMIT is executed. Once COMMIT is processed, the balance change becomes permanent and visible to other programs. This pattern ensures that the database update is properly saved and won't be lost due to system failures or program termination.

Transaction Processing with Multiple Operations

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
EXEC SQL
    INSERT INTO TRANSACTION_LOG
    VALUES (:WS-TRANS-ID, :WS-CUSTOMER-ID, :WS-AMOUNT, :WS-DATE)
END-EXEC
 
EXEC SQL
    UPDATE ACCOUNT_BALANCE
    SET CURRENT_BALANCE = CURRENT_BALANCE + :WS-AMOUNT
    WHERE ACCOUNT-ID = :WS-ACCOUNT-ID
END-EXEC
 
IF SQLCODE = 0
    EXEC SQL
        COMMIT
    END-EXEC
    DISPLAY "Transaction completed successfully"
ELSE
    EXEC SQL
        ROLLBACK
    END-EXEC
    DISPLAY "Transaction failed - changes rolled back"
END-IF

This example demonstrates transaction processing with multiple related operations. The program inserts a transaction log entry and updates an account balance as part of a single logical transaction. If both operations succeed (SQLCODE = 0), COMMIT saves all changes permanently. If any operation fails, ROLLBACK undoes all changes, ensuring the database remains consistent. This all-or-nothing approach is fundamental to reliable transaction processing.

Conditional COMMIT with Validation

1
2
3
4
5
6
7
8
9
10
11
12
PERFORM VALIDATE-BUSINESS-RULES
IF WS-VALIDATION-SUCCESS = 'Y'
    EXEC SQL
        COMMIT
    END-EXEC
    MOVE "SUCCESS" TO WS-RESULT-CODE
ELSE
    EXEC SQL
        ROLLBACK
    END-EXEC
    MOVE "VALIDATION_FAILED" TO WS-RESULT-CODE
END-IF

This pattern shows how to combine business rule validation with transaction control. After performing database operations, the program validates business rules to ensure the data meets all requirements. Only if validation passes does the program commit the changes. This approach prevents invalid data from being permanently saved and maintains business logic integrity alongside database consistency.

Tutorial: Implementing Robust Transaction Management

1
2
3
4
*> Define what constitutes a complete business transaction
*> Example: Transfer money between accounts
01  WS-TRANSACTION-STATE    PIC X VALUE 'N'.
01  WS-COMMIT-POINT         PIC X VALUE 'N'.

1
2
3
4
5
6
AFTER EACH SQL STATEMENT:
IF SQLCODE NOT = 0
    DISPLAY "Database error: " SQLCODE
    MOVE 'N' TO WS-COMMIT-POINT
    GO TO TRANSACTION-CLEANUP
END-IF

1
2
3
4
5
6
7
8
TRANSACTION-CLEANUP.
IF WS-COMMIT-POINT = 'Y'
    EXEC SQL COMMIT END-EXEC
    DISPLAY "Transaction committed successfully"
ELSE
    EXEC SQL ROLLBACK END-EXEC
    DISPLAY "Transaction rolled back due to errors"
END-IF

Practical Exercises

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
PROCESS-ORDER.
    EXEC SQL
        UPDATE INVENTORY 
        SET QUANTITY = QUANTITY - :WS-ORDER-QTY
        WHERE PRODUCT-ID = :WS-PRODUCT-ID
    END-EXEC
    
    IF SQLCODE = 0
        EXEC SQL
            INSERT INTO ORDERS 
            VALUES (:WS-ORDER-ID, :WS-CUSTOMER-ID, :WS-AMOUNT)
        END-EXEC
    END-IF
    
    IF SQLCODE = 0
        EXEC SQL COMMIT END-EXEC
    ELSE
        EXEC SQL ROLLBACK END-EXEC
    END-IF.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
TRANSFER-FUNDS.
    EXEC SQL
        UPDATE ACCOUNTS 
        SET BALANCE = BALANCE - :WS-AMOUNT
        WHERE ACCOUNT-ID = :WS-FROM-ACCOUNT
    END-EXEC
    
    IF SQLCODE = 0
        EXEC SQL
            UPDATE ACCOUNTS 
            SET BALANCE = BALANCE + :WS-AMOUNT
            WHERE ACCOUNT-ID = :WS-TO-ACCOUNT
        END-EXEC
    END-IF
    
    IF SQLCODE = 0
        EXEC SQL COMMIT END-EXEC
        DISPLAY "Transfer completed"
    ELSE
        EXEC SQL ROLLBACK END-EXEC
        DISPLAY "Transfer failed"
    END-IF.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
BATCH-PROCESS.
    PERFORM VARYING WS-COUNTER FROM 1 BY 1
        UNTIL WS-COUNTER > WS-TOTAL-RECORDS
        
        PERFORM PROCESS-SINGLE-RECORD
        
        IF SQLCODE = 0
            ADD 1 TO WS-SUCCESS-COUNT
        END-IF
        
        IF WS-SUCCESS-COUNT = 100
            EXEC SQL COMMIT END-EXEC
            MOVE 0 TO WS-SUCCESS-COUNT
            DISPLAY "Checkpoint: 100 records committed"
        END-IF
    END-PERFORM.

Advanced COMMIT Strategies

Checkpoint Processing

In long-running batch processes, implement checkpoint processing by committing after processing a certain number of records. This prevents losing all work if the program fails partway through and allows for restart capability. Balance the checkpoint frequency between performance (fewer commits) and recovery time (more frequent commits).

Distributed Transaction Coordination

When working with multiple databases or systems, coordinate commits across all participants using two-phase commit protocols. This ensures that either all systems commit their changes or all roll back, maintaining consistency across the distributed environment.

Performance Considerations

COMMIT operations involve disk I/O and can impact performance. Group related operations into logical transactions and commit at appropriate intervals. Avoid committing after every single operation in high-volume scenarios, but don't make transactions so large that they consume excessive resources or increase lock contention.