🚨 Oracle not porting Rdb to x86 and EOL on Itanium 12/2027 🚨

DEC’s sample ACMS app. Running on Linux. Untouched.

AVERTZ is the sample application DEC shipped to prove an ACMS install works: a fictional car-rental firm built from a menu, a form, COBOL logic, and an Rdb database. Watch Sector7's toolset run it, unchanged, on Linux.
Meet AVERTZ
The Sector7 toolset
AVERTZ Rent-A-Car · Check In
* DEC's sample ACMS app, now running on Linux, unchanged
 
Reservation #  00001
Customer     SIMPSON
Vehicle      Compact
Out / In     19 Apr → 22 Apr
 
> looking up reservation ok
> calculating charges ok
> saving the rental committed
 
Amount due   $30.00  exactly per the manual
Check-in complete.
Source code unchanged
The screen identical
The bill $30.00
A car-rental company that never existed

Meet AVERTZ.

When DEC shipped ACMS, the transaction engine at the heart of countless OpenVMS systems, it included a sample application to prove the install worked. That app was AVERTZ, a fictional car-rental company. If you ever stood up ACMS, you met AVERTZ. You reserved a car, checked one out, checked one back in, and watched the bill come out right.

AVERTZ is small on purpose, yet it is a complete transaction system in miniature. It quietly uses every moving part a real OpenVMS application depends on. That is exactly why it makes such a good test: get AVERTZ running somewhere new, unchanged, and you have proven the whole machine works.

Everything a real system uses, in one tiny app

ACMStasks, menus & servers
DECformsthe on-screen forms
COBOLthe business logic
SQLreads & writes
Rdbthe database
The whole migration problem, in a bottle. AVERTZ is a distributed transaction app wearing a car-rental costume. Move it to Linux without touching the source, and you have shown that the hard parts all still work together: the forms, the tasks, the COBOL, and a live database.
What has to work together

A complete transaction system, in miniature.

Behind that simple rental screen, several pieces have to cooperate perfectly. A terminal shows a form. A task engine runs the steps in order. Server processes carry out the COBOL business logic. A database records the result, all inside one transaction that either finishes cleanly or undoes itself. Here is the shape of it.

Nothing is copied or reshaped along the way. The screen, the task, and the COBOL all share the same data records, laid out exactly as the original application defined them. That fidelity is the whole point, and the thing a migration has to preserve.
The Sector7 approach

We don't rewrite AVERTZ. We re-home it.

A rewrite would take the app apart and rebuild it in something new. That is slow, risky, and never quite the same. Sector7 does the opposite. Each piece of AVERTZ is carried across by a proprietary VX/TOOLS product that speaks the original's language, so the parts click together on Linux exactly as they did on OpenVMS.

ACMS tasks, menus & servers
VX/ACMS

Runs the original task, menu, and server definitions as-is. This is the engine that orchestrates the whole transaction.

The on-screen forms
VX/DECFORMS

Compiles and runs the real DECforms screens, so operators see the exact same form they always did. No retraining.

The business logic
VX/COBOL

Takes the original COBOL procedures to Linux with their behavior intact. These are the rules that actually work out the bill.

Record & data definitions
VX/CDD

Reads the original data dictionary so every layer agrees on how a record looks, down to the byte.

Rdb / SQL data
VX/SQLMOD

Moves the Rdb database work onto PostgreSQL or Oracle, preserving the queries the app relies on.

File handling
VX/RMS

Gives the app the same file I/O it had on OpenVMS, with no changes to the source.

Recompile, don't rewrite. This is the Sector7 method on every migration: no code freeze, no manual rewrites, and behavior that matches the original. AVERTZ is simply the smallest, clearest proof of it. The same toolset moves systems with millions of lines of code.
One transaction, start to finish

A customer returns a car.

Here is AVERTZ doing its job, the check-in from the ACMS manual, running on Linux through Sector7's toolset. Every step is the original app's, unchanged.

Pick it from the menu

The operator chooses "check in a car." The same menu appears, driven by the original definition.

The form comes up

The real DECforms screen paints on the terminal. The operator types a reservation number and hits transmit, exactly as on OpenVMS.

The business logic runs

The original COBOL looks up the reservation and the customer, works out the charges, and prepares the records to save.

It all commits together

The reservation, the vehicle, and the rental history are written in a single transaction, so it either all succeeds or none of it does.

The bill is right

The customer's total comes out at $30.00, the exact figure from the manual's worked example.

Same steps. Same screen. Same result. Nothing about the application was rewritten to make this happen. Only the platform underneath it changed.
How we know it works

The bill comes out at $30.00. Every build.

"It runs" is easy to say. Sector7 proves it automatically. AVERTZ is checked end to end on every build, doing real work on the real forms, against a real database.

7
AVERTZ tasks running
$30.00
bill, matches the manual
~1M
transactions in a 24-hour soak
0
failures · flat memory

The full customer journey

Reserve a car, check it out, check it back in. Each runs on the real form, through the real terminal, with the numbers coming out right.

The original COBOL, writing for real

The unchanged COBOL runs the business logic and writes to the database inside a transaction that can be safely rolled back.

Clean under stress

A 24-hour soak ran roughly a million transactions with zero failures and steady memory, the behavior you need for a system that runs a business.

What "unchanged" really means

Your code doesn't change. The platform does.

AVERTZ makes an abstract promise concrete: the assets you already own keep working. Here is what that looks like, piece by piece.

What you already haveWhat happens to it
ACMS task, menu & server definitionsRun as-is.No rewriting the flow.
DECforms screensSame forms, same keys.Operators notice nothing.
COBOL business logicKeeps its behavior.The rules that run your business are preserved.
Record & data definitionsRead directly.Every layer agrees on the data.
Rdb / SQL dataMoves to PostgreSQL or Oracle.Queries preserved.
The platform underneathModern x86 or ARM Linux, or cloud. The one thing that actually changes.
AVERTZ is the small proof. Your estate is the real work. Sector7 has moved 1,500+ OpenVMS systems since 1985 with this same recompile-don't-rewrite method: no code freeze, and costs scoped up front by a patented model.
Explore migration servicesTalk to Sector7

Frequently Asked Questions

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

Free Code Assessment
Contact Us
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.

Does VX/ACMS maintain the original ACMS step-based processing model?

Yes. VX/ACMS preserves the ACMS component model and step-driven task interpretation verbatim. The EXC task interpreter drives the same step types you already use — PROCESSING CALL, EXCHANGE, ATOMIC, IF, WHILE, REPEAT, GOTO, MOVE, and EXCEPTION HANDLER — and workspaces still flow between submitters, EXC, and procedure servers through the familiar TASK, USER, GROUP, and SYSTEM lifetimes.

Which TDL file types does VX/ACMS support for migration?

The ADU compiler processes all four standard TDL file types: TDF for tasks, GDF for server groups and procedure definitions, ADF for applications, and MDF for menus. Existing TDF, GDF, ADF, and MDF sources compile unchanged through VX/ACMS. CDD record definitions that describe workspace layouts are compiled separately via vxcdd and consumed by both the ADU and your COBOL or C compilers.

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.

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.

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.

Transform Your Legacy Software Today!

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