Oninit® BLT — What the 4GL Actually Does to Your Database

You already know the schema. You have the table definitions, you can read the SQL output of dbschema, and you can grep the 4GL source for SQL. What you don't have is a single, consistent answer to which functions touch which tables, under what control-flow conditions, inside which transaction scopes — and you don't have time to build that answer one screen at a time. BLT is the tool that does it.

Schema-aware binding

BLT loads your CREATE TABLE / CREATE INDEX / CREATE CONSTRAINT DDL up front, then walks the 4GL and SPL source emitting database-operation facts. Every embedded INSERT / UPDATE / DELETE / SELECT is bound back to the actual table it touches, with the column list and the WHERE predicate carried along. Operations that don't match the loaded schema surface in review.md as unresolved bindings — so schema drift between source and DDL doesn't quietly inflate confidence.

DML rule extraction

The control-flow analyser walks the IF / CASE / WHILE structure around every DML statement and emits the enclosing predicate as a business rule. The canonical IF SQLCA.SQLCODE != 0 post-condition pattern is captured the same way — as a rule attached to the INSERT / UPDATE / DELETE it guards. The result is a machine-readable record of every "this insert only happens if X" and "after every update check Y" rule in the application, traceable back to the source line.

Transaction scope recovery

BEGIN WORK / COMMIT WORK / ROLLBACK WORK markers are matched within each function, and BLT emits one transaction claim per scope listing the DML operations enclosed. Nested transactions and bare-DML patterns (operations outside any explicit transaction) are distinguished so you can see at a glance which functions rely on the session's autocommit semantics.

Multi-source corroboration

When you configure both the 4GL source and the compiled binary as inputs, BLT runs the binary analyser in parallel and extracts the SQL strings the compiler baked into the executable. Operations that appear in both source and binary — matched on (table, operation) — carry an explicit corroboration marker on the finding's payload. Same-table SELECTs from the binary don't corroborate source INSERTs; the match is operation-specific.

Confidence on every claim

Every finding carries a confidence level — High, Medium, Low, Unknown — with explicit downgrade rules. A database operation whose table can't be bound to the loaded schema drops one notch. Anything inferred without direct evidence is flagged. Low-confidence and unresolved claims surface in a separate review.md for human attention instead of mixing silently into the main spec.

Deterministic by design

Identical inputs, identical configuration, and identical code version produce byte-identical output. Re-running BLT doesn't introduce salt-style drift — the same spec.json comes out every time, which is what makes the output safe to diff in CI when the schema or the application changes.

Next

The Worked Examples landing page walks through the corroboration lift, the schema binding workflow, and the STRICT-mode policy on stripped binaries.