The ACMS Runtime, Rebuilt for Modern Systems

Full-fidelity DEC OpenVMS ACMS for Linux and macOS: task definitions, server processes, terminal I/O, and a rich step library – migrated applications run without retraining.

Browse Tasks

AVERTZ proof

adu – banking application

! Step 1 – compile the CDD record repository

$ vxcdd --add banking.cdo

ok ACCOUNT_WKSP, TRANSFER_WKSP, AUDIT_WKSP (layout_hash e3f9a1)

! Step 2 – compile server group (GDF)

$ adu_compile banking_servers.gdf --cdd banking.cdd.db

ok server group BANKING_SERVERS → banking_servers.cpp

ok linked → banking_servers.so

! Step 3 – compile task definitions (TDF)

$ adu_compile funds_transfer.tdf --gdf banking_servers.gdf --compile

parsing TDF… 3 tasks

resolving workspaces… ok (layout_hash e3f9a1 ✓)

generating C++… funds_transfer_task.cpp

compiling… funds_transfer.so

! Step 4 – install into acmsd

$ acmsctl install application BANKING

BANKING installed – 3 tasks, 2 server groups

ACMS_NORMAL

$ acmsctl call BANKING FUNDS_TRANSFER

ACMS$_NORMAL – task completed.

ADU parser ✓ live

ACMS$ services 12 impl.

workspace ABI ✓ live

The problem

ACMS shouldn't be the reason you stay on OpenVMS.

For thirty years, ACMS has been the transaction-processing backbone of business-critical OpenVMS applications. Migrating off OpenVMS has always meant rewriting the ACMS layer from scratch – re-implementing task orchestration, workspace passing, server lifecycle, and the forms-driven user interface in something entirely different. Months of work, indefinite risk.

The old answer

Hand-port every TDF into a custom service. Rewrite COBOL step procedures as web handlers. Re-think workspace semantics. Bind to a new persistence layer. Re-test under load. Retrain operators.

Typical timeline: 12–36 months per application. Typical failure mode: the new code never matches the old behaviour.

The VX/ACMS answer

A native Linux runtime that is ACMS as far as your source code can tell. The same TDFs compile. The same server procedures load. The same workspace passes by reference. The same ACMS$ services resolve.

Effort shifts from port to recompile.

Source compatibility

Three boundaries. Unchanged for your code.

Your migrated VMS applications meet VX/ACMS at three contracts. Each one is specified in the VSI ACMS manuals; each one is honoured by VX/ACMS on Linux exactly as your source expects.

TDL – Task Definition Language

Your .TDF, .GDF, and .ADF files compile through the ADU unchanged. Task structure, workspace declarations, EXCHANGE / PROCESSING / ATOMIC steps, exception handlers – all of it.

ACMS$ Services – System Interface

ACMS$CALL, ACMS$SIGN_IN, ACMS$START_CALL, ACMS$RAISE_STEP_EXCEPTION – the services your code links against. Same signatures, same status codes, same semantics.

FORMS$ – DECforms Callable API

VX/ACMS binds to VSI's DECforms runtime (also available on Linux). EXCHANGE steps marshal workspace records into FORMS$ records and pump events through FORMS$TRANSCEIVE exactly as on VMS.

What you have	VX/ACMS support
Task Definition Files (`.TDF`)	Compiles unchanged – including DCL prelude, `SET DEFAULT`, workspace `WITH ACCESS`, `TASK ARGUMENTS`, IF / WHILE / REPEAT / GOTO / ATOMIC.
Group Definition Files (`.GDF`)	Compiles unchanged – SERVER blocks, PROCEDURE SERVER IMAGE, INITIALIZATION / TERMINATION / CANCEL PROCEDURE, dictionary-qualified workspace refs.
Application Definition Files (`.ADF`)	Compiles unchanged.
Menu Definition Files (`.MDF`)	Coming v1 – menu rendering arrives with the CP integration.
CDD record definitions	Authoritative source via the `CDD$` callable API; layouts feed both ADU and the COBOL compiler.
COBOL step procedures	VMS-shape signature preserved – `PROCEDURE DIVISION USING`, workspaces by reference, status via `RETURN-CODE`.
C / C++ step procedures	Native – same signature `unsigned int NAME(WKSP a, WKSP b)`; status via return value.
System workspaces (`ACMS$SELECTION_STRING`, etc.)	Implemented.
DECforms (FORMS$ API)	CP integration in flight – links VSI's Linux `libvxdf*`.
Queued tasks (QTI)	v1 – surface + drain.
Distributed transactions (DDTM)	v1 – SQLite-backed single-resource bracket; DDTM shape preserved for v2.
ACMSDI / TPware (Windows desktop)	v2 – deferred per scope.
Distributed multi-node clustering	v2 – single-server is the v1 scope.
TDMS forms	Out of scope – migrate to DECforms.

