01-04: The Legacy Bridge (Mainframe Modernization Philosophy)
Modernizing a 40-year-old Mainframe monolith is one of the most high-risk engineering operations an enterprise can undertake. The failure rate is exceptionally high, and the root cause is almost always the same: the tooling relies on strict compilation.
When traditional analysis tools (backed by Abstract Syntax Trees or compiler frontends) attempt to map a legacy COBOL repository, they crash. They crash because a .cpy (copybook) file is missing from the local disk. They crash because the code uses an undocumented dialect quirk from 1982. They crash because the execution flow is hidden inside a Job Control Language (JCL) macro that the parser cannot execute without an IBM emulator.
GitGalaxy solves this by entirely abandoning the compiler. By utilizing AST-free structural physics, GitGalaxy acts as an architectural Rosetta Stone. It treats 40-year-old COBOL and JCL not as executable software, but as raw structural data.
This philosophy unlocks deterministic mainframe modernization without requiring a mainframe.
1. Escaping the Compiler Trap
Compilers demand perfection. If a single variable is undeclared, the AST generation halts, blinding the engineering team to the rest of the file.
GitGalaxy’s heuristic engine thrives on fragmented, broken, and incomplete code. Because it uses bounded optical regular expressions (the StructuralExtractor in gitgalaxy/core/detector.py and the LanguageDetector in gitgalaxy/standards/language_lens.py), it can parse COBOL-74, COBOL-85, and IBM Enterprise extensions simultaneously. It steps over syntax errors and missing dependencies to extract the structural truth of the system:
* Where does the data enter?
* What business logic mutates it?
* Where does it exit?
2. Core Modernization Capabilities
By stripping away the need for an emulator, GitGalaxy provides three massive capabilities for legacy extraction:
A. Execution DAG Mapping (The Architect)
In a mainframe, COBOL programs rarely run in isolation; they are orchestrated by JCL scripts that handle file assignments and step execution. GitGalaxy parses both the COBOL SELECT statements and the JCL DD statements to build a complete Directed Acyclic Graph (DAG) of the system.
It computes the execution order (a topological sort) by mapping Producer -> Consumer file dependencies, instantly highlighting cyclic deadlocks and architectural bottlenecks.
B. Microservice Slicing (Taint Tracking)
Legacy monoliths are tightly coupled. Extracting a single business function (e.g., "Calculate Payroll") usually requires untangling thousands of lines of unrelated state mutations.
GitGalaxy employs a Recursive Alias Engine that traces variable taints across MOVE, ADD, and COMPUTE statements. It slices the lines of business logic that touch a target field, skipping paragraphs the Graveyard Reaper marks unreachable.
C. Zero-Trust Java Forging
GitGalaxy does not just map the old architecture; it scaffolds the new one.
By extracting legacy PIC clauses, EBCDIC byte boundaries, and COMP-3 packed decimal constraints, the engine's Forges automatically translate mainframe structures into modern equivalents. It generates Spring Boot @RestController APIs, JPA @Entity schemas, and Java data-decoding utilities from the verified layouts, with no model involved. That scaffold compiles; whether a ported program then behaves like the COBOL is a separate question, answered per program by the equivalence harness.
3. The LLM Context Constraint
While Autonomous AI Agents and Large Language Models (LLMs) are highly capable of translating COBOL syntax to Java, they lack global context. If an LLM translates a COBOL file that implicitly relies on a missing JCL step, the resulting Java code will compile but fail in production.
GitGalaxy serves as the deterministic bridge. Before an AI agent writes a single line of Java, GitGalaxy injects a strict remediation ticket containing the exact external dependencies, required I/O boundaries, and "honesty flags" (e.g., “This module assumes EBCDIC encoding”).
Grounding a model in verified facts does not by itself show that its Java behaves like the COBOL. So every port, whether a model wrote it or GitGalaxy's deterministic translator did, is checked against the original program before a person approves it: the COBOL runs under GnuCOBOL (with GitGalaxy's CICS models and, for embedded SQL, a real Db2), the port runs on the JVM with the same inputs, and their outputs, screens, COMMAREAs and tables must be byte-identical on every scenario and injected fault the case runs. That shows equivalence on those scenarios, not on all inputs; the evidence level (L2 to L5) says how much of the program they exercised, and a caller stays at L1 while any program it CALLs or LINKs has a hole. The oracle is not z/OS, and its known differences are listed with the proofs. Translating the programs is also not migrating the system (data, job streams, interfaces and cutover remain). Current counts: the progress page; see Ported COBOL-to-Java programs and their evidence.