Est. 1967 Beginner

EXEC

The original command procedure language of IBM's CP/CMS and VM/CMS - ampersand-driven scripts that turned sequences of commands into new commands, and the ancestor of EXEC 2 and REXX.

Created by IBM Cambridge Scientific Center (first version attributed to Stuart Madnick); extended at MIT Lincoln Laboratory and IBM Research

Paradigm Procedural, Command Procedure (shell scripting)
Typing Typeless (all values are blank-delimited tokens)
First Appeared 1967
Latest Version CMS EXEC processor still shipped with z/VM (documented in z/VM 7.4, 2024)

EXEC (often called CMS EXEC, and later nicknamed “EXEC Classic”) was the first command procedure language of IBM’s interactive time-sharing systems. It was born in the Cambridge Monitor System (CMS) under CP/CMS in the mid-1960s and carried forward into VM/370 and every later VM release. An EXEC was a file of CMS commands. The interpreter read it line by line, replaced ampersand variables with arguments, and passed each line to the system, so a user could build a new “command” out of existing ones. Over time it gained labels, branching, loops and a handful of built-in functions. That made it one of the earliest scripting languages to work as a programming language in its own right, and it led directly to EXEC 2 and then REXX.

History and Origins

A RUNCOM for CMS

CMS was built at IBM’s Cambridge Scientific Center in Massachusetts by people who knew MIT’s Compatible Time-Sharing System (CTSS) well. CTSS had RUNCOM, a facility for running a stored list of commands, and CMS needed something similar.

The 1978 IBM Research report that defined EXEC 2 includes a short history of its ancestor. It says the first version of CMS EXEC “appears to have been written at the IBM-Cambridge Scientific Center around 1966”, that it “was modelled after ‘RUNCOM’ in CTSS”, and that it ran a sequence of commands made of eight-byte tokens, with parameter substitution through &1, &2, and so on. The report also says that “nobody seems to want credit for the first version”.

Melinda Varian’s history VM and the VM Community: Past, Present, and Future gives the credit to Stuart Madnick, a 21-year-old MIT student who began working on CMS in June 1966. During the following school year he added several functions to CMS, “including the first EXEC processor, which was originally called the COMMAND command”. In the same period Madnick also wrote the CMS text formatter Script.

The earliest dated documentation found for this page is a CMS User’s Guide page dated 31 July 1967. It describes the $ command, which runs a file of type EXEC as a sequence of CMS commands and substitutes the arguments into its &n operands. CP-40/CMS had gone into production at Cambridge in January 1967. The 1967 date used here therefore marks the earliest documented appearance; the processor itself may date from late 1966.

From command list to language

The first EXEC could only substitute arguments. The 1978 report says the change into a programming language “took place in 1967-68 at M.I.T.’s Lincoln Labs, during a joint study with the Scientific Center”. The principal designers were Francis Belvin, Harold Feinleib, Oliver Selfridge and Joel Winnett, and Roger Banks did the programming during a summer job. They added user-defined variables, the assignment statement, and most of the control words: &IF, &GOTO, &LOOP, &STACK, &READ and others. Thomas Rosato at the Scientific Center installed the changes in IBM’s second release of CMS.

The CMS User’s Guide pages for this new EXEC are dated 1 November 1968. They note that it is “completely compatible with EXEC files created for use with the previous version of EXEC command except that in this version only one command is allowed per line”. The same pages state these limits:

  • up to 30 numeric arguments (&1 to &30)
  • at most 4,095 lines per EXEC file
  • recursion to a depth of about 16, because each level used about 1,200 bytes of free storage

Formalization and VM/370

In 1971 Christopher Stephenson at IBM Research in Yorktown Heights extended and formalized the language. He set down general rules for replacing EXEC variables and introduced predefined functions, and James Walsh in Cambridge built the extensions into CMS.

When IBM announced VM/370 in 1972, this time as a supported product, EXEC came with it. The VM/370 Introduction manual (GC20-1800-0, July 1972) described EXEC procedures as new commands made from existing ones, with “statements analogous to the GOTO, IF, and LOOP statements familiar to high level language users”. It also described a special EXEC run automatically when CMS starts, so that each user’s session could be set up from their own “profile”. IBM documented the language in its own manual, the VM/370 EXEC User’s Guide (GC20-1812, first edition copyright 1972).

Design Philosophy

EXEC was designed to run commands; logic came second. Two ideas set its character, and the EXEC 2 report notes that both lasted through every later version:

  1. Blank is the delimiter. A line is split into blank-separated words, called tokens, and each token is truncated to eight characters, the length of a CMS file name or command name.
  2. The ampersand marks what is not literal. Most programming languages quote literals and leave names bare. EXEC did the opposite: plain words were literal text sent to CMS, and anything starting with & was a variable, a control word or a built-in function.

