COBOL and DB2

A COBOL program accesses a DB2 relational database by writing embedded SQL statements directly in the PROCEDURE DIVISION, delimited by EXEC SQL and END-EXEC, which a preprocessor called the DB2 precompiler scans and replaces with calls to the DB2 runtime before the modified source is handed to the standard COBOL compiler. Host variables, ordinary COBOL WORKING-STORAGE fields prefixed with a colon inside SQL statements like WHERE CUST_ID = :WS-CUST-ID, let SQL statements read values from and write results into normal COBOL data items, bridging the relational, set-based world of SQL with COBOL's record-oriented procedural style. The DATA DIVISION also typically includes an EXEC SQL INCLUDE member-name END-EXEC statement pulling in the DCLGEN-generated host variable structure that mirrors a table's column definitions, ensuring the COBOL field lengths and types stay synchronized with the actual DB2 table schema.

Every embedded SQL statement implicitly populates the SQL Communication Area, SQLCA, a structure the precompiler automatically declares, and the program must check the SQLCODE field within it after each SQL statement to determine success or failure. An SQLCODE of zero means the statement succeeded, +100 means no rows were found to satisfy a SELECT or FETCH, and negative values indicate genuine errors such as -803 for a duplicate key violation or -305 for an unexpected null value fetched into a non-nullable host variable, and disciplined programs code a shared paragraph like 9999-CHECK-SQLCODE, performed after every EXEC SQL block, to branch on these values consistently. Because SQL operates on sets and can implicitly return null, host variables that might receive a null column value require a paired indicator variable, declared as a COBOL PIC S9(4) COMP field referenced with a colon like :WS-CUST-NAME:WS-CUST-NAME-IND, which DB2 sets to -1 when the actual column value was null.

Because COBOL processes data one record at a time while SQL SELECT statements naturally return sets of many rows, a program that needs to iterate over multiple result rows must declare a cursor with EXEC SQL DECLARE CURSOR-NAME CURSOR FOR SELECT ... END-EXEC, then explicitly OPEN the cursor, repeatedly FETCH one row at a time into host variables inside a PERFORM UNTIL loop checking SQLCODE for +100 as the end-of-data signal, and finally CLOSE the cursor once processing completes. This pattern, structurally similar to the AT END loop used for sequential file reads, lets a COBOL batch program page through thousands of DB2 rows, such as every overdue account in a billing cycle, one record at a time while applying normal procedural logic like conditional updates or accumulation between fetches. Cursors can also be declared FOR UPDATE OF column-list, which allows a subsequent WHERE CURRENT OF CURSOR-NAME clause on an UPDATE or DELETE statement to modify exactly the row most recently fetched, without needing to re-specify its full key.