Migrating OpenVMS Automation: DCL, Batch Jobs, Builds & Sort

• Direct porting of DCL scripts
• Preserves automation workflows
• Reduces migration risk

• Full compatibility with OpenVMS CLI$ APIs
• Support for command parsing and execution
• Integration with VX/RT for Linux environments

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.

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

• 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

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.

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

VX/SOR is a complete VMS/OpenVMS SORT MERGE implementation that fully supports the SOR$ API set, VX/DCL command line, and Linux shell execution. It enables organizations to migrate their OpenVMS sorting and merging operations to Linux without modifying existing application logic.

The tool replicates VMS sorting capabilities using multi-file merge sort techniques with quick-sort enhancements for optimal performance. For migration planning assistance, contact us.

VX/SOR provides complete support for all essential SOR$ API functions including SOR$BEGIN_SORT, SOR$END_SORT, SOR$INIT_SORT, SOR$MERGE, SOR$PASS_FILES, SOR$RELEASE_REC, SOR$RETURN_REC, SOR$SORT_MERGE, SOR$SPEC_FILE, and SOR$STAT.

Yes, VX/SOR integrates fully with VX/DCL, supporting native VMS command syntax for SORT and MERGE operations with complete command parsing and execution support.

VX/SOR enables seamless migration by providing call-compatible APIs that ensure applications using VMS sorting functions continue working without code changes. The tool maintains identical sorting behavior through its comprehensive qualifier support and API compatibility.

VX/SOR supports all essential VMS SORT qualifiers including ASCENDING, BINARY, CHARACTER, DECIMAL, DESCENDING, KEY, PROCESS, SEQUENTIAL, STATISTICS, and DUPLICATES, ensuring identical sorting behavior across platforms.

VX/SOR leverages multi-file merge sort techniques with quick-sort enhancements to optimize performance. The STATISTICS qualifier provides detailed performance metrics, allowing teams to monitor and optimize sorting operations effectively.

VX/JSP is a fully compatible implementation of the OpenVMS Batch and Print Queue Manager for Linux environments. It provides both API and command-line interface support, enabling seamless execution of batch processing and printing operations outside of the VMS environment.

The tool replicates VMS batch and print capabilities, ensuring organizations can retain identical functionality during their Linux migration. For guidance on implementing VX/JSP in your migration strategy, contact our team.

VX/JSP implements all major SYS$ API calls for queue management including SYS$GETQUI, SYS$GETQUIW, SYS$SNDJBC, and SYS$SNDJBCW.

VX/JSP operates as an add-on module for VX/DCL, providing fully integrated command-line execution for job and print queue management on Linux.

VX/JSP enables batch job submission using the SUBMIT command, executing DCL command files within VX/DCL while maintaining original VMS syntax for no-modification migration.

VX/JSP includes over 100 print qualifiers for advanced print job control, supporting features like restarting reports on specific pages, queue reordering, and job prioritization. The tool maps VMS devices to Linux equivalents, ensuring printer compatibility with both direct printer connections and mapped network printers.

Organizations like DuPont have successfully leveraged similar queue management capabilities during their system modernization projects.

Yes, VX/JSP supports simultaneous multi-job execution on a single queue with configurable priorities and scheduling intervals for optimized performance.

VX/JSP supports all major VMS queue management commands without syntax changes, including DEFINE, INITIALIZE/QUEUE, PRINT, SUBMIT, DELETE/ENTRY, SET QUEUE, SHOW QUEUE, START/QUEUE, and STOP/QUEUE. The tool retains the original VMS queue listing format for familiar queue management in migrated environments.

VX/JSP eliminates the complexity of migrating VMS batch and print job processing by providing identical functionality on Linux platforms. Organizations maintain their existing workflows without code rewrites or retraining, ensuring business continuity during migration.

The tool delivers full compatibility with VMS batch and print queue commands, implements all major SYS$ queue management API calls, and supports advanced print and job scheduling options. Companies like Telstra have achieved successful modernization while preserving critical operational processes.

To explore how VX/JSP can streamline your OpenVMS migration, contact us for a consultation.

