DCL

DCL — the DIGITAL Command Language — is the command-line interpreter and scripting language developed by Digital Equipment Corporation (DEC) for its minicomputer and mainframe-class operating systems. Although it appeared on a family of DEC operating systems including IAS, RSX-11, RT-11, and RSTS/E, DCL is most closely associated with VAX/VMS (later OpenVMS), where it became the definitive example of verb-qualifier command design and remains in active use nearly fifty years later.

History & Origins

DCL traces its roots to the mid-1970s. It was originally implemented as the Program Development System (PDS) on DEC’s IAS operating system and was later ported to RSX-11M, RT-11, and RSTS/E under the DCL name. The language’s defining form, however, emerged with the launch of the VAX architecture.

The VAX-11/780 was announced on October 25, 1977, and VAX/VMS V1.0 shipped in August 1978 with DCL as its primary command interface. From that point forward, DCL and VMS (later OpenVMS) evolved together, with each major VMS release adding new DCL commands, lexical functions, and control constructs.

Unlike the informal, evolved shells of the Unix world, DCL was designed top-down as part of an integrated operating system. It shares its design philosophy with DEC’s other operating systems: commands should be English-like, parseable by minimum-unique abbreviation, and consistently structured across the entire system.

Design Philosophy

DCL’s syntax is built on a single, uniform model:

$ VERB/qualifier=value parameter1 parameter2 ...

Every command begins with a verb (COPY, DIRECTORY, PRINT, SHOW, SET). Qualifiers — prefixed with a forward slash — modify the verb’s behavior, and may take values. Parameters follow. The result is a command line that reads almost like structured English:

$ COPY/LOG/REPLACE *.TXT [.BACKUP]
$ DIRECTORY/SIZE/DATE/OWNER DISK$USER:[SMITH...]*.COM
$ PRINT/QUEUE=LASER/COPIES=3/NOTIFY REPORT.TXT

This design has several consequences:

1. Discoverability. Because verbs and qualifiers follow a consistent scheme, learning one command helps you guess others. /LOG, /CONFIRM, and /NOTIFY behave similarly across file operations.
2. Minimum uniqueness. Commands and qualifiers can be abbreviated to the shortest unambiguous prefix. DIRECTORY can be typed DIR or even DI; /REPLACE can be /REP.
3. Case insensitivity. DCL treats command names, symbol names, and most arguments as case-insensitive. File specifications are converted to uppercase by default.
4. Integrated help. The HELP command is organized around the same verb/qualifier tree, letting users navigate documentation with the same mental model they use to type commands.

Key Features

Symbols and Logical Names

DCL has two distinct mechanisms for named values: symbols (variables in command procedures) and logical names (system-wide or per-process name translations).

$ COUNT = 10
$ NAME = "OpenVMS"
$ WRITE SYS$OUTPUT "Count is ", COUNT, ", name is ", NAME

$ DEFINE REPORTS_DIR DISK$DATA:[REPORTS]
$ COPY REPORT.TXT REPORTS_DIR:

Logical names are resolved by the file system itself, so they work transparently across commands and applications. They are the VMS equivalent of mount points, environment variables, and symbolic links, all unified under a single abstraction.

Lexical Functions

Lexical functions — names beginning with F$ — are DCL’s equivalent of built-in functions. They return information about the environment, manipulate strings, or query the system:

$ TODAY = F$TIME()
$ USER = F$GETJPI("", "USERNAME")
$ UPPER = F$EDIT("mixed case text", "UPCASE")
$ PARTS = F$ELEMENT(0, ".", "FILE.TXT")
$ EXISTS = F$SEARCH("LOGIN.COM")

There are dozens of lexical functions covering process information (F$GETJPI), system information (F$GETSYI), device information (F$GETDVI), file parsing (F$PARSE, F$SEARCH), and string manipulation (F$EDIT, F$EXTRACT, F$LOCATE, F$ELEMENT).

Command Procedures

DCL scripts are stored in files with the .COM extension and are executed with the @ command:

$ @BACKUP_NIGHTLY.COM

A command procedure is a sequence of DCL commands, with control-flow constructs built from IF, GOTO, labels, and CALL for subroutines:

