TPF macros and services
ENTRC, BACKC and file-access macros carry the real control flow. Each one maps to an explicit, testable construct in the target language.
SabreTalk was built in the 1970s by American Airlines, Eastern Air Lines and IBM to write reservation logic for the TPF mainframe. The compiler is discontinued. The people who wrote in it are retiring. The transaction volumes it carries never stopped growing.
Modernize Software translates SabreTalk to maintainable Java, C# or C++ with DMS, our symbolic AI and enhanced compiler technology. The translated code reads like your target language, passes your test suites and runs off the mainframe.
Trusted By
In 2019 we ran a pilot migration of a SabreTalk subsystem to C for Delta Air Lines. The translation was fully automated, including refactoring to meet Delta's C style guidelines: goto elimination, module consolidation and dead code removal.
SabreTalk is a PL/I dialect, but a PL/I translator can't read it. The language is fused to TPF: entry control blocks, TPF macros, re-entrant coding conventions and Prisym extensions all sit inside the source. A translator has to understand the platform, the dialect and the macro layer together.
ENTRC, BACKC and file-access macros carry the real control flow. Each one maps to an explicit, testable construct in the target language.
Prisym declarations and code convert to clean target-language equivalents. Macros become defined constants and functions your team can read.
TPF programs are written for extreme concurrency. The translation preserves that behaviour on modern runtimes and thread models.
Small TPF segments that exist only because of 4K block limits get folded into single coherent modules with structured control flow.
DMS separates what your code does from how SabreTalk says it. That gives you a real choice of destination instead of a single hard-wired output.
Fare logic, availability rules and booking flows carry across exactly. What changes is the syntax around them, the runtime under them and the pool of engineers who can maintain them.
| Phase | What happens |
|---|---|
| Assessment | We inventory your SabreTalk, Prisym and macro usage, then size the translator configuration against your actual code. |
| Rule tuning | The translator runs on your live codebase while your team keeps shipping. Output is reviewed, rules are refined, tests are built. |
| Final conversion | A fresh snapshot of the code converts in one automated pass, so every change your team made during the project comes across. |
| Cutover | Side-by-side test results support the go decision. Your teams take over a codebase written in a language they already know. |
General questions
SabreTalk is a PL/I dialect created in the 1970s by American Airlines, Eastern Air Lines and IBM for writing reservation logic on the TPF mainframe. The compiler is discontinued, so the code still running today has no supported toolchain behind it.
Yes. Java, C# and C++ are all supported targets, and the Delta pilot translated to C. The DMS front end for SabreTalk is independent of the destination, so the target is your choice rather than a fixed output.
Prisym declarations and code convert to clean target-language equivalents. Macros become defined constants and functions your team can read, rather than being left as unresolved text in the output.
That is the point of the rule-tuning phase. The Delta pilot included refactoring to their C style guidelines: goto elimination, module consolidation and dead code removal. Output is tuned against your standards until your reviewers accept it.
No. The translator runs on your live codebase while your team keeps shipping, and the final conversion runs in one automated pass on a fresh snapshot, so changes made during the project come across.
Legacy and translated systems run side by side on your own cases and test suites. Side-by-side results are what support the go decision at cutover.
TPF programs are written for extreme concurrency, and the translation preserves that behaviour on modern runtimes and thread models. Small segments that exist only because of 4K block limits get folded into coherent modules, which removes overhead the mainframe imposed.
File-access macros and the control flow they carry map to explicit, testable constructs in the target language, so data access becomes readable code instead of macro expansion.
It depends on estate size and target. The Delta pilot moved a 200,000 line subsystem in 3 months at 100% automation. The assessment sizes the translator configuration against your actual code and gives you a real schedule.
No. Translation is rule-driven and deterministic through DMS using symbolic AI, because repeatability is what makes a final automated pass safe. Gen AI is used around the edges, for documentation and comprehension.
Book a free assessment and get a concrete plan for your TPF estate.
.png)
info@semanticdesigns.com