Runtime architecture

Faithful to ACMS. Native on Linux.

Every ACMS component you know is here. Where VMS used P0 mappings and global sections, we use POSIX shared memory. Where VMS used DECnet, we use UNIX-domain sockets. The shapes match the VMS manuals; the substrate is modern Linux.

acmsd

VMS: ACC

Root daemon. Manages the SQLite control DB, spawns child processes, owns the operator socket.

acms-exc

VMS: EXC

Per-application task interpreter. Drives IF / WHILE / REPEAT / ATOMIC / EXCHANGE / PROCESSING steps against dlopen'd task .so files.

acms-sp

VMS: SP

Procedure server pool. Loads server group .so files via dlopen; dispatches step calls from EXC.

acms-cp

VMS: CP

Per-submitter FORMS$ / menu process. Bridges terminal I/O through DECforms libvxdf* on Linux.

acms-qti

VMS: QTI

Queued task initiator. Drains the SQLite-backed task queue; submits deferred tasks to EXC.

acms-atl

VMS: ATL

Audit trail logger. Writes structured audit events from all components via the SWL log library.

┌──────────────────────────────────────────────────┐ │ acmsd (ACC) │ │ SQLite: control.db · audit.db · queue.db │ │ operator socket · child lifecycle │ └──┬──────────┬──────────┬────────┬───────────────┘ │ │ │ │ ┌──────▼──┐ ┌────▼────┐ ┌─▼──┐ ┌─▼──┐ │ acms-exc│ │ acms-sp │ │ cp │ │ qti│ │ (EXC) │ │ (SP) │ │(CP)│ │ │ │ task │◄─► dlopen │ │ │ │ │ │ interp │ │ servers │ │ │ │ │ └────┬────┘ └─────────┘ └────┘ └────┘ │ POSIX shm_open / mmap (workspaces) │ UNIX-domain sockets (CBOR frames) ┌────▼────┐ │ libacms │ ← ACMS$CALL / ACMS$SIGN_IN / … │ _si.so │ agent callable surface └─────────┘

runtime components

ACMS$ services implemented

bytecode interpreters

C++20

implementation language

Zero-copy workspace passing. Workspaces are POSIX shared memory segments mapped at the same layout hash in every process. EXCHANGE steps move data without copying – the EXC and SP processes read and write the same physical pages. Only TASK ARGUMENTS copy boundaries cross the submitter-EXC split.

Inside the ADU

Your TDFs become native C++.

The Application Definition Utility parses your TDF, GDF, ADF, and MDF sources, resolves workspace records through the published CDD$ callable API, and emits clean C++ – one construct per TDL construct. The C++ is compiled and linked into a deployable .so per task and per server. No bytecode interpreter sits between your source and the CPU.

TDF source in

! funds_transfer.tdf
REPLACE TASK FUNDS_TRANSFER
    WORKSPACES ARE
        ACCOUNT_WKSP,
        TRANSFER_WKSP,
        AUDIT_WKSP;

    TASK ARGUMENTS ARE
        ACCOUNT_WKSP WITH ACCESS MODIFY,
        AUDIT_WKSP   WITH ACCESS WRITE;

    BLOCK
        EXCEPTION HANDLER
            MOVE "FAILED" TO AUDIT_WKSP.MSG;
            PROCESSING CALL LOG_AUDIT
                USING AUDIT_WKSP;
            EXIT TASK;

        PROCESSING CALL READ_ACCOUNT
            USING ACCOUNT_WKSP;

        IF ACCOUNT_WKSP.BALANCE
                < TRANSFER_WKSP.AMOUNT THEN
            MOVE "NSF" TO AUDIT_WKSP.MSG;
            EXIT TASK;
        END IF;

        PROCESSING CALL DEBIT_ACCOUNT
            USING ACCOUNT_WKSP, TRANSFER_WKSP;
    END BLOCK;
END DEFINITION;

Native C++ .so out

/* Generated by adu_compile */
extern "C" acms_status_t
task_FUNDS_TRANSFER_run(exc_ctx_t *e,
                        acms_runtime *rt,
                        exc_workspace_t *ws,
                        uint32_t n_ws)
{
  try {
    try {
      {
        const char *args[] = {"ACCOUNT_WKSP"};
        auto rc = acms_rt_dispatch(e, rt,
            "READ_ACCOUNT", ws, n_ws, args, 1);
        if (rc != ACMS_NORMAL)
          throw acms_rt_exception{rc};
      }
      if (acms_rt_field_i32(ws, n_ws,
              "ACCOUNT_WKSP", "BALANCE")
          < acms_rt_field_i32(ws, n_ws,
              "TRANSFER_WKSP", "AMOUNT")) {
        acms_rt_move_str(ws, n_ws,
            "AUDIT_WKSP", "MSG", "NSF");
        return ACMS_NORMAL; /* EXIT TASK */
      }
      /* DEBIT_ACCOUNT … */
    } catch (acms_rt_exception &) {
      /* EXCEPTION HANDLER */
      acms_rt_move_str(ws, n_ws,
          "AUDIT_WKSP", "MSG", "FAILED");
      return ACMS_NORMAL;
    }
  } catch (acms_rt_exception &x) {
    return x.status;
  }
  return ACMS_NORMAL;
}

