Stratus VOS Command Macro
The built-in scripting language of Stratus VOS, used to automate commands, drive interactive programs, and build menu systems on fault-tolerant Stratus computers
Created by Stratus Computer (now Stratus Technologies / Penguin Solutions)
Stratus VOS Command Macro is the built-in scripting language of VOS (the Virtual Operating System, now OpenVOS), the proprietary operating system that runs Stratus Technologies’ fault-tolerant computers. A command macro is a text file—by convention ending in the .cm suffix—that combines ordinary VOS commands, calls to user programs, and special command macro statements. Those statements give the language its control flow: conditionals, loops, branches, variables, and error handling, all layered on top of the same command interpreter a user drives interactively at the VOS prompt. It is, in spirit, VOS’s answer to the Unix shell script or the DEC VMS command procedure: a way to turn a sequence of typed commands into a reusable, parameterized program.
A note on dating
The metadata for this page lists the 1980s as the language’s era, and that is the most honest framing available. VOS itself dates to the launch of Stratus’s first system in February 1982, and the command macro facility was part of the VOS environment from its early releases. Public sources describe the Command Macro Language as something VOS “introduced in its foundational releases during the 1980s” rather than pinning it to a single dated version, and Stratus’s own historical documentation is versioned by VOS release number rather than by calendar year for that period. This page therefore uses 1982—the year VOS first shipped—as an approximate first-appearance year, and treats the precise introduction of individual macro statements as undocumented. Where a specific year matters below, it is stated with appropriate hedging.
History & Origins
Stratus Computer, Inc. was founded in 1980 in Natick, Massachusetts by William Foster, Robert Freiburghouse, and Gardner Hendrie, with an early venture round reported at roughly $1.7 million. The company’s goal was fault-tolerant computing: machines that could keep running through hardware failures, aimed at online transaction processing where downtime is unacceptable. Roughly twenty-one months after founding, in February 1982, Stratus shipped its first system.
VOS was written for this hardware from the ground up, and it drew heavily on the design experience of the Multics project (the MIT/Bell Labs/General Electric—later Honeywell—operating system that also influenced Unix). Several of Stratus’s early engineers came from the Multics world and from Data General, and VOS’s emphasis on a rich, orthogonal command environment reflects that heritage. The command macro language sits squarely in that tradition: like Multics’s exec_com files and abbreviations, VOS command macros extend the interactive command language into a programmable one rather than introducing a separate scripting runtime.
Because it was designed as a high-security, transaction-processing environment, VOS shaped its macro language conservatively. Stratus deliberately limited the macro language’s capabilities in places—part of the reason it never grew user-defined functions—so that a scripting facility able to automate and impersonate interactive sessions could not become an unbounded security surface.
Design Philosophy
The command macro language embodies a few clear principles:
- The script is the command line. There is no separate interpreter grammar to learn for the “normal” parts of a macro—any command you can type at the VOS prompt can appear in a
.cmfile. The macro statements simply add the glue: control flow and variables. - Statements are keywords beginning with an ampersand. A command macro statement is a special VOS command usable only inside a macro, and its name always begins with
&—for example&echo,&label,&goto,&set_string,&if…&then…&else,&while, and&return. This makes macro control flow visually distinct from the commands being automated. - Parameterization via a declared interface. Arguments are declared in a parameters section at the top of the macro. VOS can then accept those arguments on the command line or present them through a structured form—the same
-formdisplay mechanism VOS uses for built-in commands—so a macro looks and behaves like a first-class command. - Automate the interactive as well as the batch. A macro can run interactively or non-interactively (in batch or as a started process), and it can drive other programs by capturing their prompts and supplying scripted responses.
Key Features
Ampersand-prefixed statements
Within a macro, the ampersand character & is overloaded: it introduces a macro statement, marks a comment line, delimits a parameter for substitution, and serves as the logical “and” operator. To emit a literal ampersand in output you double it. For example:
&display_line The variable &&source&& is about to be used.
displays:
The variable &source& is about to be used.
Line continuation is written with &+, allowing a long command to span multiple physical lines.
Control flow
The language provides the constructs expected of a job-control language:
| Construct | Purpose |
|---|---|
&if / &then / &else | Conditional execution |
&while | Looping while a condition holds |
&goto / &label | Unconditional branch to a named label |
| Boolean operations | Combine conditions (including & as logical and) |
&return | End macro execution and return to the caller |
The command processor reads and executes lines from the .cm file until it reaches the end of the file, encounters &return, or a program terminates in a way that abandons the file.
Variables and strings
Variables hold string values (set with statements such as &set_string) and are substituted into commands using the ampersand/apostrophe substitution syntax. This makes the language untyped in the practical sense—everything is text, interpreted according to the command it is handed to.
Parameters and forms
A macro declares its arguments in a parameters section. Callers can pass values positionally or by keyword on the command line, or fill them in on a generated form where each field represents an argument and shows its default. This is the same convention VOS uses for its built-in commands, so a well-written macro is indistinguishable from a native command to its users.
Error reporting
VOS command macros are noted for strong, structured error reporting, which—together with batch/started-process execution—makes them practical for unattended operational automation on production fault-tolerant systems.
Limitations
The language’s constraints are well known and frequently cited:
- No user-defined functions. There is no facility to define reusable, callable subroutines with their own local scope; factoring is done by splitting logic across separate
.cmfiles invoked as commands. - Weak include support. The language does not cleanly support include files, complicating code reuse across macros.
- Fragile string handling. String manipulation is error-prone, particularly with embedded control characters.
- Deliberately capped power. As a matter of security policy, Stratus intentionally restricted aspects of the language—especially given its ability to automate and respond to interactive programs.
These limitations reflect the language’s origins as an operations-and-automation tool for a hardened transaction-processing platform, not as a general-purpose programming language. For heavier work, VOS provides full compilers for PL/I, COBOL, Pascal, FORTRAN, C (both a native VOS C and GCC), and C++, and command macros typically orchestrate those compiled programs rather than replace them.
Evolution
The command macro language did not change dramatically, but the platform beneath it migrated repeatedly, carrying VOS and its macros to each new architecture:
- Motorola 68000 family — the original FT and XA series.
- Intel i860 — the XA/R series.
- HP PA-RISC — the Continuum series; VOS 13.0 launched with Continuum in 1995.
- Intel Xeon (x86) — the ftServer / V Series line (the ftServer family was introduced in June 2002), where VOS runs on commodity Intel processors made fault-tolerant in hardware.
VOS also grew toward openness over time: Unix System V was integrated at the kernel level as Unix System Facilities (USF) in 1984, POSIX.1 support arrived in Release 14.3, and the GNU C/C++ compiler and gdb plus many POSIX commands arrived in Release 14.4. Reflecting that shift, Stratus renamed VOS to OpenVOS beginning with Release 17.0 (around 2010), and the product line has continued through the OpenVOS 19.x series. Throughout these changes, the command macro language remained the native scripting layer of the system.
Current Relevance
OpenVOS remains a supported, actively maintained product for organizations that run mission-critical, continuously available applications—historically concentrated in finance, payments, telecommunications, and industrial control, where the cost of downtime is high and application longevity is measured in decades. In those environments, command macros are still the everyday tool for operational automation: startup and shutdown sequences, scheduled maintenance, backups, and menu-driven operator consoles. Interest in the language today is largely tied to maintaining and modernizing these long-lived deployments; a community Visual Studio Code syntax-highlighting extension for VOS command macros is a small but telling sign that people are still reading and editing .cm files in the 2020s.
Why It Matters
The VOS command macro language is a clear example of a platform-defining scripting language: one whose entire reason for existing is to make a particular operating system’s command environment programmable. Like the VMS DCL command language on DEC systems or shell scripting on Unix, it shows how each major OS lineage of the early 1980s answered the same need—turning interactive commands into reusable programs—in its own idiom. Its conservative feature set is itself instructive: here is a scripting language whose designers chose to leave out functions and to cap its own power in the name of security and reliability, priorities that made sense for the fault-tolerant, high-assurance systems it was built to run. Decades later, those same systems—and their macros—are still running, which is perhaps the most fitting testament to the engineering philosophy behind them.
Sources: Stratus VOS — Wikipedia, Stratus Technologies — Wikipedia, Command Macro Language — Liquisearch, Punctuation: VOS Commands User (R089) — StrataDOC, VOS Commands Reference (R098) — StrataDOC, Stratus Continuum PA-RISC — OpenPA.net.
Timeline
Notable Uses & Legacy
Fault-tolerant transaction processing
Command macros automate operational tasks—batch jobs, backups, and application startup—on Stratus systems used for high-volume, continuously available transaction processing in banking, payments, and telecommunications
Menu-driven operator interfaces
A common VOS pattern is building menu systems entirely in command macros, presenting operators with numbered choices and dispatching to further macros or programs based on their selection
Program automation and prompt handling
Because macros can run non-interactively and capture a program's prompts to send scripted responses, they are used to drive interactive VOS applications unattended in batch or started-process mode
System administration
VOS system administrators use command macros to package routine maintenance—user provisioning, log rotation, and scheduled housekeeping—into reusable, argument-driven scripts stored as .cm files