Afunana's quality analysis targets the costliest, best-hidden class of defects: the ones that produce no error message. A cross-program parameter mismatch, a MOVE that silently truncates an amount, a file read whose status is never checked, an exception quietly swallowed -- these do not crash. The batch chain "runs clean" and produces wrong results. Afunana catches them deterministically, on every build.
Results appear in the web UI and as VS Code extension diagnostics.
Why "Silent Failure"
Manual review and testing are good at finding code that breaks loudly. They are poor at finding code that works until the day it doesn't: the field that truncates only when a value finally exceeds its capacity, the interface mismatch that reads adjacent memory only for certain record layouts, the exception handler that hides the one error you needed to see. These defects survive years in production and surface as data corruption, reconciliation breaks, or a wrong number on a regulatory report. Afunana's checks are engineered specifically to find them before they cost money.
How the Analysis Works
The analysis is purely deterministic -- no AI, no machine learning, no heuristics. It parses the source, resolves data definitions with a real data-division parser (PIC / COMP-3 / OCCURS / REDEFINES byte math for COBOL), and applies exact structural rules. The same source always produces the same findings, and every reported finding reflects an actual structural fact in the code -- there are no probabilistic false positives.
Checks run as a collection artifact during the build, after parsing has produced the structural model. See Build Process. Two checker families exist: the COBOL/RPG family for IBM i and the PL/SQL family for Oracle. Severities are set per customer via a check catalog.
COBOL / RPG Checks
The COBOL catalog defines checks in three UI groups: Interface Checks, Control Flow, and Data Integrity.
Interface Checks -- Cross-Program Contract Mismatches
The most important family. Interface checks compare each CALL statement to the called program's LINKAGE SECTION to verify that caller and callee agree on the interface contract -- the single hardest defect to find by eye because the two halves live in different source members.
Interface checks work across COBOL-to-COBOL, RPG-to-RPG, and COBOL-to-RPG call boundaries, and the byte-size comparison uses the real data-division parser (PIC, COMP-3, OCCURS, REDEFINES) rather than string length.
Example:
Data Integrity -- Silent Truncation and Dead Data
This family catches silent data loss: a transfer that moves a value into a field too small to hold it (losing characters, high-order digits, or decimal precision with no runtime error), and fields that are defined but never used.
Data-truncation example:
Any value in WS-TOTAL-AMOUNT exceeding 99,999.99 is silently truncated. COBOL produces no runtime error; the data simply disappears. The field works correctly until the day a value exceeds the smaller field's capacity -- and in financial systems that truncation can propagate through batch cycles before anyone notices.
Control Flow -- Unsafe Logic Paths
Control-flow checks detect structural risks in a program's logic. All four ship off by default -- they are advisory patterns that vary by coding standard, so administrators enable the ones relevant to their site.
The read-without-status-handler check is the quintessential silent failure: the read fails, no handler runs, and the program processes whatever happened to be in the record area.
PL/SQL Checks (Oracle)
For Oracle collections, a PL/SQL-aware checker family applies the same deterministic, no-LLM discipline to packages, procedures, functions, and triggers. It covers 14 rules, targeting the silent-failure patterns specific to PL/SQL:
- Swallowed exception -- empty
WHEN OTHERS(or a handler that discards the error), a common way an Oracle failure disappears - DML without WHERE -- an UPDATE or DELETE with no WHERE clause, i.e. a whole-table modification
- Dynamic-SQL injection -- unbound user input concatenated into dynamic SQL
= NULL-- a comparison to NULL that is always false rather thanIS NULL- Hardcoded credentials -- secrets embedded in source
- Commit in loop -- a COMMIT inside a loop, risking partial work and ORA-01555
SELECT *in production code- High cyclomatic complexity
- Dead private subprogram -- a private procedure/function never called
- ...and further rules in the same vein.
As with COBOL, each PL/SQL rule carries a per-customer severity and its findings flow into the same reports, program pages, and diagnostics.
Per-Customer Severity Catalog
Every check has one of three severity levels, tuned per customer:
| Setting | Behavior |
|---|---|
| Error | Finding displayed, program flagged for review. Red indicators in the UI. |
| Note | Finding displayed in results. Amber warnings. Program not flagged. |
| Off | Check disabled. No analysis performed, no findings generated. |
Administrators set each check in the Admin Panel under Check Settings, where checks are grouped by family and each has a three-position toggle; a single button resets every check to its catalog default.
This lets an organization tune the catalog to its own codebase -- a site that intentionally truncates fields in certain patterns might set the data-truncation check to Note, while a shop with strict structured-programming standards enables the Control Flow checks.
Quality Report
A quality report is generated at the end of each build, summarizing all findings across the collection.
The report includes:
- Total findings by severity (error, note)
- Findings by check family
- Top programs -- programs with the most findings, ranked by severity
- Trend data -- comparison with previous builds to track improvement or regression
- Detailed finding list -- every finding with program name, line number, description, and severity
Each finding is a structured record containing check type, source file, line number, the specific fields or parameters involved, and the relevant sizes or counts -- so the UI can link findings to exact source lines and downstream tooling can consume them programmatically. The report is viewable in the Build History section of the Admin Panel.
Viewing Results
Web UI
Findings are surfaced in multiple places:
- Program Details page -- findings for the current program in a dedicated section
- Programs List -- a quality-indicator column with finding count per program
- System Overview (Notes tab) -- findings grouped by caller/called pair or program, with severity coloring and clickable program badges
- Build History -- the quality report for each build
- Collection Dashboard -- aggregate quality metrics as summary cards
VS Code Extension
The Afunana extension renders findings as native diagnostics. When you open a source file that has findings, they appear as squiggly underlines on the relevant lines, list in the Problems panel with severity icons, and show the full description and risk on hover -- bringing the silent-failure analysis directly into the developer's editor. See UI Walkthrough and Program Documentation for related surfaces.