2026-04-02·10 min read·sota.io team

Deploy PL/I to Europe — IBM Vienna Research Lab 🇦🇹 (Dines Bjørner 🇩🇰 + Peter Lucas 🇦🇹, 1964), the Enterprise Language That Invented Formal Semantics, on EU Infrastructure in 2026

Every language has a public history and a hidden one. PL/I's public history is well known: designed at IBM in 1964 to replace both FORTRAN and COBOL with a single general-purpose language for the new System/360 architecture, it became the dominant enterprise language of the 1970s and 1980s across banking, insurance, and government computing worldwide. Its hidden history is Viennese — and it is where the entire discipline of formal programming language semantics began.

In 1966, IBM opened a research laboratory in Vienna, Austria 🇦🇹. One of its first major projects was to produce a rigorous mathematical specification of PL/I's semantics — a language so large and ambiguous that no two IBM compiler teams produced the same behaviour for the same input. To do this, a team of researchers invented an entirely new formalism: the Vienna Definition Language (VDL). The people who built it — Dines Bjørner 🇩🇰 from Denmark, Peter Lucas 🇦🇹 from Austria, and Hans Bekič 🇭🇷 from Croatia — were doing something that had never been done before: giving a programming language a complete, unambiguous, machine-processable formal semantics.

VDL became VDM. VDM became a standard tool in safety-critical system engineering across Europe. The intellectual thread runs from IBM Vienna in 1966 to today's EU AI Act Art. 9 risk management requirements, to DO-178C avionics, to ISO 26262 automotive software.

PL/I itself never went away. It is running right now, today, in the data centres of Deutsche Bank 🇩🇪, BNP Paribas 🇫🇷, Société Générale 🇫🇷, ING 🇳🇱, and dozens of other European financial institutions — processing SEPA payments, running SWIFT settlement, computing risk under MiFID II. The language that IBM designed in 1964 is deeply embedded in European financial infrastructure, and the formal methods tradition that grew from its specification is the intellectual backbone of EU-regulated software safety.

IBM System/360 and the Unification Problem

In 1961, IBM faced a strategic crisis. The company was producing half a dozen incompatible computer architectures — IBM 704, 709, 7090 for scientific computing; IBM 1401, 1620 for commercial computing — each with its own programming language and ecosystem. Customers could not share software between machines. IBM's own engineers could not transfer skills across product lines. The maintenance costs were becoming unsustainable.

The solution was the IBM System/360 — announced in April 1964, it was a single architecture designed to span the full range of computing applications from the smallest commercial workload to the largest scientific computation. The System/360 was one of the most consequential decisions in computing history: it established the idea of an architecture family, influenced every subsequent mainframe and minicomputer design, and its descendants (System/370, System/390, z/Architecture) still run in IBM mainframes today.

But the System/360 also needed a new programming language — one that could replace both FORTRAN (the scientific language) and COBOL (the commercial language) while adding the systems programming capabilities that neither provided. IBM formed a joint committee with the SHARE (scientific) and GUIDE (commercial) user groups. The committee — in a display of ambitious optimism — named the result NPL (New Programming Language). When it emerged that NPL was also the name of the UK's National Physical Laboratory, the name was changed to PL/I (Programming Language One).

The first PL/I definition was published in 1965 as IBM Technical Report TR 00.820. The language that emerged was, by any measure, enormous.

PL/I: A Language of Firsts

PL/I was designed with a philosophy of inclusiveness that was unprecedented at the time: rather than choosing a small, clean set of features (as Algol 60 had done), PL/I aimed to include every feature that any programmer in any domain might need. The result was the largest language specification that had ever existed — and also, embedded within it, a remarkable collection of genuine innovations.

Exception Handling: The ON Condition

PL/I was the first mainstream language to include structured exception handling as a core language feature. FORTRAN used error flags. COBOL used conditional branches to error labels. PL/I introduced ON conditions — named exception categories that could be handled with user-provided code at any scope level:

