Technical Capabilities
Having trouble finding what you need?
Get in touch with us, so we can answer your specific questions directly.
Get In Touch

VX/DCL – OpenVMS DCL

Overview

VX/DCL is a from-scratch reimplementation of the OpenVMS DIGITAL Command Language (DCL) that runs natively on Linux and Windows. It is a full command-line interpreter, not a shell wrapper: it has its own lexer, expression parser, symbol and logical-name machinery, and .COM command-file engine, so existing procedures and DCL-based automation run without modification. Interactive login runs SYLOGIN.COM and the user's LOGIN.COM in the same order as VMS.

The interpreter ships more than 120 built-in verb handlers and 43 F$ lexical functions, and reproduces VMS file-spec handling through the VX/RT runtime, including automatic VMS-to-Unix and VMS-to-UNC path translation. VX/DCL runs on the shared VX/RT runtime and calls sibling tools directly: VX/SORT for SORT and MERGE, VX/JSP for print and batch queues, and VX/RMS for file operations. It can also replace a user's login shell to give migrated operators a familiar captive DCL environment.

Architecture and components

VX/DCL is a full DCL command-line interpreter, not a wrapper around a Unix shell. It is split into two source subsystems: the interpreter and verb handlers, and the CLI parsing and lexical subsystem. Utilities that OpenVMS also ships as separate images (SORT, DIFF, SEARCH, BACKUP and more) are built as standalone executables and dispatched as DCL verbs. The table maps each major piece to its role.

ComponentSubsystemRoleStatus
DCL interpreter / CLI driverdclMain read-eval loop, login and captive-account handling, LOGIN.COM / SYLOGIN.COM processing, banner, and dispatch entry.live
Built-in verb handlersdcl121 distinct DO_* routines behind a 195-entry dispatch table.live
Expression / lexical parsercliOperator and F$ name table, expression-tree build, and path-translation resolution.live
Lexical function bodiescliImplementations of F$CVTIME, F$GETSYI, F$FILE_ATTRIBUTES, F$FAO and the rest.live
Command grammar parsercliParses verb, qualifier and parameter syntax against the loaded CLD tables.live
CLD table loadercliLoads Command Language Dictionary tables via SET COMMAND; default sys$library:dcltables64.exe.live
Process control blockdclPer-process DCL state: symbols, logical names, and ON / control-Y state.live
File-spec name parserdclVMS file-spec parse through RMS extended attribute blocks.live
Web / X front endsdclBrowser-hosted and X-hosted DCL sessions.partial: terminal CLI is the primary surface
One interpreter, many verbs. VMS ships DCL alongside dozens of separate utility images. VX/DCL can either spawn those utilities as external executables or link them into a single interpreter image, so a deployment trades image size against process-spawn cost without changing script behaviour.

Dispatch model

Every command line resolves to a verb handler through dcl_dispatch(). It first consults small state-specific tables (for IF / THEN / ELSE and SUBROUTINE handling while in a GOTO or CALL branch), then the master verb table, and finally falls back to loading a routine from a dynamic shared image. Every handler shares the signature U32 DO_xxx(U32) and returns a VMS-style status code, so success is tested the VMS way: odd status is success.

01Command lineThe interpreter receives the DCL verb and its arguments.
02DCL_PARSEMatches the verb, qualifiers, and parameters against loaded CLD tables.
03dcl_dispatch()Resolves a handler name such as DO_COPY through ordered dispatch routes.
FirstState tablesHandle IF, THEN, ELSE, SUBROUTINE, and false-branch state.
Thendoroutines[]Search 195 dispatch entries that resolve to 121 built-in DO_* handlers.
FallbackDynamic .so imageLoad an external utility routine when no internal route matches.
04DO_xxx(U32)The selected built-in or loaded routine executes with the shared handler signature.
05VMS statusThe handler returns a code such as SS$_NORMAL.
06Success testAn odd status value is treated as success.

External utility images

File and data utilities are built as standalone executables and also compile into the interpreter when a smaller footprint is wanted. The standalone image set includes:

ANALYZE
CONVERT
DUMP
EDIT
MERGE
FTP
SORT
CC
CXX
CXXLINK
FORTRAN
PASCAL
MONITOR
LIBRARY
TCPIP
ZIP
DIFF
HELP
SEARCH
SHOW
START
STOP

The DCL command language