So the most common kind of line, a CMS command, needed no special syntax at all. Any line that did not begin with an asterisk (a comment) or an ampersand was passed to CMS to be run, after its variables had been substituted. Mike Cowlishaw later pointed out that this design suited programs made mostly of commands. It became awkward once people wrote large programs that were mostly logic, and that problem eventually led to REXX.

Key Features

The VM/370 EXEC User’s Guide (1975 printing for Release 2 PLC 11) describes the mature language. Besides plain commands, it groups the control statements into three categories: execution control statements, built-in functions and special variables. The table below splits the execution control statements further by purpose:

CategoryExamplesPurpose
Execution control&IF, &GOTO, &LOOP, &SKIP, &EXIT, &ERROR, &CONTINUEBranching, looping, error handling, return codes
Terminal and stack I/O&TYPE, &READ, &STACK, &BEGTYPE, &BEGSTACK, &END, &PUNCH, &SPACETalking to the user, feeding input to other commands
Built-in functions&CONCAT, &DATATYPE, &LENGTH, &LITERAL, &SUBSTRSimple token manipulation
Special variables&INDEX, &RETCODE, &GLOBAL, &LINENUM, &READFLAG, &TYPEFLAGArgument count, last return code, recursion level, line number
Display control&CONTROL, &TIMEWhether commands, return codes and timing information are typed at the terminal

Other notable traits:

  • Labels start with a dash (for example -EDIT) and are the targets of &GOTO and &LOOP.
  • Arithmetic is limited to integers in assignment statements such as &X = &X + 1.
  • Error handling. A failing CMS command does not stop the EXEC unless an &ERROR action says so, and the return code is available in &RETCODE.
  • Console-stack programming. &STACK and &BEGSTACK put lines into the terminal input buffer, so a later command such as the editor reads them as if the user had typed them. This was the main way an EXEC could drive an interactive program.
  • Recursion. An EXEC can call other EXECs, including itself. The 1975 guide allows up to 19 levels of recursion.
  • Line length. Only the first 72 columns of each record are processed by default. &BEGTYPE ALL and &BEGSTACK ALL give access to longer lines.

Example

The following is adapted from the 1975 VM/370 EXEC User’s Guide. When the file being edited has filetype TABLE, it stacks three editor subcommands before starting the CMS Editor, so the user does not have to type them:

1
2
3
4
5
6
7
8
&IF &INDEX LT 2 &EXIT 12
&IF &2 NE TABLE &GOTO -EDIT
&BEGSTACK
CASE M
TABSET 1 10 20
SHORT
&END
-EDIT EDIT &1 &2 &3 &4 &5 &6

How it works:

  • &INDEX holds the number of arguments. If fewer than two were given, the EXEC exits with return code 12.
  • &1 and &2 are the file name and file type. Unless the file type is TABLE, control jumps to the label -EDIT.
  • The lines between &BEGSTACK and &END go into the console stack unchanged. The EDIT command then reads them as its first three subcommands.

Evolution

EXEC had two successors, and none of the three replaced the others outright.

  • EXEC 2 came from Christopher Stephenson at IBM Research. He proposed it in a paper at the Fourth Symposium on Operating System Principles in 1973; it was defined and first implemented in 1976, and gained user-defined subroutines and functions in 1977. It kept EXEC’s look but removed the eight-byte token limit, added better string handling and arithmetic, and could send commands to other environments such as editors. CMS tells the two apart by the first line: an EXEC 2 file starts with &TRACE. EXEC 2 became a supported product in VM/System Product Release 1, which shipped late in 1980.
  • REXX. Mike Cowlishaw conceived it on 20 March 1979. In his words, the scripts being written in EXEC 2 had become “cumbersome for the large and complex programs and macros”. REXX turned the convention around: literal strings are quoted, and keywords and variable names are left bare. A REXX program is recognized because its first line is a /* ... */ comment.

In the meantime, IBM published an Installed User Program of CMS EXEC enhancements (5796-PJA, reportedly first issued in January 1977). According to its description it added services such as date and time, file reading and writing, and global variables to CMS EXEC through a helper command, EXSERV.

Current Relevance