ON OVERFLOW BEGIN;
   PUT SKIP LIST('Overflow detected — using fallback value');
   RESULT = MAX_SAFE_VALUE;
   RESUME;
END;

RESULT = A / B;  /* if B is near zero, OVERFLOW fires */

The PL/I exception model — named conditions, scoped handlers, SIGNAL/RESUME/GOTO for recovery — influenced every subsequent exception system, including Ada's exception model, C++'s try/catch, Java's checked exceptions, and Python's try/except. PL/I's ON ZERODIVIDE, ON OVERFLOW, ON UNDERFLOW, and ON STRINGRANGE are the direct ancestors of modern exception hierarchies.

Structures: Heterogeneous Data Before C

PL/I introduced structures — named collections of heterogeneous typed fields — before C had them. A PL/I structure is declared as:

DECLARE 1 CUSTOMER,
          2 NAME CHARACTER(30),
          2 ID FIXED DECIMAL(8),
          2 ADDRESS,
            3 STREET CHARACTER(50),
            3 CITY CHARACTER(20),
            3 POSTCODE CHARACTER(10),
          2 ACCOUNT_BALANCE FIXED DECIMAL(15,2);

The hierarchical numbering (1, 2, 3) for nested structures is PL/I's distinctive syntax for what C calls struct. PL/I supported arrays of structures, structures of arrays, and dynamic allocation of structured storage via BASED variables — giving it the full range of data structure capabilities that ALGOL W and Pascal were independently developing at the same time.

PL/I introduced four explicit storage classes that programmers declared for every variable:

AUTOMATIC — stack-allocated, scoped to the enclosing block (like C's default locals)
STATIC — persistent across calls, module-lifetime storage
BASED — heap-allocated, accessed via a pointer (BASED(ptr))
CONTROLLED — allocate/free explicitly with ALLOCATE/FREE

This explicit storage class system — where the programmer must consciously declare what kind of memory a variable uses — is a GDPR Art. 25 design pattern. Data minimisation by design means that personal data should not persist beyond its necessary scope. PL/I's AUTOMATIC storage implements exactly this: a variable declared AUTOMATIC cannot outlive its block. The GDPR's technical requirement for purpose limitation by default has a direct mechanical implementation in PL/I's storage class system.

Fixed-Point Decimal: The Banking Foundation

PL/I's FIXED DECIMAL type — exact decimal arithmetic with user-specified precision and scale — is the foundation of PL/I's dominance in financial computing. Unlike FORTRAN's floating-point (which cannot represent 0.10 exactly in binary) or COBOL's computational PIC types, PL/I's FIXED DECIMAL(15,2) represents exactly 15 significant decimal digits with 2 after the decimal point, without floating-point rounding errors.

DECLARE AMOUNT FIXED DECIMAL(15,2);
DECLARE TAX_RATE FIXED DECIMAL(5,4);
DECLARE TAX_AMOUNT FIXED DECIMAL(15,2);

AMOUNT = 1000.00;
TAX_RATE = 0.1900;  /* 19% German VAT */
TAX_AMOUNT = AMOUNT * TAX_RATE;  /* = 190.00 exactly */

Every SEPA payment, every MiFID II trade, every PSD2 transaction processed on IBM z/OS PL/I uses fixed-point decimal arithmetic. The alternative — floating-point — would introduce rounding errors that are illegal under EU financial regulations. PL/I's decimal arithmetic is not a legacy curiosity; it is a regulatory requirement.

IBM Vienna Research Laboratory 🇦🇹: Where Formal Semantics Was Born

The IBM Vienna Research Laboratory (Wissenschaftliches Zentrum Wien) was established in 1961 as IBM's European research presence. Located in Vienna, Austria — in the intellectual tradition of a city that had produced Wittgenstein, Gödel, and the Vienna Circle — it became, somewhat unexpectedly, the birthplace of formal programming language semantics.

The Problem: PL/I Was Ambiguous

By 1966, PL/I was already in production and already broken. Different IBM compiler teams in Poughkeepsie (New York), Hursley (England), and Vienna produced compilers that disagreed on the behaviour of the same PL/I programme for hundreds of constructs. The problem was fundamental: the PL/I definition was written in English natural language, and English is ambiguous. Without a formal semantics — a mathematical specification that unambiguously defined what every PL/I construct meant — no two compilers would ever agree.

IBM's Vienna Lab received the assignment: formally define PL/I.

Dines Bjørner 🇩🇰: The Danish Architect of Formal Methods

Dines Bjørner was born in 1937 in Denmark 🇩🇰. He studied mathematics and computer science and joined the IBM Vienna Research Laboratory in 1965 as one of its founding researchers. Over the following eight years in Vienna — and then for decades after at DTU (Danmarks Tekniske Universitet, Technical University of Denmark) in Lyngby, Copenhagen — Bjørner built what became the Vienna Development Method.

Bjørner's insight was that a programming language's semantics could be described as a set of mathematical state-transition functions: given an abstract machine state, each language construct maps the input state to an output state. This "denotational" approach — giving meaning to programme text by mapping it to mathematical objects — was being developed simultaneously and independently by Christopher Strachey 🇬🇧 (Oxford) and Dana Scott 🇺🇸 (Oxford, then Carnegie Mellon), but Bjørner's group at Vienna was working on the largest and most practically important test case: PL/I.

After leaving IBM Vienna in 1973, Bjørner returned to DTU Copenhagen, where he led the formal methods group for decades and became one of Europe's most influential computer scientists. His work on VDM was adopted by the Danish research community, by the British Ministry of Defence (Def Stan 00-55 required formal methods for safety-critical software), and eventually by ISO (ISO 13817-1, the VDM-SL standard).

Peter Lucas 🇦🇹: The Austrian Who Built VDL

Peter Lucas was Austrian, born in Vienna, and was a central figure in the IBM Vienna Lab's formal semantics work from the beginning. Lucas led the technical development of the Vienna Definition Language (VDL) — the notation that the team invented specifically to write PL/I's formal definition.

VDL was a language designed to describe other languages. It provided:

Abstract syntax trees — structured, hierarchical representations of programme syntax
State functions — mathematical functions from interpreter states to states
Interpretation rules — recursive functions mapping abstract syntax trees to state transitions
Environments and stores — explicit mathematical models of variable binding and memory

The VDL specification of PL/I, completed between 1966 and 1969, ran to hundreds of pages. It was the first time any real programming language of industrial scale had been given a complete, formal, mathematical definition.

Hans Bekič 🇭🇷: The Croatian Theoretician

Hans Bekič (sometimes spelled Beki) was born in Zagreb, Croatia 🇭🇷 (then Yugoslavia) and joined the IBM Vienna Lab in the mid-1960s. He was, by many accounts, the most technically gifted member of the team. Bekič made fundamental contributions to the theory of recursion equations and fixed-point semantics — the mathematical machinery that underlies denotational semantics.

Bekič's work on least fixed points and domain theory — developed in parallel with Dana Scott at Oxford — gave VDL its mathematical foundations. His 1969 paper on interprocedural semantics (how procedures and parameter passing work in formal semantics) remains a landmark in the field.

Bekič died in a skiing accident in December 1982, aged approximately 44. IBM Vienna published a commemorative collection of his papers posthumously. His contributions to formal methods — largely via unpublished IBM technical reports that were circulated among researchers — influenced the entire subsequent generation of formal methods work, including the development of Standard ML (Milner 🏴󠁧󠁢󠁳󠁣󠁴󠁷, Edinburgh), Z notation (Abrial 🇫🇷, Oxford), and Algebraic Specification (ADJ group, IBM Research).

VDL → VDM → EU Safety Standards Today

The Vienna Definition Language, after the PL/I project, evolved into the Vienna Development Method (VDM). Where VDL was a specification tool for language definition, VDM became a method for software development: write a formal specification of what a system should do, refine it through a series of proved steps into an implementation, and carry proof obligations at each step that guarantee correctness.

VDM is not a historical artefact. It is in active use today:

DO-178C (Avionics Software): VDM models are used in the design and verification phases of Level A and B avionics software development. Companies like Rolls-Royce 🇬🇧 (Derby), Thales 🇫🇷 (Meudon), and Airbus Defence & Space 🇩🇪🇫🇷🇪🇸 use formal specification tools that trace their lineage to VDM.

ISO 26262 (Automotive Functional Safety): VDM-style formal specifications are accepted evidence of ASIL-D software design correctness — the highest automotive safety integrity level. Continental AG 🇩🇪, Bosch 🇩🇪, and ZF Friedrichshafen 🇩🇪 use formal methods in safety-critical automotive ECU development.

EU AI Act Art. 9 (Risk Management for High-Risk AI): The formal specification and verification approach pioneered in VDM is directly applicable to EU AI Act compliance for high-risk AI systems — systems that assist in medical diagnosis, credit scoring, biometric identification, or safety-critical infrastructure management. VDM-SL (ISO 13817-1) provides machine-checkable evidence that a system's design meets its specification.

OVERTURE Tool: The Overture project (Aarhus University 🇩🇰, Newcastle University 🇬🇧, INRIA 🇫🇷 Sophia-Antipolis) maintains an active open-source IDE for VDM-SL and VDM++ — continuing the IBM Vienna tradition in 2026 at European universities.

PL/I in EU Financial Infrastructure: The Living Legacy

PL/I did not disappear when C arrived, or when Java arrived, or when Python arrived. It went underground into the most critical, least-replaceable layer of European financial infrastructure.

Deutsche Bank 🇩🇪: SEPA on z/OS PL/I

Deutsche Bank's core banking systems — settled at its Frankfurt 🇩🇪 data centres — run IBM z/OS mainframes with PL/I applications that process SEPA Credit Transfers (30+ billion annually across the EU), TARGET2 real-time gross settlement, and SWIFT interbank messaging. These are not legacy systems pending replacement: they are the financial plumbing of the EU economy, and their PL/I programmes have been running, accumulating regulatory compliance, and being audited under DORA (Digital Operational Resilience Act, Regulation (EU) 2022/2554) continuously since the 1970s.

BNP Paribas 🇫🇷 and Société Générale 🇫🇷: MiFID II on Mainframes

French banking operates on IBM z/OS mainframes with PL/I. BNP Paribas — the EU's largest bank by assets — and Société Générale both maintain PL/I programmes that generate MiFID II transaction reports (the mandatory post-trade transparency reports required by EU securities law), compute EMIR margin calls for derivatives clearing, and produce COREP regulatory capital reports for the ECB.

The reason PL/I persists in these applications is precisely PL/I's FIXED DECIMAL arithmetic: the ECB and national supervisors require that capital and exposure calculations produce exact decimal results. Floating-point approximations are not acceptable for regulatory reporting. PL/I on z/OS is the only production-grade platform that guarantees this for applications that have been in continuous operation for 30+ years.

ING 🇳🇱: PSD2 and Open Banking

ING's core banking infrastructure includes PL/I components that handle account history and balance calculation for its PSD2 APIs — the open banking interfaces mandated by the EU Payment Services Directive. When a third-party payment app queries ING's account API, the PSD2 backend may well be calling a PL/I balance calculation that has been running since the 1990s. ING has invested in modernisation — wrapping legacy PL/I in API gateways — but the calculation logic remains on z/OS.

ECMA Standardisation: Geneva 🇨🇭

PL/I's formal standardisation was a European initiative. ECMA (European Computer Manufacturers Association, founded 1961, Geneva, Switzerland 🇨🇭) published ECMA-50 in 1976 — the first internationally recognised PL/I standard. ECMA-50 defined a "General Purpose" subset of PL/I that was implementable across different hardware architectures and formed the basis for subsequent ISO 6160:1979 (PL/I general purpose subset), the ISO standard that governed PL/I implementations across Europe for decades.

ECMA's Geneva base matters: as the organisation that also standardised ECMAScript (JavaScript), C# (ECMA-334), and C++/CLI (ECMA-372), its standardisation of PL/I was part of a continuous European tradition of bringing industrial programming languages under international, vendor-neutral governance. The ISO standard remains in force and is the specification against which Iron Spring PL/I (the Linux implementation) is validated.

PL/I on Linux: Iron Spring PL/I

For deployment in containers and modern Linux environments, Iron Spring PL/I is the available implementation:

FROM debian:bookworm-slim

# Install Iron Spring PL/I (x86-64 Linux)
# Download from ironspring.com/compilers
COPY ironspring-pli-linux-x86_64.tar.gz /tmp/
RUN tar -xzf /tmp/ironspring-pli-linux-x86_64.tar.gz -C /opt && \
    ln -s /opt/ironspring/bin/plicomp /usr/local/bin/plicomp

COPY src/ /app/src/
WORKDIR /app

# Compile PL/I programme to native binary
RUN plicomp -o banking_service src/main.pli

EXPOSE 8080
CMD ["./banking_service"]

An example PL/I HTTP service structure (calling a C socket layer):

/* PL/I service using external C HTTP layer */
main: PROCEDURE OPTIONS(MAIN);
   DECLARE request_body CHARACTER(4096) VARYING;
   DECLARE response CHARACTER(4096) VARYING;
   DECLARE amount FIXED DECIMAL(15,2);

   /* Read HTTP request via C interop */
   CALL read_http_request(request_body);

   ON CONVERSION BEGIN;
      response = '{"error":"invalid_amount","code":400}';
      CALL send_http_response(400, response);
      RETURN;
   END;

   amount = DECIMAL(request_body, 15, 2);

   IF amount <= 0 THEN DO;
      response = '{"error":"amount_must_be_positive","code":422}';
      CALL send_http_response(422, response);
   END;
   ELSE DO;
      CALL process_payment(amount, response);
      CALL send_http_response(200, response);
   END;
END main;

EU Regulatory Alignment

DORA (Digital Operational Resilience Act, Regulation (EU) 2022/2554): PL/I on IBM z/OS is the archetypical DORA-compliant runtime. DORA requires financial entities to demonstrate operational resilience, ICT risk management, and continuity of critical business functions. IBM z/OS mainframes — with PL/I applications that have been running continuously for 30+ years without data loss or unplanned downtime — represent precisely the kind of "proven resilience" that DORA's Art. 5-8 ICT risk management framework rewards. Iron Spring PL/I on Linux delivers the same language semantics in containerised environments subject to sota.io's EU-native infrastructure guarantees.

MiFID II (Directive 2014/65/EU) — Transaction Reporting: PL/I's FIXED DECIMAL arithmetic is mandated by the mathematical requirements of MiFID II transaction reports. Notional amounts, prices, and quantities in MiFID II reports must be exact decimal representations — IEEE 754 floating-point is not acceptable for regulatory data. PL/I applications generating MiFID II reports for European broker-dealers and investment firms inherit this compliance property from the language itself.

GDPR Art. 25 (Data Protection by Design and by Default): PL/I's explicit storage classes implement GDPR Art. 25 at the language level. AUTOMATIC variables cannot outlive their containing block — personal data stored in AUTOMATIC structures is automatically purged when the procedure returns. BASED (heap-allocated) variables require explicit FREE — creating a clear audit point for the disposal of personal data. The storage class system enforces data lifecycle management by construction rather than by programmer discipline.

GDPR Art. 32 (Security of Processing): IBM z/OS — the platform on which production PL/I runs — implements pervasive encryption at rest and in transit via z/OS Data Set Encryption and TLS 1.3. PL/I programmes running on z/OS inherit these security guarantees without modification. For new PL/I development on Linux via Iron Spring PL/I on sota.io, TLS termination, at-rest encryption, and network isolation are provided by sota.io's infrastructure layer.

EU AI Act Art. 9 (Risk Management — VDM Connection): The Vienna Development Method, which grew from IBM Vienna's work on PL/I semantics, is a valid tool for producing the formal specifications and verification evidence required by EU AI Act Art. 9 for high-risk AI systems. An organisation building a high-risk AI application (credit scoring, medical diagnosis, biometric identification) can use VDM-SL (ISO 13817-1) to formally specify the system's behaviour and carry the proof obligations required by Art. 9(1). The IBM Vienna heritage connects PL/I directly to the most demanding current requirements of EU AI regulation.

The Wirth Connection: IBM Vienna and ETH Zürich

The IBM Vienna Research Laboratory and ETH Zürich were not isolated institutions. They were nodes in the same European computer science network. When Niklaus Wirth was designing Pascal at ETH Zürich in 1968–1970, he was well aware of the VDL work at IBM Vienna — the formal semantics tradition shaped how Wirth thought about language definition. Pascal's clean, formally definable semantics (compared to PL/I's enormous ambiguity) was in part a reaction to the difficulties that Bjørner and Lucas had encountered trying to formalise PL/I.

The lineage:

PL/I (IBM 1964)
    ↓
IBM Vienna Lab (Bjørner 🇩🇰 + Lucas 🇦🇹 + Bekič 🇭🇷, 1966–1969)
    → VDL → VDM (VDM-SL, ISO 13817-1)
    → EU safety standards: DO-178C, ISO 26262, EU AI Act Art. 9

Reaction to PL/I's complexity →
    Pascal (Wirth 🇨🇭, ETH Zürich 1970) — clean, formally definable
    → Free Pascal → Turbo Pascal (Hejlsberg 🇩🇰) → Delphi → C# → TypeScript

PL/I itself →
    z/OS PL/I: EU banking backbone (Deutsche Bank 🇩🇪, BNP Paribas 🇫🇷, ING 🇳🇱)
    Iron Spring PL/I: Linux/Docker for modern containerised deployment

Why Deploy PL/I on sota.io

GDPR-compliant infrastructure by default: All services run on German infrastructure. Your data does not leave the EU. No Privacy Shield concerns, no Schrems-II risk, no EU Data Act complications. For PL/I applications handling financial data, GDPR Art. 32 compliance is built into the infrastructure layer.

Containerised PL/I without DevOps overhead: Iron Spring PL/I compiles PL/I to native Linux x86-64 binaries. Wrap the binary in a Docker container, add a sota.io Dockerfile, and you have a running service without managing servers, load balancers, or TLS certificates.

Managed PostgreSQL 17 with exact decimal support: sota.io includes managed PostgreSQL 17 — which supports NUMERIC(precision, scale) for exact decimal arithmetic. PL/I's FIXED DECIMAL(15,2) maps directly to PostgreSQL's NUMERIC(15,2). Financial applications that require the same arithmetic guarantees in both the application layer and the database layer can achieve this on sota.io.

Formal methods traceability: If you are building EU AI Act-regulated systems and using VDM for formal specification, running your implementation on sota.io gives you a single EU-hosted environment for both the VDM specification tools (Overture IDE) and the production services. All verification artefacts, model files, and compliance documentation stay in the EU.

EU banking modernisation patterns: PL/I's persistence in EU banking creates a well-understood modernisation problem: how to expose PL/I business logic via modern APIs without rewriting 50 years of validated financial logic. sota.io's container model supports exactly this pattern — a PL/I binary behind an nginx reverse proxy or a thin Node.js API gateway, keeping the PL/I calculation engine intact while adding REST/JSON interfaces.