For engineers tackling the modernization of legacy COBOL systems, handling embedded SQL (EXEC SQL) has always been a persistent challenge.
SlimeCOBOL-ESQL, under development by JAVATEL, is a project that directly confronts this very core issue.
Official page: https://www.javatel.co.jp/ja/resource/slimecobol-esql/
What It Aims to Achieve
A tool that converts EXEC SQL written directly within old COBOL programs to modern forms without changing behavior by a single bit.
- Output targets: Java (JDBC) / Rust (sqlx + typed bind)
- Approach: Bit-exact pathway (rigorously matching behavior)
- Current status: Development and validation phase (final confirmation with actual IBM DB2 planned for the next stage)
Striking "Honesty" and Depth of Validation
What impressed me most after reading this page was the complete absence of vendor-style marketing hype.
From the outset, it states "under development / validation phase" and clearly distinguishes between "what we can prove now" and "what we haven't yet confirmed".
Key achievements demonstrated (as of June 2026)
- Against the independent reference implementation Open-COBOL-ESQL (ocesql), 47 test cases with perfect matches (both output and table state)
- Confirmed that both Java and Rust emitters work with the same intermediate representation (Slot IR)
- Coverage range: SELECT/INSERT/UPDATE/DELETE, cursors, dynamic SQL, NULL indicators, fixed-length PIC X space padding, packed decimals and other legacy-specific behaviors
- Extraction rate of 97.1% and type recognition rate of 95.1% against a publicly available corpus of 146 programs (with the careful note that these do not represent bit-exact conversion completion rates)
Additionally, end-to-end validation has been completed:
- Actual sample programs (INSERTTBL.cbl, FETCHTBL.cbl, PGMOD2/3, etc.) executed on PostgreSQL, confirmed to match the reference implementation at the byte level
- Date and timestamp precision at the microsecond level, and deterministic columns other than CURRENT_TIMESTAMP also match
- Two fidelity bugs found during validation were fixed, with regression tests kept green
How Validation Works
Extractor (S1.5) → Slot IR → Java/Rust emit → PostgreSQL execution → differential comparison against ocesql reference implementation—a multi-layered validation approach.
A thoroughly engineer-like methodology of "crushing issues with volume."
Still Ahead (Realistic Awareness of Limitations)
- SQLCODE behavior, dialects, and locking conduct with actual IBM DB2 remain unvalidated
- Does not claim complete coverage of large-scale production code; instead follows a per-PoC validation approach
- Delivery format still undecided
Final Assessment
To be honest, this is a page that "genuine engineers have built".
Rather than flashy sales copy, it reads like engineers speaking to fellow engineers—"we've validated this far. Want to run a PoC together?"—in modest and sincere tones.
Combined with the SlimeCOBOL body's COBOL→Java/Rust transpiler, it could become a quite powerful asset in legacy mainframe modernization projects.
For those involved in COBOL modernization or wrestling with database access portions of legacy systems, I strongly recommend taking a look.
References
- SlimeCOBOL main: javatel.co.jp
- Validation date: Information as of June 10, 2026
I found myself appreciating the attitude of respecting legacy systems while carefully bridging them with modern technology.