Feature request: add missing SQL DML statements (INSERT, UPDATE, DELETE, DECLARE CURSOR, OPEN, CLOSE, FETCH)

[allieseb]

Context

TypeCobol already has excellent SQL parsing support with 14 statement types in TypeCobol/Compiler/Sql/CodeElements/Statements/ (SELECT, COMMIT, ROLLBACK, CONNECT, TRUNCATE, DROP TABLE, LOCK TABLE, etc.).

However, the most common SQL DML statements used in COBOL programs on z/OS with DB2 are currently missing from the parser:

Missing statements

Statement	Usage in COBOL/DB2	Priority
INSERT	EXEC SQL INSERT INTO table VALUES (:host-var) END-EXEC	High
UPDATE	EXEC SQL UPDATE table SET col = :host-var WHERE ... END-EXEC	High
DELETE	EXEC SQL DELETE FROM table WHERE ... END-EXEC	High
DECLARE CURSOR	EXEC SQL DECLARE cursor-name CURSOR FOR SELECT ... END-EXEC	High
OPEN (cursor)	EXEC SQL OPEN cursor-name END-EXEC	High
FETCH	EXEC SQL FETCH cursor-name INTO :host-var END-EXEC	High
CLOSE (cursor)	EXEC SQL CLOSE cursor-name END-EXEC	High

Why this matters

These 7 statements represent the core of embedded SQL in COBOL programs:

• INSERT/UPDATE/DELETE are the basic DML operations — virtually every COBOL batch program that interacts with DB2 uses at least one of them.
• Cursor operations (DECLARE CURSOR, OPEN, FETCH, CLOSE) are the standard pattern for processing multi-row result sets in COBOL. This is the most common DB2 access pattern after single-row SELECT INTO.

Without these, EnableSqlParsing = true only covers a subset of real-world COBOL/DB2 programs. Tools that rely on TypeCobol's AST for static analysis or code navigation cannot see these statements, which limits their usefulness for SQL-related checks (e.g., detecting cursor usage patterns, analyzing DML coverage, building CRUD matrices).

Use case

I'm building Triangulate, a multi-language SAST tool that uses TypeCobol as its COBOL parser. Adding these statements would enable:

• CRUD matrix generation: mapping which programs INSERT/UPDATE/DELETE/SELECT which tables
• Cursor usage analysis: detecting DECLARE CURSOR patterns (performance implications vs SELECT INTO)
• SQL injection detection: analyzing whether host variables in DML statements come from validated sources

Proposed approach

Following the existing pattern in Compiler/Sql/:

1. Add CodeElements/Statements/InsertStatement.cs, UpdateStatement.cs, DeleteStatement.cs, DeclareCursorStatement.cs, OpenStatement.cs, CloseStatement.cs, FetchStatement.cs
2. Add corresponding nodes in Nodes/
3. Extend the SQL scanner/grammar to recognize these statements within EXEC SQL ... END-EXEC blocks
4. Register them in SqlCodeElementBuilder.cs

I've implemented this in my own fork for the bridge layer and would be happy to contribute a PR if the team is interested.

Environment

• TypeCobol version: latest develop branch
• Target: IBM Enterprise COBOL 6.x with DB2 for z/OS