HPE NonStop (Tandem) modernization: TAL, Pathway, Enscribe and process pairs explained

← All posts

HPE NonStop systems still authorize card payments, switch ATM and point-of-sale traffic, settle trades and many more use cases, often with uptime records measured in decades. They are also among the least understood systems in any enterprise. The engineers who designed the original Tandem applications have mostly retired, and their successors see TAL source, PATHCOM configuration and Enscribe file labels without the mental model that ties them together.

This guide is for architects, modernization leads and senior engineers deciding what to do with an HPE NonStop estate. It explains the platform from the bottom up (process pairs, $RECEIVE, Pathway, TMF, Enscribe, NonStop SQL, TAL and TACL), maps each construct to modern equivalents, walks through a TAL-to-Java translation, and is honest about where a migrated system can and cannot match NonStop availability. For the wider strategic picture, start with our legacy software modernization guide.

Key takeaways

• HPE NonStop is a current, sold product line (x86 NS5 X5 and NS9 X5 systems plus Virtualized NonStop software), not a dead platform. "Stay and modernize" is a legitimate option.
• NonStop availability comes from a stack of cooperating mechanisms (process pairs, message-based OS, TMF, Pathway's context-free servers), not from one feature you can swap out.
• The hardest part of a migration is not TAL syntax. It is preserving transaction boundaries that travel with messages, Enscribe key semantics, and fixed-point arithmetic.
• Process pairs map to replicated stateless services with health checks; TMF maps to local database transactions where possible and sagas only where you must.
• Matching 99.999% availability off-platform is possible but has to be engineered and measured, not assumed.

What is HPE NonStop?

HPE NonStop is Hewlett Packard Enterprise's fault-tolerant server platform for online transaction processing, descended from Tandem Computers' NonStop systems of 1976. It pairs redundant, shared-nothing hardware with a message-based operating system, process pairs, the TMF transaction manager and Pathway, so that a single hardware or software failure does not stop the application.

The HPE NonStop Compute product page currently lists three offerings: the high-end NS9 X5, the entry-class NS5 X5, and HPE Virtualized NonStop Software, which runs in a customer's private cloud and is described as backward compatible with applications on x86-based NonStop systems. "HP NonStop", "Tandem NonStop" and "HPE NonStop" all refer to the same lineage.

From Tandem Computers to HPE: a short timeline

Tandem Computers was founded in Cupertino, California, by Jimmy Treybig and three colleagues. The dates below follow Wikipedia's history of Tandem Computers and its companion article on the NonStop line.

Year	Event
1974	Tandem Computers founded in Cupertino, California
1976	First NonStop (Tandem/16, later called NonStop I) shipped to Citibank
1983	TMF and Pathway introduced
1986	NonStop SQL introduced, described as the first fault-tolerant SQL database
1997	Compaq acquires Tandem
2002	HP and Compaq merge; NonStop becomes an HP product
2005	Itanium-based NonStop i (TNS/E) systems introduced
2014	x86-based NonStop X (TNS/X) systems introduced
2015	HP splits; NonStop moves to Hewlett Packard Enterprise
2020	Sales of Itanium-based NonStop systems end (July)
2025	NS5 X5 and NS9 X5 announced (June 2)

The platform changed processors several times (proprietary CISC, MIPS, Itanium, x86-64) while keeping application compatibility, so one 2026 application can mix 1980s TAL, pTAL recompiled for RISC, and Java written last year.

Where NonStop still runs

HPE's June 2025 announcement of the NS5 X5 and NS9 X5 states that six of the top 10 full-service global retail banks (by market cap as of April 2, 2025) use NonStop for retail card and high-volume payments, ATM functionality and core banking. The same release cites IDC classifying NonStop at availability level AL4, with uptime of 99.999% or 99.9999%, and reports up to 15% more performance capacity than the NS8 X4 in an internal benchmark.

Typical workloads include:

• Payments and card authorization: issuer and acquirer authorization, in-path fraud checks, settlement.
• ATM and POS switching: ACI Worldwide's BASE24 product family, for example, lists HP NonStop among its supported platforms.
• Stock exchanges and post-trade: order matching, clearing and settlement.
• Telecom, retail and manufacturing: call routing, prepaid billing, reservations and plant-floor systems that cannot pause.

A 2002 estimate cited in the Wikipedia history put NonStop behind 95% of worldwide stock transactions and two-thirds of credit card transactions. Treat that as a historical marker, not current market share.

How the Tandem NonStop architecture works

Every NonStop design decision follows one rule: no single failure may stop the application. Tandem applied it to hardware, operating system, database and application framework, and the layers depend on each other.

Shared-nothing hardware and message passing

A NonStop node is a set of independent processors ("CPUs", today x86 server modules), each with its own memory and its own copy of the operating system. They share no memory and talk over a redundant interconnect (originally Dynabus, later ServerNet, InfiniBand on NonStop X). Disks are mirrored, and each volume is managed by a disk process that itself runs as a process pair.

Because nothing is shared, a processor can fail without corrupting anything another processor holds. The cost is that every interaction, including every disk I/O, is a message. NonStop programmers thought in requests and replies decades before microservices. Nodes join into networks with Expand, so a file name like \PROD.$DATA01.BANK.ACCOUNTS carries node, volume, subvolume and file.

Guardian, OSS and the NonStop OS kernel

The operating system was first called T/TOS, then Guardian; it was later marketed as the NonStop Kernel and is now branded NonStop OS. Guardian provides the file system, process management, and the procedure library (FILE_OPEN_, READUPDATEX, REPLYX and hundreds more) that TAL, C and COBOL programs call.

Open System Services (OSS) sits on top of Guardian and provides a Unix-like environment with a hierarchical file system, a shell and POSIX-style APIs. Java and most open-source ports run in OSS. Most estates use both personalities, and Guardian and OSS processes can exchange messages.

Process pairs and checkpointing

A process pair is two copies of the same program in different CPUs. The primary works and sends its state to the backup with the Guardian CHECKPOINT procedure (and mirrors file opens with CHECKOPEN); the backup waits in CHECKMONITOR. If the primary's CPU fails, the operating system notifies the backup, which resumes from the last checkpoint, as described in the Tandem GUARDIAN Operating System Programmer's Guide (1985).

Jim Gray's Tandem technical report Why Do Computers Stop and What Can Be Done About It? (TR 85.7, 1985) is still the best explanation of why this works. Gray contrasts checkpoint-restart pairs, which checkpoint before every significant event (and are hard to program), with persistent pairs, which checkpoint little and rely on transactions to abort in-flight work. He also coined "Heisenbug": a transient fault that disappears on retry, which is why re-executing the same logic in another processor usually succeeds. Every "restart it somewhere else" strategy in modern cloud platforms rests on that insight.

The practical consequence for migration: system processes (disk processes, TMF, PATHMON) run as pairs, but most Pathway application servers do not. Application availability usually comes from many identical servers plus TMF. Hand-written CHECKPOINT calls do exist in older TAL, and every one marks state you must account for.

$RECEIVE: the message queue every server reads

Every Guardian process has a pseudo-file called $RECEIVE. A server opens it, calls READUPDATEX to wait for a request, and answers with REPLYX; a message tag ties each reply to its request. The operating system also delivers system messages there (requester opens and closes, CPU-down notices), signaled by file-system error 6.

$RECEIVE is the integration surface of a NonStop application. If you can describe every message layout that crosses it, you can describe the application's API. Teams that skip this inventory discover interfaces in production.

The NonStop application stack: Pathway, TMF, Enscribe and NonStop SQL

Business logic on HPE NonStop is shaped by a few platform services. Understanding them is the difference between translating code and translating an application.

Pathway (TS/MP): requesters, server classes and PATHMON

Pathway, now delivered as NonStop TS/MP and Pathway/TS, is the transaction processing monitor. The model is requester-server:

• Requesters handle the user or device side: historically SCOBOL programs run by a terminal control process (TCP), today more often Pathsend programs in C, COBOL or Java, or gateways that turn ISO 8583, HTTP or MQ traffic into Pathway messages.
• Server classes are pools of identical processes running one program. Requesters send to the class name; Pathway picks a server.
• PATHMON (itself a process pair) starts servers, restarts failed ones, and grows a class toward its maximum under load. PATHCOM is its command interface.

A server class configuration looks like this (illustrative values):

RESET SERVER

SET SERVER PROGRAM $DATA01.BANK.ACCTSRV

SET SERVER PROCESSTYPE GUARDIAN

SET SERVER TMF ON

SET SERVER NUMSTATIC 4

SET SERVER MAXSERVERS 16

SET SERVER MAXLINKS 32

SET SERVER CPUS (0:1, 2:3, 4:5, 6:7)

ADD SERVER ACCT-SERVER

The rule that made Pathway scale is that servers are context-free: each request carries everything needed, and no conversational state survives between requests. That is the biggest gift a NonStop estate gives a modernization team, because well-written Pathway servers are already stateless services.

Screen COBOL (SCOBOL) requesters define block-mode screens, send to server classes, and bracket work with BEGIN-TRANSACTION, END-TRANSACTION, ABORT-TRANSACTION and RESTART-TRANSACTION. In migration, SCOBOL splits in two: screens become a web or API front end, and transaction control (which servers to call, in what order, when to restart) becomes a service orchestration layer. The second part is where business rules hide.

TMF: transactions that travel with the message

TMF (Transaction Management Facility) provides ACID transactions over audited Enscribe files and NonStop SQL tables, with audit trails, automatic backout and two-phase commit across nodes.

What surprises engineers from other platforms is propagation. A requester calls BEGINTRANSACTION (BEGIN-TRANSACTION in SCOBOL), and the transaction identifier travels with every message it sends. A server that reads the message from $RECEIVE adopts the transaction, so its audited I/O belongs to the requester's unit of work; the server never begins or commits anything. If a server or CPU fails mid-request, TMF backs out the work and the requester restarts it against another server. Pathway servers can be simple because they never handle partial failure. In the target architecture, someone must own that responsibility explicitly.

Enscribe file types

Enscribe is NonStop's native record-oriented file system, roughly the counterpart of VSAM. Record layouts usually live in DDL (Data Definition Language) dictionaries. Files can be partitioned across volumes, carry alternate keys, and be audited by TMF or not.

Enscribe file type	How records are addressed	Typical use	Relational target
Key-sequenced	Primary key (B-tree), plus optional alternate keys	Master files: accounts, cards, customers	Table with primary key; alternate keys become indexes (unique or not, matching the original)
Entry-sequenced	Record address, in insertion order; append-only	Logs, journals, transaction history	Table with a generated sequence column; preserve insertion order explicitly
Relative	Record number (fixed-size slots)	Lookup tables, slot-based queues	Table keyed by slot number; empty slots become absent rows or a status flag
Unstructured	Relative byte address	Binary blobs, program-managed formats	Object storage or BLOB column, after reverse-engineering the format

Two Enscribe behaviors break naive migrations. Key ordering is a raw byte comparison, including binary fields and trailing blanks, so a case-insensitive or locale-aware collation orders and deduplicates keys differently. And programs routinely use generic (partial-key) KEYPOSITION followed by sequential reads, which become range queries that must stop exactly where the original scan stopped. Our guide to migrating VSAM, IMS and Db2 data to relational databases covers the data-conversion mechanics.

NonStop SQL/MP and SQL/MX

NonStop SQL arrived in 1986. SQL/MP is the original Guardian-integrated implementation, with Guardian-named tables and SQL typically embedded in COBOL or C. SQL/MX is the later ANSI-oriented engine with catalog.schema.table names, JDBC and ODBC access, and Java stored procedures. HPE's documentation for NonStop Server for Java 11 lists separate JDBC drivers for SQL/MP and SQL/MX.

NonStop SQL migrates more easily than Enscribe because it is already relational. Watch for partitioning clauses, access modes such as FOR BROWSE ACCESS, and numeric scale and sign rules.

TAL, pTAL and TACL

The TAL programming language (Transaction Application Language, originally Tandem Application Language) is NonStop's systems language. Derived from HP 3000's SPL, it reads like Pascal crossed with C: BEGIN/END blocks, := assignment, ! comments, ^ inside identifiers, and . for indirect (pointer) variables, as the Tandem TAL Reference Manual (1985) shows. pTAL arrived with native RISC code, and later native compilers followed each architecture change.

TAL exposes the machine: word versus byte addressing, pointer arithmetic, bit fields, the FIXED 64-bit scaled integer, DEFINE macros, and Guardian calls checked by condition code (IF <> THEN). None of that exists in Java or C#, so each construct needs a defined translation.

TACL (Tandem Advanced Command Language) is the shell and job-control language. TACL macros start Pathway environments, run batch jobs and drive operations; like JCL, they are routinely left out of migration estimates.

HPE NonStop migration options: stay, extend or move

The first decision is not which language to target. It is whether the application should leave the platform at all.

Stay and modernize on NonStop

HPE still ships new hardware and software, so staying is a real option. Modernizing in place usually means:

• Exposing Pathway services as APIs through gateways that turn HTTP or messaging calls into Pathsend requests.
• Writing new code in Java in OSS. NonStop Server for Java (NSJ 11, aligned with Java SE 11) ships JDBC drivers for NonStop SQL, a JMS implementation and JToolkit.
• Converting Enscribe to SQL/MX on the platform, which also removes a major obstacle to any later exit.
• Retiring TAL incrementally by translating it to C or Java on NonStop.
• Moving to Virtualized NonStop on private-cloud infrastructure.

Staying makes sense when the application is stable, genuinely needs NonStop-class availability, and the skills risk is manageable. As our article on when not to modernize legacy systems argues, a payment switch that works is not a problem just because it is old.

Move off NonStop

An HPE NonStop migration off the platform makes sense when platform costs dominate, when the TAL and SCOBOL talent pool is a business risk, when the organization is consolidating on one cloud or Linux platform, or when the NonStop application is a small, isolated part of a larger estate. The decision criteria in our complete guide to modernizing legacy software apply here too. Most successful exits move subsystem by subsystem, with modernized services running alongside live NonStop workloads.

Mapping NonStop constructs to modern platforms

Whatever the target, each NonStop mechanism needs a named equivalent and an owner. Put this table in front of your architecture review board.

NonStop construct	What it guarantees	Modern equivalent	What you must add or watch
Process pairs (system level)	Survives CPU failure without operator action	Replicated instances across nodes and zones; clustered databases with synchronous replication	Takeover depends on probe and election timeouts; clients must retry
PATHMON restart	Failed server restarted automatically	Kubernetes liveness and readiness probes	Probes must test real dependencies, not just "process alive"
Hand-written CHECKPOINT state	Backup continues mid-conversation	Externalized state or a stateless redesign	Every checkpointed variable must be found
Pathway server class	Pool of identical stateless servers, load-balanced, auto-grown	Stateless service behind a load balancer; horizontal autoscaling	Autoscaling reacts in seconds to minutes; keep a warm minimum
SCOBOL requester	Screen I/O plus transaction control	Web or API front end plus orchestration service	Transaction-control logic must move to the service tier, not the UI
$RECEIVE messages, Pathsend	Typed request/reply by server name	HTTP/gRPC with OpenAPI or protobuf contracts, or a message queue	Timeouts, retries and idempotency become explicit
TMF transaction	ACID across audited files and tables, propagated with messages	Local database transaction in the service that owns the data; XA where unavoidable; sagas across services	Transaction boundary must be moved from requester to service
Enscribe files	Keyed, sequential, relative access with locks	Relational tables and indexes	Binary collation, generic key scans, record locks
SQL/MP, SQL/MX	Relational with NonStop extensions	PostgreSQL, SQL Server, Oracle, Db2	Locking modes, partitioning, numeric scale
TAL, pTAL	Systems code close to the hardware	Java or C# (business logic); C or C++ (low-level utilities)	Word/byte addressing, FIXED, condition codes
TACL macros	Operations, job control, startup	Scheduler, CI/CD pipelines, infrastructure as code	Often undocumented; inventory them early

The Kubernetes version of the Pathway server class above shows how much of the mapping is configuration rather than code:

apiVersion: apps/v1

kind: Deployment

metadata:

name: acct-server

spec:

replicas: 4 # NUMSTATIC 4

selector:

matchLabels: { app: acct-server }

template:

metadata:

labels: { app: acct-server }

spec:

topologySpreadConstraints: # replaces CPUS (0:1, 2:3, ...)

- maxSkew: 1

topologyKey: topology.kubernetes.io/zone

whenUnsatisfiable: DoNotSchedule

labelSelector:

matchLabels: { app: acct-server }

containers:

- name: acct-server

image: registry.example.com/bank/acct-server:1.0.0

readinessProbe:

httpGet: { path: /actuator/health/readiness, port: 8080 }

periodSeconds: 2

failureThreshold: 2

livenessProbe:

httpGet: { path: /actuator/health/liveness, port: 8080 }

periodSeconds: 5

failureThreshold: 3

---

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

name: acct-server

spec:

scaleTargetRef: { apiVersion: apps/v1, kind: Deployment, name: acct-server }

minReplicas: 4 # NUMSTATIC

maxReplicas: 16 # MAXSERVERS

metrics:

- type: Resource

resource:

name: cpu

target: { type: Utilization, averageUtilization: 60 }

The Kubernetes documentation on liveness, readiness and startup probes explains the distinction: a failed readiness probe removes an instance from traffic, a failed liveness probe restarts it. PATHMON did both for you. Probe intervals put detection in seconds, which is where the availability gap starts.

TAL to Java: a worked example

Here is a simplified Pathway server in TAL. It reads a debit request from $RECEIVE, reads and locks the account in a key-sequenced Enscribe file, and replies. Note the missing BEGINTRANSACTION: the requester owns the TMF transaction.

! ACCTSRV: debit an account (simplified; most error handling trimmed)

?NOLIST, SOURCE $SYSTEM.SYSTEM.EXTDECS0 (FILE_OPEN_, FILE_GETINFO_,

? READUPDATEX, REPLYX, KEYPOSITION, READUPDATELOCKX, WRITEUPDATEX)

?LIST

LITERAL ok^status = 0, not^found = 1, nsf^status = 2, sysmsg = 6;

STRUCT req^def (*);

BEGIN

INT req^code;

STRING acct^no[0:15]; ! blank-padded; also the primary key

FIXED(2) amount; ! 64-bit integer, 2 implied decimals

END;

STRUCT rep^def (*);

BEGIN

INT status;

FIXED(2) new^balance;

END;

STRUCT acct^def (*);

BEGIN

STRING acct^no[0:15];

STRING name[0:39];

FIXED(2) balance;

END;

PROC acct^server MAIN;

BEGIN

STRING .recv^name[0:7] := "$RECEIVE";

STRING .acct^name[0:20] := "$DATA01.BANK.ACCOUNTS";

INT recv^fnum, acct^fnum, error, cnt;

STRUCT .req (req^def);

STRUCT .rep (rep^def);

STRUCT .rec (acct^def);

CALL FILE_OPEN_(recv^name:8, recv^fnum, , , , 1);

CALL FILE_OPEN_(acct^name:21, acct^fnum);

WHILE 1 DO

BEGIN

CALL READUPDATEX(recv^fnum, req, $LEN(req), cnt);

IF <> THEN

BEGIN

CALL FILE_GETINFO_(recv^fnum, error);

IF error = sysmsg THEN CALL REPLYX(, 0); ! open/close/CPU down

END

ELSE

BEGIN

CALL KEYPOSITION(acct^fnum, req.acct^no, , 16, 2); ! exact key

CALL READUPDATELOCKX(acct^fnum, rec, $LEN(rec), cnt);

IF <> THEN

BEGIN

rep.status := not^found; ! assumes error 11

rep.new^balance := 0F;

END

ELSE IF rec.balance < req.amount THEN

BEGIN

rep.status := nsf^status;

rep.new^balance := rec.balance;

END

ELSE

BEGIN

rec.balance := rec.balance - req.amount;

CALL WRITEUPDATEX(acct^fnum, rec, $LEN(rec));

rep.status := ok^status;

rep.new^balance := rec.balance;

END;

CALL REPLYX(rep, $LEN(rep));

END;

END;

END;

A faithful Java (Spring) translation moves the transaction boundary into the service, since there is no requester transaction to inherit:

@Service

public class AccountServer {

private final JdbcTemplate jdbc;

public AccountServer(JdbcTemplate jdbc) { this.jdbc = jdbc; }

@Transactional

public DebitReply debit(String acctNo, BigDecimal amount) {

String key = String.format("%-16s", acctNo); // Enscribe keys are blank-padded

if (key.length() != 16) throw new IllegalArgumentException("acct_no longer than 16");

List<BigDecimal> rows = jdbc.query(

"SELECT balance FROM account WHERE acct_no = ? FOR UPDATE",

(rs, n) -> rs.getBigDecimal(1), key);

if (rows.isEmpty()) return new DebitReply(DebitReply.NOT_FOUND, BigDecimal.ZERO);

BigDecimal balance = rows.get(0);

if (balance.compareTo(amount) < 0) return new DebitReply(DebitReply.NSF, balance);

BigDecimal newBalance = balance.subtract(amount).setScale(2, RoundingMode.UNNECESSARY);

jdbc.update("UPDATE account SET balance = ? WHERE acct_no = ?", newBalance, key);

return new DebitReply(DebitReply.OK, newBalance);

}

}

public record DebitReply(int status, BigDecimal newBalance) {

public static final int OK = 0, NOT_FOUND = 1, NSF = 2;

}

A C# version is structurally identical: TransactionScope or an explicit DbTransaction, decimal for FIXED(2), and FOR UPDATE (PostgreSQL) or WITH (UPDLOCK, ROWLOCK) (SQL Server). The gotchas:

• FIXED(2) is an integer holding cents with an implied decimal point. Never translate it to double; use BigDecimal or decimal with scale 2.
• Transaction ownership moves. A requester may call three servers inside one TMF transaction. Give each its own @Transactional service and one atomic unit silently becomes three. Find multi-server transactions before splitting anything.
• Lock duration. On an audited file, the record lock is held until the TMF transaction ends. FOR UPDATE behaves the same; do not "optimize" it into an optimistic read without analysis.
• Key semantics. acct^no is 16 raw bytes. Use CHAR(16) with binary collation, or lookups and uniqueness checks change.
• System messages vanish. Error 6 handling has no Java equivalent. Servers that keep per-requester state keyed on open messages need redesign.
• Retries need idempotency. TMF backout made restarts safe. Over HTTP, a timeout does not tell you whether the debit committed, so add an idempotency key.

Proving the translated server behaves identically requires recorded production traffic and equivalence testing, which we cover in our guide to proving functional equivalence after a migration.

Can a migrated system match NonStop availability and throughput?

Sometimes, at a cost, and only if you engineer for it. "The cloud is just as available" skips the arithmetic.

Five nines (99.999%) allows about 5.3 minutes of downtime a year; four nines about 53 minutes. NonStop gets there because failover happens below the application and much maintenance happens online. Gray's 1985 Tandem data reported a mean time between system failures of 7.8 years, against roughly two weeks for conventional systems then. The same study attributed 42% of failures to administration and 25% to software: operations discipline is half the story on any platform.

A well-built distributed system can approach that, but the mechanisms differ:

• Failure detection moves from operating-system notification to health checks and leader election, which take seconds. Clients must retry idempotently.
• Database failover becomes the critical path. Synchronous cross-zone replication costs write latency; asynchronous replication can lose committed transactions. Choose deliberately.
• Planned downtime must go, through rolling deployments and backward-compatible schema changes.
• Throughput is rarely the problem on modern x86 hardware. Tail latency during failover and lock contention on hot rows (a merchant account, a settlement total) are the real risks.

Distributed consistency is where teams get hurt. The saga pattern described in Microsoft's Azure Architecture Center replaces one ACID transaction with local transactions and compensations, and it explicitly gives up isolation, exposing you to lost updates and dirty reads. Fine for a travel booking; not for a debit and its ledger posting, which belong in one database transaction in one service. Use sagas only where the business already tolerates eventual consistency. Budget for the infrastructure too: our analysis of why cloud bills rise after modernization applies doubly to multi-zone, always-on payment systems.

A step-by-step HPE NonStop migration plan

• Inventory everything: TAL, pTAL, C, COBOL85, SCOBOL, TACL, PATHCOM configuration, DDL dictionaries, Enscribe and SQL file labels, and every external interface (ISO 8583 links, HSMs, MQ, FTP).
• Map transactions: for every requester, record which server classes it calls inside each TMF transaction. This becomes your service-boundary map.
• Document $RECEIVE message layouts as versioned API schemas.
• Classify state: find every CHECKPOINT call, global variable that survives between requests, and open-message-keyed table.
• Design the data migration: Enscribe file types to tables, key collation, alternate keys, audited versus non-audited files.
• Translate code with an automated, repeatable process so you can re-run it as the NonStop source keeps changing.
• Prove equivalence with recorded production transactions replayed against both systems.
• Cut over in slices, routing traffic subsystem by subsystem, with a tested rollback path.

The broader sequencing (inventory, wave planning, parallel runs, cutover) follows the same discipline as a mainframe exit, and our mainframe migration strategy playbook covers it step by step. Be wary of open-ended incremental routing; the reasons strangler fig migrations stall apply to NonStop too.

How deterministic translation handles NonStop code

The TAL example above contains a dozen decisions: FIXED(2), the transaction boundary, error 6, KEYPOSITION modes. A human team makes them inconsistently across millions of lines; a GenAI model makes them inconsistently across runs.

DMS, Semantic Designs' program-transformation engine, takes a different approach. It parses TAL, COBOL, SCOBOL and the surrounding languages into full syntax trees, runs control-flow and data-flow analysis across the whole application, and applies explicit rewrite rules. Modernize Software reports that the same input always produces the same output, and that constructs it cannot translate deterministically are flagged for engineer review rather than guessed. Its HPE NonStop modernization service lists TAL, pTAL, COBOL85, SCOBOL, C, C++, SQL/MP, SQL/MX, TACL, Pathway and Enscribe as in scope, with Java or C# targets, and states that GenAI is used for documentation, test generation and review but never writes the transformed code.

Limits are worth stating. Translation does not decide your service boundaries or your consistency model; architects do, and the translator then applies those decisions everywhere. Low-level TAL that manipulates hardware-specific structures may need redesign rather than translation. When a NonStop-specific dialect or in-house macro library has no off-the-shelf parser, it is the same problem as any proprietary language migration: someone has to build the grammar. For the underlying mechanics, see how deterministic software transformation works.

Case example: NonStop COBOL and SCOBOL to Java and C#

Semantic Designs, the company behind Modernize Software, describes its first HP NonStop COBOL migration on its NonStop COBOL migration page: more than 2 million lines of COBOL and SCOBOL, with a reported 99% of the code converted automatically in 60 days. According to that page, Enscribe file access was replaced with SQL based on the DDL definitions, SCOBOL screens became HTML/JavaScript on the client with C# or Java on the server, and the translated code was refactored for maintainability.

Those are the vendor's own figures, and the customer is not named. Note where the description puts its weight: on the Enscribe-to-SQL mapping and on splitting SCOBOL into presentation and server logic, not on COBOL syntax. A TAL-heavy estate adds systems-level constructs, but the shape is the same: automate the repeatable translation so engineers spend their time on the decisions in the mapping table above.

Frequently asked questions

1. Is HPE NonStop still used today?

Yes. HPE sells the x86-based NS5 X5 and NS9 X5 systems, announced in June 2025, and Virtualized NonStop software. HPE states that six of the top 10 full-service global retail banks use NonStop for card payments, ATM functionality and core banking. Payment switches, stock exchanges, telecom carriers and retailers remain the core user base.

2. What happened to Tandem Computers?

Tandem Computers, founded in 1974, was acquired by Compaq in 1997. Compaq merged with HP in 2002, and when HP split in 2015, the NonStop line went to Hewlett Packard Enterprise. The architecture moved from proprietary processors to MIPS, Itanium and, since 2014, x86, while keeping application compatibility.

3. What programming languages run on HPE NonStop?

TAL and pTAL (Tandem's systems language), COBOL85, SCOBOL for Pathway requesters, C and C++, and Java through NonStop Server for Java in the OSS environment. TACL is the command and scripting language. NonStop SQL/MP and SQL/MX provide embedded and JDBC database access.

4. What is a process pair in Tandem NonStop?

A process pair is a primary and a backup copy of the same program running in different processors. The primary sends state to the backup with checkpoint messages; if the primary's processor fails, the backup takes over from the last checkpoint. System processes use pairs; most Pathway application servers rely on server classes and TMF instead.

5. What is the difference between NonStop SQL/MP and SQL/MX?

SQL/MP is the original NonStop SQL, integrated with Guardian file naming and typically embedded in COBOL or C. SQL/MX is the later ANSI-oriented engine with catalog and schema naming, JDBC and ODBC access, and Java stored procedures. Both are protected by TMF, and HPE ships separate JDBC drivers for each.

6. Can you migrate HPE NonStop applications to the cloud?

Yes: run Virtualized NonStop in a private cloud, or translate the application to Java or C# on Linux or a public cloud. The second path means redesigning process pairs, Pathway, TMF transaction ownership and Enscribe data access, and NonStop-level availability must then be engineered and measured.

Start with a NonStop codebase assessment

Before you decide to stay, extend or move, find out what is actually in the estate: how much TAL, how many server classes, which transactions span servers, and how much Enscribe data has no SQL equivalent yet. Modernize Software offers a free codebase assessment that reports complexity, the share of code that can be translated automatically, and a rough timeline. Request your assessment or read more about our Tandem and HPE NonStop migration approach.