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
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 (
&1to&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:
- 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.
- 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:
| Category | Examples | Purpose |
|---|---|---|
| Execution control | &IF, &GOTO, &LOOP, &SKIP, &EXIT, &ERROR, &CONTINUE | Branching, looping, error handling, return codes |
| Terminal and stack I/O | &TYPE, &READ, &STACK, &BEGTYPE, &BEGSTACK, &END, &PUNCH, &SPACE | Talking to the user, feeding input to other commands |
| Built-in functions | &CONCAT, &DATATYPE, &LENGTH, &LITERAL, &SUBSTR | Simple token manipulation |
| Special variables | &INDEX, &RETCODE, &GLOBAL, &LINENUM, &READFLAG, &TYPEFLAG | Argument count, last return code, recursion level, line number |
| Display control | &CONTROL, &TIME | Whether 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&GOTOand&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
&ERRORaction says so, and the return code is available in&RETCODE. - Console-stack programming.
&STACKand&BEGSTACKput 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 ALLand&BEGSTACK ALLgive 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:
| |
How it works:
&INDEXholds the number of arguments. If fewer than two were given, the EXEC exits with return code 12.&1and&2are the file name and file type. Unless the file type isTABLE, control jumps to the label-EDIT.- The lines between
&BEGSTACKand&ENDgo into the console stack unchanged. TheEDITcommand 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&nsubstitution. 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
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.