Synon · CA 2E · IBM i
Synon / CA 2E Migration
Your Synon code was written by a machine. It should not be migrated as if a person had written it — and it should not be priced that way either.
We recover the 2E function model from the generated RPG itself. No model library required.
Is your 2E model still telling the truth about your system?
Every established Synon modernization path — ARCAD Transformer Synon, Fresche X-2E, CM First — works from the 2E model: the design files in the model library, not the generated RPG. When the model exists and still matches production, that is the right place to start, and we will tell you so.
We keep meeting codebases where it does not.
The 2E licence lapsed
Dropped years ago, often after the last 2E developer retired. The generated RPG kept running the business; the tooling that produced it did not stay. You still own the output, but no longer the means of producing it.
The model library was lost
Typically in a platform move, a hardware refresh, or a migration of the migration tool itself — nobody expected to need the design files afterwards. The source of truth was treated as a build artifact.
The generated code was edited by hand
The one that quietly breaks everything. Developers changed the RPG directly after generation, and kept doing it for years. The model still exists and still looks authoritative. It no longer describes what runs in production.
In all three the standard path stalls before it starts: the tools need a model that is missing, or quietly lying. The third case is the dangerous one, because a migration driven from a stale model produces a system that passes review and fails in production.
That is why we built our recognizer to work from the generated code alone. The skeleton is the fingerprint. The generator's own comments are a bonus, not a requirement.
What makes Synon/2E code different from hand-written RPG
Synon does not generate free-form prose. Every program of a given function
type — Edit File, Select Record, Print File — gets the same skeleton: the same
subroutines, with the same six-character names, doing the same things. BAIZSF
initializes the subfile. CAEXFM displays the screen. ECADRQ
handles an add request.
We have seen this hold across two eras: a CA 2E release 8.7 application generating ILE RPG with embedded SQL, and a Synon-era RPG III application from the 1990s. The same skeleton, twenty-five years apart. The generator's output is one of the most stable artifacts in enterprise software.
That stability is the opportunity. Where a machine wrote the code, a machine can recognize it — and separate it from the part a developer actually wrote. The abstraction the original developers worked at — function types, action diagrams, user points — is recoverable from the generated code, and it is the right level at which to migrate.
How much of a Synon application is actually worth migrating
Where these figures come from
Everything in this section is measured on public demo applications — a CA 2E release 8.7 sample of 13 programs, and a Synon-era RPG III sample. We publish these numbers because we are allowed to: the code is public, so you can check the claim instead of taking it on trust.
The client codebases we actually work on are under NDA, far larger and considerably messier, and we can publish nothing about them. So read what follows as a demonstration of the method, not a benchmark. A thirteen-program sample shows that the recognition works and what it produces; it does not tell you your number. The only template ratio that matters for your migration is the one measured on your own members — which is what the evaluation in section 06 is for.
members recognized
generator boilerplate
hand-written statements
F1 vs the comment oracle
roles bound, names hidden
In that 13-program application every member was recognized as 2E-generated, and the hand-written business logic across the whole thing came to 192 statements.
Look at the Select Record programs: 100% template. Not mostly template — entirely. There is no business logic in them at all. They exist because in 1994 the only way to get a record-selection window was to generate a program for it.
The largest program in the set, an Edit File member, is 2,460 lines of SQLRPGLE. Its hand-written logic sits in four user points. Everything else — 51 subroutines — is generator template.
This is the argument in one line: the migration problem for that program is
not 2,460 lines. It is four user points, a screen definition and a database relation
— plus the knowledge that the rest maps to scaffolding your target platform gives you
for free. A subfile edit screen becomes a CRUD view. BAIZSF and its fifty
sibling routines become a framework's responsibility, not translated code.
The pricing corollary
Migration is routinely quoted per line of code. For hand-written RPG that is already a blunt instrument. For generated RPG it is indefensible: the majority of the quote buys the reproduction of code that nobody wrote.
Ask any vendor quoting on your Synon codebase one question: what is your template ratio? If the answer is not a number, your scaffolding is about to be translated by hand — or by an LLM — and billed to you by the line.
How do we know the recognition is right
We tested it against the one oracle the generator leaves behind: the
* USER: comments that mark every hand-written section.
We stripped those comments before parsing, ran the structural recognizer, and compared what it found against what the comments said. Across nine ILE members and 184 hand-written statements:
statements recovered. Precision 1.00, recall 1.00, F1 1.00 — with zero false positives on the three programs that contain no business logic at all.
Then we made it harder. We anonymized all 45 subroutine names in the largest
Edit File program, so the recognizer could not lean on BAIZSF or
ECADRQ as hints. 91% of roles were still bound correctly, and the
function type was still inferred correctly.
And on the RPG III sample, whose generator banner had been stripped entirely, both members were still classified correctly — recognized structurally, with nothing to read but the code. That is the result that matters for the three situations above: no model, no banner, no comments, and still a function inventory.
The recognizer also shows its work. For every member it reports the evidence behind the classification, with a confidence score: the banner if one is present, the declared function type, the 2E runtime artifacts and calls it found, and how many skeleton subroutines matched the catalog.
What we have validated, and what we have not
We would rather tell you the limits than have you find them.
- The fingerprints are derived from a small public corpus. On your codebase we validate first and promise second.
- Two function types — Edit Transaction and Print File — rest on a single observed example each, so their boundaries are inferred rather than confirmed across instances.
- The database function types (RTVOBJ, CRTOBJ, CHGOBJ, DLTOBJ) have not appeared in any public corpus we could test against.
- RPG III is preliminary support — we validate it on representative samples before committing to it.
None of this changes on a sales call. It changes when we run the engine on your members, which is what the evaluation is for.
How we validate it on your code
We agree an NDA and a representative, limited evaluation scope.
You provide 5–10 sample members per relevant asset type — RPG, DDS, CL, and Synon-generated or RPG III members where applicable.
We load them into a private analysis space and document coverage, parsing outcomes and the generated artifacts. The engines run as a library on your own infrastructure: no connection to your IBM i is required, and no source code is sent to a Strumenta cloud.
We review the results together — your function inventory, your template ratio, your user points, and what they mean for the shape and the cost of the migration.
Start with your own members
Find out your template ratio before anyone quotes you by the line.
Send a representative sample and we will tell you what is generator scaffolding and what is the business logic worth migrating.
The recognizer runs on Strumenta's RPG Language Engine, which parses RPG IV / ILE RPG, SQLRPGLE and DDS into a full semantic model, alongside the CL and DB2 SQL engines. Language engineering is all we do, and has been since 2015.