EXEC has not been extended for decades, but it has not been removed either. The z/VM 7.4 CMS User’s Guide (SC24-6266-74, © 2024) still lists three exec processors: REXX/VM, EXEC 2 and CMS EXEC. It describes how CMS examines the first line of an exec file to choose between them. It also says that “the three interpreters coexist, so exec programs will continue to correctly process with no user modifications, regardless of the language”. The CMS EXEC processor (module DMSEXT) is loaded as a permanent nucleus extension, and LISTFILE ... (EXEC still produces a file named CMS EXEC that is written in the original language.

New VM work is done almost entirely in REXX. EXEC now lives on as a compatibility layer for very old procedures and as a piece of mainframe history.

Why It Matters

  • One of the earliest interactive scripting languages. EXEC carried CTSS’s RUNCOM idea into IBM’s interactive systems and then grew it, during 1967-68, into a language with variables, conditionals, loops and recursion. That happened years before command languages of that kind were common elsewhere.
  • The start of the REXX family. The line from CMS EXEC to EXEC 2 to REXX is well documented. Through REXX, ideas that began in EXEC reached OS/2, AmigaOS (as ARexx), TSO and z/OS.
  • The value of a user-extensible system. The VM/370 Introduction presented EXEC as a way for users to define their own commands, and the CMS culture of users writing their own tools rested on it. VMSHARE, the electronic conference that Varian credits with helping VM survive, was first written in EXEC.

Sources and Verification Notes

  • Earliest documentation: CP-67/CMS User’s Guide (IBM form 320-2015, October 1967, with revisions to 1970), on bitsavers. The $ command page dated 7-31-67 refers to EXEC files and &n substitution. The EXEC pages dated 11/01/68 describe the control-word version, its limits and its compatibility note.
  • History of EXEC and EXEC 2: W. E. Daniels and R. W. Ryniker II, adapted from C. J. Stephenson, EXEC 2: A Computer Language for Word Programming, IBM Research Report RC 7268, 25 August 1978, section “History and Acknowledgements”.
  • Madnick’s authorship and the name “COMMAND command”: Melinda Varian, VM and the VM Community: Past, Present, and Future (1991 and later revisions). The 1978 IBM report does not name the original author, so this attribution rests on Varian.
  • VM/370 features: VM/370 Introduction GC20-1800-0 (July 1972) and VM/370 EXEC User’s Guide GC20-1812-1 (April 1975).
  • REXX origin date and quotations: Mike Cowlishaw, “The early history of REXX”, speleotrove.com.
  • Current status: z/VM 7.4 CMS User’s Guide, SC24-6266-74.
  • 5796-PJA: an IBM 1983 Service for Consultants program index lists it as “CMS EXEC Enhancements”; the January 1977 date, the title “EXEC Language Extensions” and the EXSERV details were not checked against the program’s own documentation.
  • Not verified: the exact month in which the first EXEC/COMMAND processor ran, and which numbered CMS release first included the Lincoln Laboratory extensions.

Timeline

1966
Around 1966, the first CMS command-file processor is written at IBM's Cambridge Scientific Center, modelled on CTSS RUNCOM. Melinda Varian credits MIT student Stuart Madnick, who called it the COMMAND command
1967
CP-40/CMS goes into production in January; a CMS User's Guide page dated 31 July 1967 already documents files of type EXEC with &1, &2, ... argument substitution
1968
After a 1967-68 joint study with MIT Lincoln Laboratory, EXEC gains variables, assignment and control words (&IF, &GOTO, &LOOP, &STACK, &READ); CMS User's Guide pages dated 1 November 1968 document the new version
1971
Christopher Stephenson at IBM Research, Yorktown Heights, formalizes the variable-replacement rules and adds built-in functions; James Walsh incorporates the extensions into CMS
1972
IBM's VM/370 Introduction (July 1972) presents the CMS EXEC processor, including a special EXEC run automatically to set up each user's "profile", as a standard feature of the newly supported VM/370
1976
EXEC 2 is defined and first implemented at IBM Research; in August, Dave Smith announces the VMSHARE conferencing system, written in CMS EXEC, at SHARE XLVII in Montreal
1977
IBM releases an Installed User Program of CMS EXEC enhancements (5796-PJA), reportedly first documented in January 1977
1979
Mike Cowlishaw conceives REX on 20 March 1979 as a replacement for EXEC 2, the descendant of EXEC
1980
VM/System Product Release 1 ships late in 1980 with EXEC 2 as a supported alternative to the original CMS EXEC
2024
The z/VM 7.4 CMS User's Guide still lists the CMS EXEC processor next to EXEC 2 and REXX/VM, so old EXECs keep running unchanged

Notable Uses & Legacy

PROFILE EXEC

Every CMS user's login customization (accessing disks, setting terminal options, defining synonyms) ran from a special EXEC called PROFILE EXEC, run automatically when CMS starts. The first VM/370 Introduction (1972) described this start-up "profile" EXEC, and the 1975 *EXEC User's Guide* documents it by name.

VMSHARE

The SHARE user group's VMSHARE electronic conference, announced in August 1976 by Dave Smith of Tymshare, was first implemented in CMS EXEC. Charles Daney replaced it with a PL/I implementation in 1982.

MIT Lincoln Laboratory

In a 1967-68 joint study with the Cambridge Scientific Center, Lincoln Lab staff designed the variables, assignment statement and most of the control words that turned EXEC into a real programming language.

CMS EDIT macros

Under VM/370, EXEC files whose names began with a dollar sign served as macros for the CMS Editor, letting users add their own editor subcommands.

LISTFILE-generated command lists

The LISTF/LISTFILE command could write a file listing as an EXEC (a CMS EXEC), with argument slots in front of each file identifier. This was a standard way to run one command over many files, and z/VM still documents it.

Language Influence

Influenced By

RUNCOM

Influenced

EXEC 2 REXX

Running Today

Run examples using the official Docker image:

docker pull
Last updated: