PROTEL: The Language That Ran the Switch, and Why I Brought It Back

Before there was a cloud, before “five nines” was a slide in somebody’s pitch deck, there were telephone switches that simply could not go down. Northern Telecom’s DMS family of digital switches was built for exactly that, and the software inside them was written in a language most programmers have never heard of: PROTEL, the Procedure Oriented Type Enforcing Language.

I spent a good part of my career inside that world. I was the Dev and Test manager for the initial releases of the Nortel DMS-500, the product that combined the DMS-100 and DMS-250 into a single switch. Later I led Sales Engineering and Product Management at AudioCodes and Netrake, and I initiated the Nortel–AudioCodes relationship. PROTEL was the common thread through the first part of that story, and it is the reason I recently did something a little unusual: I brought it back.

Born at Bell-Northern Research

PROTEL was designed in 1975 at Bell-Northern Research (BNR), Northern Telecom’s research and development arm, for one job: producing the software for digital switching systems. The need arose directly out of the development of the DMS-100 family of telephone switches. That is how the BNR engineers themselves described it in their 1981 ICSE paper, Experience With a Modular Typed Language: PROTEL (Cashin, Joliat, Kamel and Lasker).

The language was introduced publicly two years earlier at IEEE COMPSAC 1979, in Protel: a high level language for telephony by Foxall, Joliat, Kamel and Miceli. One design decision in that paper still makes me smile. As it is quoted from the paper: “it was decided that PROTEL should be the only implementation language — no assembly language was provided for DMS-100.” In the mid-1970s, for a hard real-time system, BNR took away the assembler. If you wanted to make the switch do something, you did it in a strongly typed high-level language, and the compiler checked your work.

By the time of the 1981 paper, the team reported more than 750,000 lines of PROTEL source, a development and support organization of nearly 200 people, and a toolchain (compiler, linker, loader, library control system) that ran both on IBM/370 hosts and on the DMS-100 processor itself. PROTEL was not only used for telephony features; the authors note it was also used to write compilers, linkers, operating systems and database systems. Over the following decades that codebase grew enormously. The PROTEL 2026 project’s own history puts it at tens of millions of lines written by Nortel teams for production switches around the world.

What made PROTEL different

PROTEL is a block-structured, procedure-oriented language in the ALGOL and Pascal family. Its designers extended the Pascal of the day with separate (external) compilation and richer data structures. A few features stand out:

• Types that mean what they say. You can declare a ranged type such as {0 TO 255}, and assigning something outside that range is a type error, not a surprise in the field.
• Left-to-right assignment. PROTEL assigns with ->, which everyone I worked with called “gazinta” (as in “goes into”). n -> i -> result; reads exactly the way the data flows.
• Tables, sets, structures and descriptors. Descriptors carry an array’s location and size, which gives bounds-checked slices and made dynamically sized tables practical in a switch that allocated store at run time.
• Modules checked across boundaries. The 1981 paper describes “imbedding”: the compiler writes symbolic information about each section into its object file and reads it back for every section that depends on it, so references between modules are type-checked at compile time. BNR counted PROTEL among the first modular typed languages, in the same conversation as MESA and Ada.

The philosophy is right there in the name. The field is a terrible place to find a bug. If the compiler can catch it, the customer never has to.

SOS, PLS and the integrated platform

PROTEL never lived alone. On the DMS it sat alongside the Support Operating System (SOS), which Nortel’s own documentation describes as the software that sets up the environment for loading and executing application software, including the Nucleus, the file system, the Command Interpreter (CI) and the loader. SOS itself was written in PROTEL. So were the call processing software (CALLP) and the Product Library System (PLS), the tooling that managed source, editions and builds. A 1982 paper in the IEEE Transactions on Communications by Penney and Williams of BNR, The Software Architecture for a Large Telephone Switch, sums up the approach as a strongly typed high-level language, independent design and compilation of modules, and an automated program library and problem reporting system.

Anyone who worked on DMS loads will remember the practical side of that: modules with edition suffixes, software that could be loaded and replaced while the office stayed in service, and a culture where the build system, the language and the operating system were designed as one thing. A lot of what we now call modern software engineering practice was already happening there decades ago.

PROTEL-2 and objects

PROTEL kept evolving. A later version, PROTEL-2, added object-oriented extensions. According to the recollections of former Nortel engineer Frazer Clement on his message passing blog, this happened in the mid-1990s, in phases, and was tied to a large Nortel project called the Generic Services Framework, an object-oriented reimplementation of call processing. As he describes it, PROTEL-2 used single inheritance from a common root class, explicitly overridable methods, abstract classes, read-only methods and a GENERIC keyword for type-parameterized classes. Even then, objects were added on top of a procedural core rather than replacing it, which is exactly the balance I wanted to keep.

Back on the line: PROTEL 2026

When Nortel went through bankruptcy, PROTEL was left for dead along with it. I thought that was a waste of a genuinely good idea, so I wrote PROTEL 2026, a free, open-source reimplementation under the GNU GPL v3. You can read the story and see the language in action on the PROTEL 2026 project page at Binary Systems, and get the compiler, manuals and examples from the PROTEL 2026 source repository on GitHub.

The toolchain includes Pc, the compiler, which parses and type-checks PROTEL and then drives GCC or clang++ to produce native code; Pc!, which lets you run a .P file as a script with a shebang line; Pb, the Beautifier, which uppercases reserved keywords; and a GNU Emacs protel-mode. It interoperates with C, C++, Rust, Swift, Python and Java through the C calling convention, and a --classical switch restores the case-insensitive identifier rules of the old DMS code. The repository also ships an Introductory Manual and a Reference Manual. Here is the factorial example from the Introductory Manual:

SECTION factorial_demo;

TYPE integer {-32768 TO 32767};

DCL factorial PROC(n integer) RETURNS integer IS
BLOCK
   DCL result, i integer;
   n -> i -> result;
   WHILE (i - 1 -> i) > 1
   DO
      i * result -> result;
   ENDDO;
   RETURN result;
ENDBLOCK;

This is not retro computing. It is smart computing.

A ready-made telecom lab: PROTEL in VoxBox

PROTEL comes pre-packaged in VoxBox, Binary Systems’ Asterisk PBX distribution. The VoxBox 2026 installer pulls the latest PROTEL 2026 toolchain from GitHub and installs Pc, Pb, Pc! and the Emacs protel-mode under /usr/local/protel, with the commands linked into /usr/local/bin so every account on the box can use them. Alongside it you get Asterisk compiled from source (22 LTS by default, or 23), FreePBX 17 web management and emacs-nox.

Because VoxBox runs on Debian or RHEL-family Linux, on bare metal or as a virtual machine, a VoxBox VM makes a ready-made telecom development environment: a working PBX and a strongly typed systems language in one place. It is a good way to learn PROTEL and experiment with call-processing ideas. If you would rather install PROTEL on its own, it builds on macOS and UNIX/Linux with Python 3, a C++20 compiler and make.

Why it still matters

The engineers at BNR worked out, half a century ago, that reliability comes from catching mistakes early, keeping interfaces explicit and treating the language, the build system and the operating system as one design. Those lessons did not expire when the company did. PROTEL deserves to be used, not just remembered. To the BNR compiler team and every Nortel developer who wrote PROTEL that kept the dial tone on: thank you. It is good to have it back on the line.