Whole-system analysis
DMS parses each NonStop language, TAL and COBOL85 through TACL and Pathway definitions, into a unified program representation, so cross-language calls and shared data structures are visible as one system.
NonStop applications were built around capabilities that made the platform unique: fault tolerance, process pairs, message-based communication, distributed transaction processing and continuous availability. They run payment processing, banking, securities trading and telecommunications workloads where downtime isn't an option.
We modernize NonStop applications by transforming both the code and the architecture around it. Depending on your objectives, that can mean migration to Java or C#, modernization of data access and messaging patterns, decomposition of monoliths into services and adoption of cloud-native deployment models.
The goal is a maintainable modern system that preserves the operational characteristics your business depends on and keeps evolving after the migration ends. A Tandem replica on new hardware fails that test.
Message-passing architectures, Guardian services, Pathway transaction processing, process-pair fault tolerance and low-latency communication models have no direct equivalent in modern cloud environments. So modernization here starts at the architecture and works down to the language. Line-by-line translation produces Java or C# that still behaves like Guardian code, and nobody can maintain it.
Message-based process designs become service-oriented architectures with explicit, documented interfaces.
Pathway transaction processing maps to modern API and workflow frameworks. No emulation.
Process pairs give way to cloud-native resiliency: clustering, orchestration, automated failover.
Enscribe and SQL/MP access strategies move to modern relational patterns with data semantics intact.
Business logic comes out of Guardian-specific infrastructure so it can live and evolve on any platform.
Phased modernization keeps legacy and modernized components running side by side through hybrid architectures.
Every NonStop modernization decision comes down to this split. We preserve the behaviors your business depends on and transform the platform-specific mechanisms that implement them.
Modernize Software supports the languages and platform services that make up real NonStop environments: TAL, pTAL, COBOL85, SCOBOL (Screen COBOL), C, C++, SQL/MP, SQL/MX, TACL, Pathway, Enscribe and related Guardian platform services.
This matters because NonStop applications aren't written in one language. Business logic, data access, transaction processing, batch workloads and operational scripts span several technologies in the same system, and they call into each other constantly. Broad coverage lets us modernize complete applications as one ecosystem instead of a stack of separately translated files.
Our transformations run on the DMS Software Reengineering Toolkit, a fusion of symbolic AI and enhanced compiler technology developed over 25+ years. For NonStop work, that means:
DMS parses each NonStop language, TAL and COBOL85 through TACL and Pathway definitions, into a unified program representation, so cross-language calls and shared data structures are visible as one system.
Formal rewrite rules restructure the code and its architecture. The same input produces the same output every time, which makes results auditable and repeatable across millions of lines.
Transformations operate on program structure and meaning, so the output is idiomatic Java or C# your engineers can actually maintain.
Gen AI plays a separate, supporting role: documenting legacy behavior, generating test cases and assisting code review. It augments the engineering around the migration. It never writes the transformed code.
NonStop modernization is rarely a single-language migration, and the right destination depends on your business objectives.
TAL, pTAL and COBOL85 applications transformed into idiomatic Java services on Spring Boot.
The same architectural transformation targeting the .NET ecosystem, for Microsoft-standard estates.
Azure or AWS deployment models with cloud-native resiliency replacing platform fault-tolerance mechanisms.
Monolithic applications decomposed into services, with Pathway transaction flows exposed as documented APIs.
Modernized services coexist with live NonStop workloads through well-defined interfaces, so capabilities move subsystem by subsystem while critical operations keep running.
Where the objective is platform exit with minimal architectural change, a conservative migration path that still delivers maintainable code.
The phased path is how most organizations actually do this. It cuts cutover risk, and it lets modernization priorities follow business objectives instead of platform constraints.
General questions
Yes. DMS parses TAL and pTAL into the same program representation used for every other language in your environment, then transforms them at the architecture level into idiomatic Java or C#. The resulting applications preserve business behavior while aligning with modern Java or .NET development practices.
The application behavior is preserved while the implementation is modernized. Availability and recovery requirements are mapped to cloud-native resiliency patterns such as clustering, orchestration, health monitoring, and automated failover to deliver equivalent reliability in the target environment.
Pathway server classes are transformed into services with documented APIs. SCOBOL requesters and screen definitions are analyzed together, allowing presentation flows to move into modern web applications or be exposed as API endpoints for integration with other enterprise systems.
Yes, and most organizations do. Modernized services can coexist with existing NonStop applications through well-defined interfaces, allowing business capabilities to migrate subsystem by subsystem while critical production workloads continue operating.
Data access is modernized for relational database targets while preserving the business semantics your applications depend on. Enscribe file structures and SQL/MP schemas are analyzed alongside the application code to ensure consistent data behavior throughout modernization.
No. Code transformation is deterministic and rule-driven through DMS. Gen AI is used as a complementary layer for documentation generation, test creation, code review assistance, and developer productivity, but it does not generate the production conversion itself.
A NonStop assessment inventories your languages, line counts, Pathway configuration and cross-component dependencies, then maps the modernization paths that fit your objectives. You'll know what you're dealing with before anything moves.
.png)
Send us a short note about your system. Rough line counts and target stack are enough to begin.
© 1995-2025
Semantics Design All rights reserved
info@semanticdesigns.com