$ ! nightly_backup.com — back up user directories
$ ON ERROR THEN GOTO FAIL
$ SET NOON
$ !
$ START_TIME = F$TIME()
$ WRITE SYS$OUTPUT "Backup started at ", START_TIME
$ !
$ BACKUP/LOG DISK$USER:[000000...]*.* TAPE:USERS.BCK/SAVE_SET
$ IF $STATUS .NE. 1 THEN GOTO FAIL
$ !
$ WRITE SYS$OUTPUT "Backup complete"
$ EXIT
$ !
$FAIL:
$ WRITE SYS$OUTPUT "Backup failed with status ", $STATUS
$ EXIT 2

Notably, DCL historically lacked a DO-WHILE or FOR loop construct — loops were implemented with labels and GOTO, a quirk that persists in the language today. Later versions added CALL / SUBROUTINE / ENDSUBROUTINE for structured subroutines.

Data Types

DCL symbols are dynamically typed and support strings, integers, bit arrays, arrays, and Booleans. Floating-point arithmetic is notably not supported in DCL itself; numeric computation is limited to integer operations, which is unusual among general-purpose scripting languages.

$ N = 42
$ S = "Hello, VMS!"
$ FLAG = "TRUE"
$ !
$ IF N .GT. 10 THEN WRITE SYS$OUTPUT "Big number"
$ IF S .EQS. "Hello, VMS!" THEN WRITE SYS$OUTPUT "Match"

Note the operator spellings: .EQ., .NE., .GT., .LT. for numeric comparisons and .EQS., .NES., .GTS., .LTS. for string comparisons — a legacy of DCL’s Fortran-influenced ancestry.

Error Handling and $STATUS

Every DCL command sets a 32-bit condition code in the $STATUS symbol, with the low-order bits encoding severity: success (1), informational (3), warning (0), error (2), or fatal (4). The ON statement lets procedures respond to different severities:

$ ON WARNING THEN CONTINUE
$ ON ERROR THEN GOTO CLEANUP
$ ON SEVERE_ERROR THEN EXIT $STATUS

This structured approach to status propagation was ahead of its time and remains one of DCL’s most distinctive features.

Hello, World

A minimal DCL command procedure:

$ ! hello.com
$ WRITE SYS$OUTPUT "Hello, World!"

Run it with:

$ @HELLO
Hello, World!

Operating Systems Using DCL

DCL has shipped on multiple DEC operating systems over its lifetime:

Current Relevance

OpenVMS — and therefore DCL — is actively developed by VMS Software, Inc. (VSI), which licensed the operating system from HP in 2014 (prior to the 2015 split that created Hewlett Packard Enterprise). VSI shipped OpenVMS V9.2 for x86-64 in 2022, bringing DCL to commodity hardware and modern hypervisors for the first time in the operating system’s history, and followed with V9.2-3 in December 2024.

DCL continues to be used in industries where OpenVMS’s reputation for reliability, security, and long uptimes remains valuable:

• Financial services, including stock exchanges, clearing houses, and bank back-office systems
• Manufacturing and process control, where older plants run VMS-based MES and SCADA systems
• Telecom billing and provisioning, often running on VMS systems deployed decades ago
• Defense and government applications with strict certification and long-lifecycle requirements
• Healthcare systems, particularly laboratory and hospital information systems

Because OpenVMS is proprietary and has historically been tied to specific DEC / HP / HPE hardware, there is no officially supported Docker image for DCL. Developers working with DCL typically do so through a licensed OpenVMS instance, either on physical hardware or via the VSI x86-64 distribution running under a hypervisor such as KVM or VMware.

Why It Matters

DCL represents a design road not taken by the rest of the computing industry. While Unix shells evolved organically from small, composable tools and the Windows command line borrowed heavily from CP/M and MS-DOS, DCL was designed from the top down as part of an integrated operating system. It pursued consistency, discoverability, and English-like readability at a level few other shells have matched.

Its verb-qualifier syntax influenced the conventions of many later command-line tools — the /qualifier style survives in Windows cmd.exe and in PowerShell’s named parameters, although these were developed independently. More broadly, DCL stands as an argument that shells can be designed, not merely grown, and that a coherent command language can outlast the hardware it was born on.

After nearly half a century, DCL is still the first thing a user sees when they log in to an OpenVMS system — the $ prompt, waiting for a verb.