Take the complexity out of parsing: license an engine we have already built.
Fifteen parsers, from RPG and COBOL to Oracle PL/SQL, SAS, Java and the Accellera Portable Test and Stimulus Standard. Each one is a library you license and run yourself, in your own network, against source you export rather than a system we connect to.
They were not built as fifteen separate products. Every one of them is a Starlasu language module, so they produce trees of the same shape — and one tool can walk all fifteen.
Find your language
The catalog is grouped the way estates actually are: the IBM and enterprise platforms, the database languages, the general-purpose and analytical languages — and then PSS, which belongs to a different industry altogether and is listed apart for that reason. Eight of the fifteen can be run in the browser before you talk to anybody; those carry a Playground mark.
IBM and enterprise platforms
The languages that run the business and that nobody can read any more. These four are the ones migration programs start from — and RPG, DDS and CL share one data model, so an IBM i estate can be analyzed as a single connected graph rather than three disconnected inventories.
RPG & DDS
The IBM i application itself. RPG IV fixed-format, /FREE and fully-free layouts in the same member, embedded SQL, and all four kinds of DDS file. RPG III is supported too: those members are adapted line by line into the equivalent RPG IV layout and run through the same pipeline, so both generations produce identical AST node types. RPG II is not supported. Beyond the tree there is cross-codebase symbol resolution, a dependency-graph builder and a sequence-diagram generator.
CL
The orchestration the RPG never shows you: job flows, file overrides, library lists, spool handling, program calls. CL is a thin syntax over an enormous open vocabulary of commands, so the engine carries over 2,100 IBM i commands modeled as typed nodes — and parses the ones it does not recognize as faithful generic nodes instead of skipping them. Modernization programs usually start with RPG and stall here.
COBOL
COBOL-85 at the core, with COPY and REPLACE expansion, embedded SQL and CICS, and positions preserved through both continuation joining and copybook expansion. The regression run parses all 459 programs of the NIST COBOL-85 validation suite — a public, vendor-neutral corpus you can go and count yourself.
EGL
IBM’s generate-to-target 4GL, for organizations that want an exit and cannot simply keep the generated COBOL either. The strong part of this engine is the semantics module: cross-file member, function and record resolution, including the implicit-SQL get and open statements that are the hardest thing in the language to resolve.
Database and SQL dialects
Five engines, and they are not interchangeable. Two of them read the procedural code that lives inside a database, one reads physical warehouse design, one is an embedded component for software vendors, and one is an editor engine for analytic SQL. Pick by what you are doing, not by the word SQL.
Oracle PL/SQL
Package bodies, the SQL embedded in them, and the SQL*Plus script wrapped around both — one grammar covers all three, which is what a single-namespace SQL parser cannot do. 508 regression fixtures ship with committed expected trees, and a code generator writes PL/SQL back out. It is the one engine in the catalog that closes the loop.
T-SQL
Microsoft’s control-of-flow language as it is actually written: stored procedures, triggers, functions and ad-hoc batches, over DECLARE @var and temporary tables. Two implementations exist — a JVM one that shares the Oracle engine’s grammar and handles both dialects, and a focused .NET one for SELECT, INSERT and UPDATE. Which you want depends on your runtime.
Teradata SQL
Teradata SQL is not a language people write applications in — it is the language of physical warehouse design. A single CREATE TABLE carries the fallback policy, the journaling, the block size, the checksum, the map, the primary index and the per-value compression lists, and all of that has to survive the move. A Teradata-to-Spark SQL transpiler sits beside the engine.
Firebird
The component for software vendors who embed Firebird in their own product. It is a .NET library rather than a JVM one, it targets Firebird 4.0, and it does more than read syntax: symbol resolution and expression typing against a database model you supply. 93 automated tests, one of them a real ISV production schema.
Analytic SQL
Not a general-purpose SQL parser, and we would rather say so than let you find out. It is a TypeScript engine for analytic SQL across cloud warehouses, built for editors and language services: completion, formatting, symbol resolution against a supplied database model, expression type inference. Eight dialects — Generic, Snowflake, Databricks, MSSQL, MS Fabric, BigQuery, PostgreSQL and Redshift, which maps to the PostgreSQL dialect. SELECT, INSERT and UPDATE; no DDL and no procedural language.
General-purpose and analytical languages
Free parsers exist for most of these and some of them are good. That is not the argument. You license these because the Java, Python or SAS side of a project has to land in the same model as the COBOL or RPG side — and because four of the five write code back out as well as reading it.
Java
Modeled on the Java Language Specification, SE 20. All final language syntax through Java 17 is covered — records, sealed types, switch expressions, text blocks, pattern matching for instanceof, modules — and Java 18 to 20 introduced no further final syntax. Beyond parsing there is a semantic layer that resolves lambdas and type parameters, and a printer that writes Java back out with comments intact.
Python
Four fifths of this engine’s test suite exercises generation rather than parsing, which tells you what it is for: this is the component you license when Python is the target — when a migration has to emit Python from a model, repeatedly and consistently, with placeholders for the parts a template supplies. Python 3; it does not read Python 2.7.
Kotlin
Built on JetBrains’ own published ANTLR grammar, so what counts as legal syntax is settled by a versioned document rather than by running the compiler and watching. Templates and code generation are included. It does not do symbol resolution, type inference or call graphs — the README says so and so do we.
VBA / VB6
One grammar for both dialects: the macro estate hiding inside Excel and Access workbooks, and the VB6 desktop applications still running behind them. The statement-level language is very largely shared, which is why a single engine can cover both. It is the youngest engine in the catalog — check the maturity column before you plan around it.
SAS
A SAS program is not one language but three stacked on each other: the DATA step, the PROC steps, and the macro language that generates the source text of the other two before either runs. This engine reads all three, including the whole of PROC SQL with pass-through. Eleven releases since 2021, 151 automated tests, and the transpilers built on it have processed tens of millions of lines.
Hardware verification
Fourteen of these engines exist because somebody has an old business system to read. This one does not. It is listed apart because pretending it is a sibling of the COBOL parser would mislead both audiences.
PSS — Portable Test and Stimulus Standard
PSS is the Accellera Portable Test and Stimulus Standard, version 3.2: a portable description of test intent for a chip or a system, from which tools generate concrete tests for many targets — UVM and SystemVerilog among them. It is sold to semiconductor verification teams, not to modernization programs. The engine parses the full PSS language: 277 parser rules across 1,571 lines of grammar implement the standard’s formal syntax, including actions and abstract actions, activities in all their statement forms, constraints, covergroups with coverpoints and crosses, components and pools, flow objects, exec blocks, extension and inheritance, and the compile-time compile if, compile has and compile assert forms.
Beyond the fifteen engines listed above, we are always building more, and a language we have not packaged yet is usually a custom parser project rather than a refusal. If you do not see what you need — or what you run is a dialect of your own — get in touch and we will tell you which it is.
Try them before you talk to us
The Strumenta Playground runs several of these engines in the browser. Paste your own code, pick the language, and look at the tree the parser actually produces — which is a far better way to judge an engine than reading a page about it.
It is also the family argument made tangible. The Playground is built on Starlasu, the same AST framework as every engine in this catalog, and one interface reads all of the languages in it. Switching the language does not switch you into a different tool with a different model — which is exactly the point the rest of this page is making in words.
It does not cover all fifteen. Kotlin, VBA/VB6, CL, EGL, PSS, T-SQL and Firebird are not in the Playground today. For those, send us a file instead and we will run it ourselves and tell you what came back.
- RPGThe IBM i engine, with named customer variants alongside the standard one.
- COBOLThe same engine that runs the NIST COBOL-85 suite.
- PL/SQLPackage bodies, embedded SQL and SQL*Plus in one grammar.
- SASDATA steps, PROCs and the macro layer, with variants.
- JavaFinal syntax through Java 17.
- PythonPython 3.
- SQLThe analytic SQL engine behind the editor language services.
- Teradata SQLPhysical warehouse design, DDL and all.
Fifteen engines, one model underneath.
This is the argument that only makes sense on this page, because this is the page about all of them at once. The engines were built as one family, and the family is the thing you cannot assemble yourself.
Every Strumenta engine is built on Starlasu, our AST framework. That is not a branding detail: it means a COBOL tree, an RPG tree, a PL/SQL tree, a Java tree and a Python tree have the same shape, the same traversal model and the same API. One tool walks all of them.
Try to get that by gluing five unrelated open-source parsers together and you have five models, five idioms, five position conventions and five sets of edge cases to reconcile before you have written a single line of analysis. That reconciliation layer is the project. It is also the part nobody budgets for.
Every engine supports LionWeb, so the models interchange with LionWeb-compliant tooling instead of being locked inside one process. And every engine is reachable through bindings from Java, Kotlin, Python, TypeScript and C# — the host application picks the language, the parser does not impose one.
The practical consequence: an estate that is RPG on IBM i, COBOL on z/OS, PL/SQL in the database and Java in the service layer can be inventoried as one connected graph, not four disconnected ones. Which program calls which package; which package writes the column the screen reads; what breaks if this table changes — none of those questions live inside a single language.
Shared by all fifteen
- The Starlasu AST shape. Same node model, same API, same traversal, whichever language produced the tree.
- Positions on every node. Every finding can be taken back to the line it came from.
- Error tolerance, not exceptions. Awkward input returns a partial tree plus positioned issues, so a batch run over twenty thousand files completes and tells you where it struggled.
- LionWeb support. Models interchange with other LionWeb-compliant tooling.
- Five bindings. Java, Kotlin, Python, TypeScript and C#.
- A command-line tool. Serialized output for every engine, so the first experiment does not need an integration.
- It runs where you are. Your own laptop or your own CI, on exported source, with no connection back to us and none to the machine the code came from.
Compare them side by side
Three things separate one engine from another once you have found your language: what it runs on, what it does beyond producing a tree, and how deep the evidence behind it goes. All three are in the table.
| Engine | Playground | Runs on | Beyond parsing | Depth of evidence |
|---|---|---|---|---|
| RPG & DDS | Try it live | JVM | Symbol resolution, dependency graph, sequence diagrams | 718 automated tests; a regression corpus of 53 open-source RPG repositories; 30 million lines of production RPG |
| CL | Not in the Playground | JVM | Cross-file symbol resolution | Over 2,100 IBM i commands modeled as typed nodes; unrecognized commands parsed rather than skipped |
| COBOL | Try it live | JVM | Printer — AST back to COBOL text | 681 automated tests; all 459 programs of the NIST COBOL-85 suite on every run |
| EGL | Not in the Playground | JVM | Cross-file symbol resolution, including implicit SQL | Golden-file AST fixtures, plus a regression task that downloads external EGL projects and parses them |
| Oracle PL/SQL | Try it live | JVM | Code generator — AST back to PL/SQL | 508 fixtures with committed expected ASTs, so an upgrade cannot silently change the tree; 156 unit tests |
| T-SQL | Not in the Playground | JVM and .NET | Parsing and AST | 66 automated tests on the .NET implementation; the JVM one shares the PL/SQL engine’s test infrastructure |
| Teradata SQL | Try it live | JVM | A separate Teradata → Spark SQL transpiler | Worked examples versioned per release, v0.1.1 to v0.1.12 — a public record of what each release added. A young component; see the note below |
| Firebird | Not in the Playground | .NET Standard 2.0 | Symbol resolution and expression typing | 93 automated tests, including a production ISV schema |
| Analytic SQL | Try it live | Node / TypeScript | Editor language services: completion, formatting, type inference | 257 automated tests across 18 files; the package is published only if all of them pass |
| Java | Try it live | JVM | Semantic resolution and a Java printer | 331 tests across parsing, semantics and generation — 103 of them on semantic resolution alone |
| Python | Try it live | JVM | Code generator and placeholders | Around 104 tests, 79 of them on the code generator |
| Kotlin | Not in the Playground | JVM | Code generation and templates — no symbol resolution | JetBrains’ own published grammar underneath; 15 tests in the module. A young component |
| VBA / VB6 | Not in the Playground | JVM | Parsing and AST | 26 tests. The youngest engine in the catalog, and still below version 1.0 |
| SAS | Try it live | JVM | Transpilers built on it target Python, PySpark, Databricks and SQL | 151 automated tests; 11 releases since 2021; transpilers on this engine have processed tens of millions of lines |
| PSS 3.2 | Not in the Playground | JVM | Parsing and AST | 277 parser rules across 1,571 lines of grammar, covering the standard’s formal syntax. We do not publish a test count for this engine |
The fifteen are not all at the same depth, and we would rather say which
A catalog that presented all fifteen as equals would be easy to write and easy to catch. They are not equals. RPG, COBOL, SAS, Oracle PL/SQL and Java are the deep end: years of continuous development, test suites in the hundreds, public or named corpora behind them, and in several cases production migrations running on top. CL, EGL, Firebird and the analytic SQL engine are solid, focused components with real semantic layers and real test suites, built for a narrower job.
Teradata SQL, Kotlin, VBA/VB6 and PSS are younger. Teradata SQL and VBA/VB6 are still below version 1.0; the Kotlin module has fifteen tests and no symbol resolution; PSS has comprehensive grammar coverage but no test figure we are willing to print. Licensing one of those is a reasonable thing to do — they are real, they are supported, and a focused component that does one job is often exactly what a project needs. It is just not the same proposition as licensing the RPG engine, and you should know which one you are buying before you plan around it.
The honest way to settle it is not a table at all. If your language is one of the eight in the Playground, paste your worst file into it and judge the tree yourself. If it is not, send the file to us: we will tell you what parses, what does not, and whether the engine is at the depth your project needs — and if it is not, we will say so rather than sell you the license.
A library, not a service.
You license the engine and run it yourself. There is no hosted endpoint to send your source to, no per-file metering, and no connection back to us at run time.
Delivery is a library for your runtime — the JVM for most of the catalog, .NET for Firebird, Node for the analytic SQL engine — plus a command-line tool that serializes the AST, and documentation of the model you will actually work against rather than a generated class list.
Licensing comes in three tiers. Standard is for using the engine inside your own organization. Distribution is for shipping it inside a product you sell. Service is for running it as part of a service you offer. Support is included in all three; the terms of the general license are published in full.
What we ask in return is a representative sample before you commit — the awkward file, not the clean one. It is the fastest way for both sides to find out whether this is a fit, and it costs you nothing.
In the package
- The library for your runtime, versioned and released.
- A command-line tool that serializes the AST, for the first experiment.
- Documentation of the AST you work against, not of the parse tree.
- Serialization to JSON, XML, EMF/Ecore and LionWeb.
- Support, included in every tier.
- Published license terms — read the general Language Engine license before you talk to us, not after.
Straight answers
My language is not in the catalog. Now what?
Then it is a custom parser project, which is work we do routinely — including for in-house dialects and formats that were never documented. The engines in this catalog all started that way. Tell us what you need to read and we will tell you what it would take.
Why license a parser for Java or Python when free ones exist and are good?
You should not, if all you need is to parse Java. You license ours when the Java has to sit in the same model as the COBOL, the RPG and the SQL — one AST shape, one traversal, one tool — or when you need to generate the language rather than read it. Those are the two jobs the free parsers do not do for you.
Do we have to send you our source code?
Not to run an engine. The libraries and the command-line tools run inside your own network, on source you have exported, with no connection back to us and none to the system the code came from. For a qualification conversation we do like to see a representative sample, under whatever agreement you need.
Can I use two engines together?
That is what the catalog is for. Every engine is a Starlasu language module producing an AST in the shared shape, so a tool written against one works against the others. RPG, DDS and CL in particular are designed to be used together: an IBM i estate becomes one connected graph rather than three separate inventories.
What format does the output come in?
JSON, XML, EMF/Ecore or LionWeb, depending on what you are feeding. The metamodel is documented and exportable, so you can generate your own bindings rather than working against an opaque structure — and the five language bindings mean the host application picks the language, not the parser.
Is the output good enough to migrate from?
For the deep end of the catalog, yes — these are the same engines underneath our own migration work, and the transpilers built on the SAS and RPG engines have processed tens of millions of lines. If you want the migration rather than the machinery, start from Legacy Modernization or RPG and IBM i modernization.
Bring us a file, and we will tell you what parses.
A representative sample of the code you actually need to read, and we will come back with what the engine handles, what it does not, and which tier of license the work calls for. If the engine is not deep enough for what you are planning, we will say so.