VX/CLD is a Command Line Definition compiler that enables OpenVMS command parsing to function identically on Linux. It ensures applications using CLD to define commands, parameters, and qualifiers continue working without modification during migration.

By integrating with VX/DCL, organizations can extend, modify, or restrict VMS-style commands while maintaining complete compatibility with existing OpenVMS command-line applications. For migration planning assistance, contact our team.

VX/CLD enables migration of CLD-based applications to Linux while preserving command parsing logic, extends the VMS DCL command set with custom verbs and qualifiers, and restricts or modifies existing commands for greater control.

VX/CLD compiles a CLD file into an executable command parser that can be interpreted and executed under VX/DCL.

VX/CLD integrates seamlessly with VX/DCL to provide automated command parsing and execution. This integration allows applications using VMS-style command definitions to launch seamlessly from VX/DCL environments.

Organizations like Telstra have successfully leveraged this integration during their OpenVMS migrations to maintain command-line functionality on Linux systems.

Yes, VX/CLD allows you to extend, modify, or restrict existing VMS DCL commands, providing greater control over application behavior and command syntax.

VX/CLD ensures that legacy VMS CLD-based applications run on Linux without modification while maintaining existing command structures and qualifiers. Applications continue to function identically in non-VMS environments.

VX/CLD delivers seamless migration of VMS command syntax to Linux environments, enabling organizations to preserve their command-line application investments while modernizing their infrastructure. The tool maintains complete compatibility with existing command structures, parameters, and qualifiers.

As a critical component for VMS migrations, VX/CLD ensures DCL-based command-line applications continue to function exactly as expected on the new platform. Companies like SEB have successfully used similar migration strategies to modernize their systems.

To learn how VX/CLD can support your OpenVMS migration project, contact our migration specialists.

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

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.

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.

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.

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.

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.

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.

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

VX/JSP is a source-compatible reimplementation of the OpenVMS job controller and print/batch queue manager for Linux. It reproduces the VMS spooling subsystem and implements the SYS$SNDJBC and SYS$GETQUI system services, so batch scripts, print jobs, forms and queue definitions migrate without code rewrites or operator retraining.

It is an add-on module for VX/DCL. Batch and print queue management runs through VX/DCL's command-line execution, so SUBMIT and PRINT behave as they do on OpenVMS and no separate command environment is introduced.

VX/JSP implements the VMS queue-management services SYS$SNDJBC and SYS$SNDJBCW for request submission and queue control, and SYS$GETQUI and SYS$GETQUIW for queue, job, file and form queries. The function codes, item codes and status values match OpenVMS, so existing service calls keep working without API changes.

VX/JSP supports the major VMS queue-management commands, including INITIALIZE/QUEUE, START/QUEUE, START/QUEUE/MANAGER, SUBMIT, PRINT, SET QUEUE, SET/ENTRY, SHOW QUEUE, DEFINE/FORM, DELETE/ENTRY, STOP/QUEUE and SYNCHRONIZE. No syntax changes are required for migrated workloads.

Use the SUBMIT command through VX/DCL to execute a DCL command file. The original VMS syntax is retained, so existing batch scripts migrate with no modification, and you can set queue priorities and scheduling intervals to control execution.

Yes. A single queue can run multiple jobs simultaneously up to its job limit, with queue priorities and scheduling intervals controlling how work is dispatched. The queue manager uses POSIX threads and supports a large number of active jobs per queue.

The print symbiont reproduces the VMS page-formatting pipeline, including forms, page geometry, burst and flag pages, setup modules and carriage-control fixup. Jobs can print to local devices or spoolers, to raw network printers over TCP with PCL and PJL support, or to terminal-server and Xerox devices, with VMS devices mapped to their Linux equivalents.

No. VX/JSP replicates VMS batch and print queue behaviour, including the same commands, SYS$ service calls and the familiar VMS queue listing format, so organizations can keep their existing workflows on Linux without code rewrites or retraining.

VX/MMS is a Linux implementation of the OpenVMS Module Management System (MMS), DEC's dependency-driven build tool and the OpenVMS analogue of make. It reads your existing MMS description files, works out which targets are out of date, and rebuilds them on Linux, so your build automation migrates with the rest of your OpenVMS application.