Reviewable, debuggable output. Generated C++ is one construct per TDL construct – no opaque interpreter, no hidden state. git diff tells you exactly what an ADU version bump changed. Debuggers and profilers see function names that match your TDF identifiers.

Implementation status

What's live. What's coming.

VX/ACMS v1 targets the full single-server deployment model used by the overwhelming majority of production ACMS estates. Verified against large customer applications including multi-million-line COBOL codebases.

ADU Compiler live

Full TDF / GDF / ADF parser and C++ emitter. MDF support arriving with CP. CDD integration via vxcdd and the published CDD$ callable API.

TDF: all task constructs (BLOCK, IF, WHILE, REPEAT, GOTO, ATOMIC, MOVE, GET MESSAGE)
GDF: SERVER blocks, procedure server image, init/term/cancel procs
ADF: application definitions

Runtime Core live

EXC task interpreter, SP procedure server, workspace shared memory, IPC (CBOR over UNIX-domain sockets), ATOMIC SQLite bracket, EXCHANGE step machinery.

acmsd / EXC / SP / ATL / SWL
POSIX shm workspaces (zero-copy)
12 ACMS$ services implemented

FORMS$ / CP v1 soon

Per-submitter CP process with DECforms integration via VSI's Linux libvxdf*. Completes the EXCHANGE step pathway for terminal-I/O-driven applications.

Menu rendering (MDF)
FORMS$TRANSCEIVE / FORMS$RECEIVE
DECforms record marshalling

QTI / Queued Tasks v1 soon

SQLite-backed task queue with QTI drain process. Queued task surface API live; drain-to-EXC dispatch arriving in the next release.

Clustering / DDTM v2

Multi-node ACMS and true distributed transaction management (DDTM/XA) are scoped for v2. The v1 ATOMIC bracket preserves the DDTM interface shape so application code needs no changes at upgrade.

ACMSDI Gateway v2

The Windows desktop TPware interface (ACMSDI) and the HTTP/JSON management API are v2 scope items. Contact us if these are blockers for your migration timeline.

Frequently Asked Questions

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

Free Code Assessment

What is VX/ACMS and how does it help modernize OpenVMS ACMS applications?

VX/ACMS is a native C++20 reimplementation of HP/VSI ACMS for Linux. It delivers source-compatible task execution for migrated OpenVMS applications: your existing TDF, GDF, and ADF sources compile through the ADU, existing COBOL and C step procedures run unchanged, and calls to ACMS$ services resolve against the same signatures and status codes as on VMS. VX/ACMS targets the single-server deployment model used by most production ACMS estates.

How does the VX/ACMS migration build pipeline work at a high level?

Migration follows a four-step pipeline exposed through adu_compile and acmsctl. First, vxcdd builds your CDD database from .cdo record definitions. Next, GDF sources compile to server group .so files, then TDF sources compile to task .so files that reference the GDF. Finally, acmsctl install application registers the ADF and compiled .so files in the control database, with layout_hash checks catching any workspace mismatch before tasks can run.

Which ACMS$ services does VX/ACMS implement?

VX/ACMS implements the 12 ACMS$ services used across production estates, including ACMS$SIGN_IN, ACMS$SIGN_OUT, ACMS$CALL, ACMS$START_CALL, ACMS$WAIT_CALL, ACMS$CANCEL_CALL, and ACMS$RAISE_STEP_EXCEPTION. Submitter programs link against libacms_si.so and call these services with the same VMS-compatible signatures and 32-bit status codes – ACMS_NORMAL, ACMS$_NOSUCHAPP, ACMS$_STEP_ERR, and the rest of the standard set.

Does VX/ACMS require rewriting existing COBOL and C step procedures?

No. VX/ACMS preserves the VMS server module ABI so that existing procedure source compiles and runs without modification. COBOL step procedures keep their VMS-shape BY REFERENCE workspace signatures with status returned through RETURN-CODE, and C or C++ procedures export the same acms_server_module_v1 struct expected by the SP procedure server. Server group .so files are loaded by dlopen at runtime, matching the GDF definitions you already maintain.

Transform Your Legacy Software Today!

Get In Touch

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