VX/DCL executes standard VMS .COM command procedures unchanged. Lines begin with $; control constructs, symbol assignment (= and :=), and lexical substitution ('symbol', ''lexical()') are all handled by the interpreter. At interactive login it runs the system login procedure (SYS$SYLOGIN, resolving to SYS$MANAGER:SYLOGIN.COM) and then the user's SYS$LOGIN:LOGIN.COM, matching VMS ordering, so captive and menu-driven login environments behave the way operators expect.

Symbols, logical names and substitution

Local and global symbols, logical-name tables, and the full VMS substitution rules are implemented in the interpreter's per-process control block. The procedure below is a representative end-of-day batch job for a funds-transfer system: it sets a symbol and a logical name, tests for a file with the F$SEARCH lexical, sorts a ledger through VX/SORT, and queues a follow-on procedure through VX/JSP.

$! nightly_close.com - end-of-day batch for the funds-transfer system
$
$ SET NOON
$ ACCT_DIR :== SYS$LOGIN:[BANKING.ACCOUNTS]
$ DEFINE ACCT$DATA DUA0:[BANKING.DATA]
$
$ start_time = F$TIME()
$ WRITE SYS$OUTPUT "Close started at ''start_time'"
$
$ IF F$SEARCH("ACCT$DATA:LEDGER.DAT") .EQS. ""
$ THEN
$     WRITE SYS$OUTPUT "No ledger to process - exiting"
$     EXIT
$ ENDIF
$
$ SORT/KEY=(POSITION:1,SIZE:12) ACCT$DATA:LEDGER.DAT LEDGER_SORTED.DAT
$ SUBMIT/QUEUE=SYS$BATCH ACCT_DIR:POST_STATEMENTS.COM
$ EXIT

Nested single and double quotes substitute symbols and lexical results into the command line before it is parsed, exactly as on VMS. Foreign commands (a symbol assigned to an image plus arguments) dispatch through the same path, so tools invoked by name from a procedure continue to work.

Built-in verbs by category

VX/DCL implements more than 120 distinct built-in verbs (195 dispatch entries once the SET, SHOW and TCPIP sub-verbs are counted). They group into the same families as native DCL.

CategoryRepresentative verbs
Flow and procedure controlIF, THEN, ELSE, GOTO, GOSUB, CALL, SUBROUTINE, ON, EXIT, INQUIRE, WAIT
Symbols and logical namesASSIGN, DEASSIGN, DEFINE, DEFINE/KEY, SET SYMBOL, DELETE/SYMBOL, SET UIC
File and data utilitiesCOPY, CREATE, DELETE, APPEND, RENAME, PURGE, TYPE, DIRECTORY, BACKUP, CONVERT, DUMP, SEARCH, DIFFERENCES, SORT, MERGE
Process and image executionRUN, SPAWN, ATTACH, MCR, PIPE, RECALL, ALLOCATE, DEALLOCATE
Queues, batch and printPRINT, SUBMIT, START/QUEUE, STOP/QUEUE, INITIALIZE/QUEUE, SET QUEUE, SHOW QUEUE, SET ENTRY
Networking and remoteFTP, SSH, SCP, SFTP, SET HOST/SSH, TCPIP
Environment and operatorSET (27 sub-verbs), SHOW (27 sub-verbs), REPLY, REQUEST, MAIL, MONITOR

Essential commands

These commonly-migrated commands are implemented so command procedures and interactive use continue without modification.

CommandFunction
ALLOCATEAssigns a device to a process.
ASSIGNCreates a logical name.
COPYCopies files from one location to another.
CREATECreates new files or directories.
DELETERemoves files or directories.
PRINTSubmits print jobs through VX/JSP.
SUBMITSubmits batch jobs through VX/JSP.
SHOW QUEUEDisplays job queue status.
SET DEFAULTChanges the current working directory.

Lexical functions

VX/DCL implements 43 DCL lexical functions. They are registered by name in the expression parser and evaluated by dedicated bodies that balance parentheses, resolve the expression, and substitute the result back into the command line. The table lists the functions scripts reach for most often; the full set is in the quick reference.

LexicalPurpose
F$SEARCHSearch a directory for a file spec; returns the full spec or an empty string.
F$PARSEParse a file spec through RMS and return a named component.
F$FILE_ATTRIBUTESReturn an RMS file attribute item such as record format or size.
F$CVTIMEConvert or decompose a date-time into fields like YEAR, MONTH or DAYOFYEAR.
F$TIMEReturn the current date-time string.
F$EXTRACT / F$ELEMENTSubstring by start and length; extract a delimited element.
F$EDITEdit a string: UPCASE, TRIM, COMPRESS and related operations.
F$LENGTH / F$LOCATEString length; offset of a substring.
F$INTEGER / F$STRINGConvert an expression to an integer or to a string.
F$GETDVIGet a device or volume information item.
F$GETJPIGet a job or process information item.
F$GETQUIGet a queue information item.
F$GETSYIGet a system information item.
F$TRNLNMTranslate a logical name.
F$MODEReturn the process mode (INTERACTIVE, BATCH and so on).
F$MESSAGEReturn the message text for a status code.
F$FAOFormatted ASCII output for building formatted strings.
Selectable item keywords are supported. The F$GETxxx lexicals resolve item keywords through per-facility tables, so F$GETDVI device items (such as FREEBLOCKS), F$GETJPI process items, F$GETQUI queue items and F$FILE_ATTRIBUTES record formats (FIX, VAR, VFC, STM) all behave as they do on VMS.

Example: F$CVTIME and nested substitution

The procedure below exercises F$CVTIME and the nested double-quote substitution rules. It is representative of date-driven batch logic that migrates unchanged.

$ WRITE SYS$OUTPUT "  DATETIME ''F$CVTIME (,,""DATETIME"")'"
$ WRITE SYS$OUTPUT "      DATE ''F$CVTIME (,,""DATE"")'"
$ WRITE SYS$OUTPUT "      YEAR ''F$CVTIME (,,""YEAR"")'"
$ WRITE SYS$OUTPUT "   WEEKDAY ''F$CVTIME (,,""WEEKDAY"")'"
$ WRITE SYS$OUTPUT " DAYOFYEAR ''F$CVTIME (,,""DAYOFYEAR"")'"
$ WRITE SYS$OUTPUT " Yesterday ''F$CVTIME (""YESTERDAY"",""ABSOLUTE"",""DAYOFYEAR"")'"
$ EXIT

F$CVTIME supports the full VMS output field set (DATETIME, DATE, TIME, YEAR, MONTH, DAY, WEEKDAY, HOUR, MINUTE, SECOND, DAYOFYEAR and more) and the input keywords YESTERDAY, TODAY, TOMORROW and ABSOLUTE.

File system and path translation

VX/DCL retains full compatibility with VMS file specifications and translates them to and from host paths automatically. Conversion is done through the VX/RT runtime rather than inside the interpreter, so the same path mapper serves every file verb, lexical function, and RMS operation. Scripts that pass VMS file specs keep working, and the interpreter handles logical-name mapping, device-table management, and automatic case conversion for file specifications.

VMS pathLinux equivalent
DUA0:[A.B.C]FILE.TXT/vms_disk/A/B/C/FILE.TXT
SYS$LOGIN:LOGIN.COM/home/user/LOGIN.COM

Path-translation lexicals

Four path-translation lexicals expose the runtime's path mapper directly to scripts. They are VX/DCL extensions, not present in native VMS DCL, and are the recommended way for a procedure to move between VMS and host path conventions when it needs an explicit conversion.

LexicalConversion
F$VMS_TO_UNIXVMS file spec to a Unix path.
F$UNIX_TO_VMSUnix path to a VMS file spec.
F$VMS_TO_UNCVMS file spec to a Windows or UNC path.
F$UNC_TO_VMSWindows or UNC path to a VMS file spec.
Case handling is a build-time choice. Linux is case-sensitive while VMS is case-insensitive and upcasing. On a case-preserving deployment, uppercase symlinks are created alongside their lowercase targets so that VMS-style uppercase file references resolve correctly.

RMS file-spec parsing

VMS file specs are parsed through RMS extended attribute blocks, so device, directory, name, type, and version decomposition matches RMS behaviour. This is the same machinery that resolves LOGIN.COM at login and that backs the DUA0:[A.B.C]FILE.TXT mapping above, which keeps file handling in the file verbs (COPY, CREATE, APPEND, BACKUP, CONVERT, DIRECTORY) consistent with the rest of the runtime.

Sector7 tool integrations

VX/DCL runs on the shared VX/RT runtime and calls its sibling tools directly through their native APIs. These are real link-time dependencies, not marketing adjacency: DCL verbs hand work to the same libraries a migrated application would use, so behaviour matches end to end.

ToolHow VX/DCL uses it
VX/RTRuntime foundation: descriptors, configuration, path mapping, process and spawn control, captive and batch mode, and terminal control. VX/DCL reports the shared VX/RT version in its banner.
VX/SORTThe SORT and MERGE verbs call the VX/SORT API directly, mapping the VMS qualifier surface (/KEY, /NODUPLICATES, /STABLE) onto its sort options.
VX/JSPPRINT, SUBMIT and the queue verbs create jobs through VX/JSP against SYS$PRINT and SYS$BATCH.
VX/RMSFile-spec parsing and the file verbs (COPY, CREATE, APPEND, BACKUP, CONVERT, DELETE, DIRECTORY) operate over RMS extended attribute blocks.
VX/CLDCommand and verb grammar is driven by CLD tables loaded at startup (default sys$library:dcltables64.exe), so SET COMMAND and custom verb definitions work as on VMS.

Example: the SORT verb calling VX/SORT

The DO_SORT handler shows the full VX/SORT lifecycle: feed each input file, begin the sort, run it, then always release the sort context. Every call is checked with the VMS convention that odd status is success.

while (nn < num_files) {
    vxrt_dsc64t(&d_infile, (U16)strlen(infile[nn]), infile[nn]); nn++;
    rc = SOR_D_PASS_FILES(&d_infile, &d_outfile, org);     // feed each input file
    if ((rc & 1) == 0) {
        fprintf(sysout, "DCL$SORT: SOR$PASS_FILES Error\r\n");
        VX_RETURNS(rc);
    }
    vxrt_dsc64t(&d_outfile, 0, NULL);                       // clear output for next pass
}
rc = SOR_D_BEGIN_SORT(key_info, &key_mrs, &key_options);    // start the sort
rc = SOR_D_SORT_MERGE();                                    // run it
SORT_END:;
rc = SOR_D_END_SORT();                                      // always release the sort context

Compatibility and divergences

The goal is source-level compatibility: existing .COM files, logical names, symbols and lexicals run without modification. The matrix summarises what is present and wired in the runtime today.

CapabilityStatus
.COM procedure execution plus LOGIN.COM / SYLOGIN.COMlive
121 built-in verb handlers across a 195-entry dispatch tablelive
43 F$ lexical functionslive
VMS-to-Unix and VMS-to-UNC path translationlive
Logical names, symbols, DEFINE and ASSIGNlive
SORT and MERGE through VX/SORTlive
PRINT, SUBMIT and queues through VX/JSPlive
File utilities (COPY, BACKUP, CONVERT, DIRECTORY, DIFF, SEARCH, DUMP)live
Captive accounts and login-shell replacementlive
Networking verbs (FTP, SSH, SCP, SFTP, TCPIP)live
Compiler front-end verbs (CC, CXX, FORTRAN, PASCAL, BASIC, LINK, MMS)live
Web-hosted and X-hosted DCL sessionspartial: terminal CLI is the primary surface

Intentional divergences from native VMS DCL

A handful of behaviours differ from native DCL by design, so scripts can interoperate with a Linux or Windows host. Each divergence is additive: VMS syntax still behaves the VMS way.

DivergenceReason
Adds F$VMS_TO_UNIX, F$UNIX_TO_VMS, F$VMS_TO_UNC, F$UNC_TO_VMSThe host filesystem is POSIX or Windows, so scripts need explicit access to the path mapper.
Adds F$SHELLVAR, DO_UNIX, SETENVLets procedures read host environment variables and run Linux commands from the $ prompt.
Adds SSH, SCP and SFTP verbsDECnet and LAT transports are replaced by TCP/IP and OpenSSH on the host.
Utilities can be external images or linked into the interpreterLets a deployment trade image size against process-spawn cost.
Case handling gated by a build-time switchLinux is case-sensitive; VMS is case-insensitive and upcasing, so a build option reconciles the two.

Quick reference

Lexical functions (43)

F$ADDTIME
F$CONTEXT
F$CSID
F$CVSI
F$CVTIME
F$CVUI
F$DEVICE
F$DIRECTORY
F$EDIT
F$ELEMENT
F$ENVIRONMENT
F$EXTRACT
F$FAO
F$FILE_ATTRIBUTES
F$GETDVI
F$GETJPI
F$GETQUI
F$GETSYI
F$IDENTIFIER
F$INTEGER
F$LENGTH
F$LOCATE
F$LOGICAL
F$MESSAGE
F$MODE
F$PARSE
F$PID
F$PRIVILEGE
F$PROCESS
F$SEARCH
F$SETPRV
F$SHELLVAR
F$STRING
F$TIME
F$TRNLNM
F$TYPE
F$UNIQUE
F$USER
F$VERIFY
F$VMS_TO_UNIX
F$UNIX_TO_VMS
F$VMS_TO_UNC
F$UNC_TO_VMS

Path-translation extensions

F$VMS_TO_UNIX
F$UNIX_TO_VMS
F$VMS_TO_UNC
F$UNC_TO_VMS
F$SHELLVAR

Verb categories

Flow control
Symbols and logicals
File utilities
Process and image
Queues and batch
Networking
SET (27 sub-verbs)
SHOW (27 sub-verbs)
System and operator

Key facts

ItemValue
Built-in verbs121 DO_* handlers behind a 195-entry dispatch table.
Lexical functions43 F$ functions.
Help topics104 top-level topics in the DCL help database.
Command tablesLoaded from sys$library:dcltables64.exe (or dcltables32.exe), up to 32 tables.
RuntimeShared VX/RT runtime, reported in the VX/DCL banner.
Platformsx86 and ARM Linux, and Windows.

Frequently Asked Questions

Curious about how Sector7 can facilitate your application migration? Explore our FAQs for expert insights.

What is VX/DCL and how does it work?

VX/DCL offers a fully compatible implementation of DCL for Linux and Windows, allowing .COM files and DCL-based automation to run unchanged. This enables organizations to maintain their existing command procedures while migrating to modern platforms.

For a real-world example of DCL migration success, see our Sprint (T-Mobile) migration case study.

How does VX/DCL support existing command procedures?

VX/DCL provides complete compatibility with OpenVMS DCL, ensuring your existing .COM files, scripts, and automation workflows continue to function without modification on Linux.

What are the key features of VX/DCL?
Key features of VX/DCL include:
  • Full compatibility with OpenVMS DCL commands and syntax
  • Support for existing .COM files without modification
  • Integration with VX/CLD for Command Line Definitions
  • Seamless automation workflow preservation
How does VX/DCL integrate with other migration tools?
VX/DCL works seamlessly with VX/CLD for compiling Command Line Definitions and integrates with the broader VX/RT ecosystem to provide comprehensive OpenVMS compatibility on modern platforms.
What types of DCL scripts can VX/DCL handle?
VX/DCL can handle all types of OpenVMS DCL scripts, from simple command sequences to complex automation workflows, batch processing scripts, and system administration procedures.
How does VX/DCL reduce migration costs?

VX/DCL eliminates the need for manual DCL-to-shell script conversion, which can cost $1-3 per line depending on complexity. By preserving existing DCL functionality, organizations save significant development time and reduce project risk.

For comprehensive DCL migration support, explore our COBOL Commercial Applications toolset bundle which includes VX/DCL integration.

What platforms does VX/DCL support?

VX/DCL provides full DCL compatibility on Linux (including RedHat and SUSE), enabling flexible deployment options for your migrated applications.

How can I get started with VX/DCL?
To learn more about VX/DCL and how it can streamline your OpenVMS migration project, contact us for a detailed assessment and consultation.
Do I need to modify my existing .COM files to run them under VX/DCL?

No. VX/DCL executes .COM files and DCL-based automation workflows without modification, so existing command procedures continue to function on the new platform.

How many DCL commands does VX/DCL support?

VX/DCL implements more than 130 VMS DCL commands, covering file and device operations (ALLOCATE, ASSIGN, COPY, CREATE, DELETE), job control (PRINT, SUBMIT, SHOW QUEUE) and environment control (SET DEFAULT), so command procedures and interactive use work without modification.

How does VX/DCL handle VMS file paths on Linux?

It performs automatic file-system translation, converting VMS-style file specifications to Linux paths and back. For example, DUA0:[A.B.C]FILE.TXT maps to /vms_disk/A/B/C/FILE.TXT, and SYS$LOGIN:LOGIN.COM maps to /home/user/LOGIN.COM. The same conversion is available inside scripts via the F$VMS_TO_UNIX lexical, with F$VMS_TO_UNC for Windows and UNC paths. It also handles logical-name mapping, device-table management and automatic case conversion.

Can I run Linux commands from within a VX/DCL session?

Yes. VX/DCL provides a fully functional command-line interface that lets Linux commands run from the $ prompt, and it supports both interactive and script-based execution.

Which VMS DCL language features does VX/DCL support?

VX/DCL provides full support for VMS lexicals, logical names, symbols, and command processing, and it is compatible with DCL system utilities, which are the core pieces DCL scripts rely on.

Which Sector7 tools does VX/DCL integrate with?

VX/DCL integrates with VX/JSP for print and batch queue management, VX/RMS for file-system compatibility, and VX/SORT for SORT and MERGE operations, and it runs on the VX/RT runtime environment.

Can VX/DCL replace a user's Linux shell for a VMS-like experience?

Yes. VX/DCL can replace Linux shells to provide a VMS-like interactive experience, and it supports captive accounts and secure environments with VMS user environments, logical names and login scripts.

What platforms does VX/DCL run on?

VX/DCL runs on x86 and ARM Linux, including Red Hat and SUSE, and on Windows, giving flexible deployment options for migrated OpenVMS applications.

Transform Your Legacy Software Today!

Get In Touch
Unlock the potential of your legacy software with our expert migration services.