No. Existing DESCRIP.MMS and MAKEFILE descriptions, along with their rules, macros, suffix rules and conditionals, are parsed and built the same way on Linux as they were on OpenVMS.

Each action line is executed through VX/DCL, the same command interpreter that runs your migrated .COM procedures. Commands such as COPY, DELETE, LINK, CC, COBOL and FORTRAN keep working after migration because they run in the same DCL environment as the rest of the estate.

No. VX/MMS fits Sector7's continuous integration migration approach. Teams keep developing on OpenVMS while the same descriptions rebuild on Linux, so the build environment moves across without a code freeze.

VX/MMS supports single-colon, double-colon and DEPENDS_ON rules; the action-line prefixes; recursive macro expansion and the special MMS$ macros; the full conditional family (.IF, .IFDEF, .IFNDEF, .ELSE, .ELSIF, .ENDIF); directives such as .FIRST, .LAST, .DEFAULT, .INCLUDE and the .SUFFIXES family; the built-in suffix rules; and extended string functions under /EXTENDED_SYNTAX.

The main difference is that each action line runs in its own VX/DCL process, so state such as SET DEFAULT, local symbols and logical names does not persist between lines. Lines that need shared state are combined onto one line or moved into a command procedure. A small set of less common qualifiers is deferred, and VX/MMS reports each one clearly rather than ignoring it silently.

Yes. VX/MMS drives the migrated compilers such as VX/C, VX/COBOL and VX/FORTRAN, and it runs alongside VX/DCL, VX/CDD, VX/DECFORMS and VX/MSG during a build.

VX/MMS tracks the worst status across all action lines, aborts on a failing line unless the failure is ignored, and publishes MMS$STATUS and MMS$SEVEREST_STATUS as DCL symbols for the surrounding procedure to test. Unrecognised directives and deferred qualifiers are named in diagnostics rather than dropped silently.

VX/SOR is a complete reimplementation of the OpenVMS SORT/MERGE utility for Linux. It provides the full SOR$ callable Sort/Merge API and the SORT and MERGE DCL verbs, so migrated applications can sort and merge records on Linux exactly as they did on OpenVMS.

No. VX/SOR provides call-compatible SOR$ routines and VX/DCL integration, so programs that call the OpenVMS sort routines and DCL scripts that run SORT or MERGE keep working without changes to their sort logic.

VX/SOR ships a callable library covering SOR$INIT_SORT, SOR$BEGIN_SORT, SOR$PASS_FILES, SOR$RELEASE_REC, SOR$SORT_MERGE, SOR$RETURN_REC, SOR$END_SORT, SOR$SPEC_FILE, SOR$STAT and SOR$DTYPE, so existing OpenVMS applications that call these routines migrate to Linux without rewriting their sort code.

Use the SORT verb through VX/DCL with the same syntax as OpenVMS. It takes one or more input files and an output file, and /KEY defines the sort key by 1-based byte position and size. For example: SORT/KEY=(POSITION:1,SIZE:10) ACCOUNTS.DAT SORTED_ACCOUNTS.DAT.

Use the MERGE verb. MERGE combines two or more inputs that are already sorted on the same keys into one ordered output file. It does not re-sort the inputs, which makes it faster than a full sort when the data is already in order.

VX/SOR acts on /KEY (position, size, number, ascending or descending, and the CHARACTER, D_FLOATING, F_FLOATING, G_FLOATING, H_FLOATING and PACKED_DECIMAL data types), /STABLE, /STATISTICS, /DUPLICATES and /NODUPLICATES, /SEQUENTIAL and /SPECIFICATION. Some further keywords are accepted for compatibility so existing command lines run without edits.

Yes. VX/SOR uses an external merge sort with a fast buffered k-way merge, and the /STATISTICS qualifier reports records read, sorted and output plus elapsed and CPU time. Environment variables let you tune the in-memory block size, the swap I/O size, and the placement of the SORTWORK files.

Yes. The /SPECIFICATION qualifier reads FIELD, CONDITION and INCLUDE/OMIT directives from a specification file, so you can define fields and record-selection rules declaratively and reuse them across jobs instead of building long command lines.