OpenVMS Screen & Forms Modernization (ACMS, DECForms, FMS, SMG)

• 100% compatible FDV$ API implementation
• Support for VT terminals and DECterm
• User Action Routines (UARs) for interactive events
• Full form compilation to binary runtime

SMG$ provides comprehensive terminal compatibility across all major Linux distributions through its OpenVMS-compatible screen management implementation. It automatically detects and adapts to different terminal types, from modern GUI terminals to traditional console interfaces, ensuring consistent behavior across Ubuntu, CentOS, RHEL, and other distributions. The SMG$ terminal abstraction layer handles terminal capability detection and adaptation, while SMG$INIT_TERM_TABLE and SMG$INIT_TERM_TABLE_BY_TYPE routines configure appropriate terminal characteristics for optimal display control and user interaction.

Yes, SMG$ applications integrate seamlessly with modern Linux desktop environments while maintaining their OpenVMS terminal-based interface design. Applications run in standard terminal emulators like GNOME Terminal, KDE Konsole, or xterm, providing familiar keyboard shortcuts and copy/paste functionality. SMG$ handles terminal capability detection automatically, ensuring proper display rendering across different terminal types. For organizations requiring enhanced integration, contact our technical team at contact us to discuss custom desktop integration solutions and user interface modernization options.

SMG$ provides extensive international character set support through its wide character display functions including SMG$PUT_CHARS_WIDE, SMG$PUT_CHARS_HIGHWIDE, and SMG$PUT_LINE_WIDE. These routines handle Unicode characters, multi-byte character sets, and various international encoding schemes while preserving OpenVMS application logic. SMG$ automatically adapts to Linux locale settings and terminal encoding configurations, ensuring proper display of international text without requiring application modifications. This makes SMG$ ideal for global organizations migrating OpenVMS applications that serve international users or process multilingual data.

SMG$ delivers comprehensive keyboard input and interaction capabilities through virtual keyboard management and input processing routines. It supports function key handling, special key sequences, and programmable key definitions via SMG$NAME_TO_KEYCODE and SMG$KEYCODE_TO_NAME. The system provides both immediate keystroke reading with SMG$READ_KEYSTROKE and full line input with SMG$READ_STRING and SMG$READ_COMPOSED_LINE. SMG$ also handles input cancellation, type-ahead buffering, and out-of-band processing, ensuring complete compatibility with OpenVMS keyboard interaction patterns across all supported Linux platforms.

SMG$ integrates seamlessly with the complete VX/RT ecosystem to provide comprehensive OpenVMS application migration capabilities. It works closely with VX/DCL for command line interfaces, RMS$ for record management, and SYS$ services for system integration. SMG$ applications can utilize QIO$ for device I/O operations while maintaining their screen management functionality. This integration ensures that complex OpenVMS applications with mixed terminal interfaces, file processing, and system calls can be migrated as complete solutions. Learn more about VX component integration with our VX/DCL technical documentation.

VX/DECFORMS provides a comprehensive implementation of DEC's OpenVMS DECforms, offering exact emulation that preserves form management and functionality across platforms. The solution compiles IFDL (Interactive Forms Definition Language) into C++ logic subroutines that mirror the original IFDL flow, ensuring 100% functional emulation where users cannot distinguish between migrated screens and original OpenVMS DECforms.

This breakthrough technology eliminates the barriers that previously made DECforms migration impractical, enabling organizations to modernize their legacy applications while maintaining complete compatibility. To explore how VX/DECFORMS can transform your migration project, contact our experts.

The IFDL compiler translates Interactive Forms Definition Language files into C++ subroutines, converting IFDL verbs into C++ classes that retain the same names and attributes as the original.

The migration process requires no changes to application programs - once form descriptions are updated, applications automatically utilize the new forms through the runtime system.

VX/DECFORMS utilities support multiple programming languages including Fortran, C, COBOL, and VX/BASIC, providing the necessary procedures to adapt VMS descriptors for modern platform integration.

User Escapes (PUEs) are custom routines written in any DEC-supported programming language that are tied to forms and fields during creation. The Form Driver automatically triggers these procedures in several scenarios: after field processing, before and after help requests, when function keys are pressed, and during screen refresh operations.

PUEs in VX/DECFORMS behave identically to those in original OpenVMS DECForms, with added flexibility. The IFDL compiler converts the IFDL into maintainable C++ code, allowing direct linking of external routines into the compiled IFDL for greater control over form interactions.

VX/ACMS is a comprehensive migration tool that translates OpenVMS ACMS applications (ADF, MDF, GDF, and TDF files) into C++ while maintaining a runtime environment that mirrors the original VMS/OpenVMS ACMS functionality. This enables seamless execution of ACMS applications on Linux without requiring a transaction monitor.

The tool preserves legacy workflows while ensuring compatibility with modern environments, making it ideal for organizations looking to modernize their ACMS applications. To discuss your ACMS migration requirements, contact us.

VX/ACMS supports all core ACMS file types including ADF (Application Definition Files), MDF (Menu Definition Files), GDF (Group Definition Files), and TDF (Task Definition Files) for translation to C++.

VX/ACMS translates ACMS files into C++ while preserving the original logic and structure. The process can be used as a one-time conversion or integrated into continuous integration workflows for automated builds.

Yes, VX/ACMS preserves the step-based processing approach that many users value, ensuring execution flow remains within a single compiled executable while maintaining the integrity of ACMS workflows.

VX/ACMS converts MDF (Menu Definition Files) into C-style menu structures that closely mimic MENU/TASK definitions. These menus can be displayed in VX/DECFORMS or processed into standard console-based menu systems, ensuring legacy ACMS menus function identically within the Linux runtime.

VX/ACMS supports all TDF control statements including IF THEN ELSE, WHILE DO, SELECT FIRST TRUE, CONTROL FIELD, and GOTO, maintaining nearly identical structure to the original TDF logic.

VX/ACMS preserves the original ACMS commit/rollback structure but delegates actual transaction management to Oracle or other modern transaction managers. The tool supports dynamic linking for procedure servers using Linux equivalents (dlopen and dlsym), ensuring compiled ACMS procedures behave identically to their VMS counterparts.

This approach maintains familiar ACMS commands while leveraging modern database transaction capabilities for improved reliability and performance.

VX/FMS provides a native call-compatible implementation of OpenVMS Forms Management System for Linux platforms. It enables OpenVMS applications to define, generate, and manage native FMS Forms on both x86 and ARM Linux systems.

This solution allows organizations to preserve their existing OpenVMS forms-based applications while migrating to modern Linux infrastructure. To discuss how VX/FMS can support your specific migration requirements, contact our team.

VX/FMS offers full compatibility with OpenVMS FDL$ APIs, supports file structure definition and parsing, and maintains OpenVMS file structure semantics on Linux.

Yes, VX/FMS provides comprehensive support for FDV$ APIs including display operations, terminal handling, file management, and workspace allocation functions.

VX/FMS preserves OpenVMS capability while enabling direct porting of applications without major modifications, minimizing development costs and preserving productivity.

VX/FMS maintains the complete OpenVMS forms workflow including structure generation, parsing, display operations, and user interaction handling. The solution preserves terminal management functions, screen operations, and file channel management exactly as they work in OpenVMS.

This comprehensive approach ensures that complex forms-based applications continue to operate with identical behavior on Linux platforms.

VX/FMS delivers seamless migration of forms-based applications with preserved functionality and consistent behavior. Organizations eliminate vendor lock-in while modernizing their infrastructure to Linux platforms.

The solution reduces development costs by avoiding application rewrites and maintains productivity through familiar forms management capabilities. Companies like Shaw Industries have successfully modernized their manufacturing systems using similar migration strategies.

Ready to explore how VX/FMS can modernize your forms-based applications? Contact us to discuss your specific requirements.

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.

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.

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.

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.

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.

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.

VX/FMS$ is a native reimplementation of the OpenVMS Forms Management System (FMS) for x86 and ARM Linux. It exports the FDV$ Forms Driver callable interface, so OpenVMS applications can define, display, and manage FMS forms on Linux without changing their forms logic.

VX/FMS$ runs on both x86 and ARM Linux. It is delivered as part of the VX/RT runtime that brings OpenVMS compatibility to those platforms.

No. Applications that call the OpenVMS FDV$ Forms Driver routines link and run without major modifications, which preserves productivity and minimizes development cost.

VX/FMS$ provides the full set of 66 FDV$ callable routines. They span form loading and display (FDV$LOAD, FDV$DISP, FDV$DISPW), field input and output (FDV$GET, FDV$GETSC, FDV$PFT, FDV$PUT), terminal and screen management (FDV$STERM, FDV$SCR_WIDTH, FDV$SCR_LENGTH), workspace handling (FDV$AWKSP, FDV$SWKSP, FDV$DWKSP), and library and channel control (FDV$LOPEN, FDV$LCHAN, FDV$TCHAN). The full routine table is on the page.

Through its FDV$ routines. For example FDV$DISP and FDV$DISPW display data, FDV$READ and FDV$GET handle input, FDV$BELL sounds the terminal alert, FDV$LEDON and FDV$LEDOF control terminal LEDs, and FDV$STERM sets terminal characteristics. Behaviour matches OpenVMS FMS, and forms are rendered to VT, ANSI, and xterm terminals using escape sequences.

VX/FMS$ integrates into the VX/RT ecosystem, which provides OpenVMS compatibility on x86 and ARM Linux. FMS forms handling is delivered as part of that broader OpenVMS-on-Linux runtime rather than as a standalone island.

Yes. VX/FMS$ preserves OpenVMS FMS capability and supports the same forms workflows: loading and displaying compiled forms, reading and transmitting fields, and managing the terminal, so forms-based applications can be ported directly.

A form is authored in the FMS form language as a .flg source file with statements such as FORM, TEXT, and FIELD, then compiled to a binary .fbn form. At run time an application selects a workspace with FDV$SWKSP, loads the form with FDV$LOAD, displays it with FDV$DISPW, and reads user input with FDV$GET or FDV$GETSC.

No. VX/ACMS bundles the TDF, MDF, and procedures (as dynamic libraries) into a single compiled executable and integrates them directly into the C++ runtime, so migrated applications run on Linux and Windows without a transaction monitor.

Yes. The translation can be a one-time conversion, where you convert the definitions to C++ and maintain the C++ from then on, or part of a continuous-integration workflow that recompiles and relinks the ACMS system on each build. Adding the --compile flag makes the adu translator invoke the C++ compiler after translating the ACMS definition files.

VX/ACMS does not execute commit or rollback itself. It assumes Oracle or another modern transaction manager owns that. The original ACMS commit and rollback structure is preserved in the translated code, but the database layer is now responsible for executing it.

MDF (Menu Definition Files) are translated into a C-style menu structure that closely mimics MENU and TASK definitions. The menus can be displayed in VX/DECFORMS or processed into standard console-based menu systems, so legacy menus behave the same way in the Linux and Windows runtime.

Procedure servers use dynamic linking. VX/ACMS maps ACMS dynamic calls onto the Linux equivalents dlopen and dlsym, so compiled ACMS procedures behave like their VMS counterparts. This also lets ACMS tasks call VX/DCL when the TDF permits it.

Yes. VX/ACMS keeps ACMS step-based processing, but the execution flow stays inside a single compiled executable. This removes the external transaction monitor while maintaining the integrity of the ACMS workflow.

CDD workspace definitions become packed C structures with fixed-width, space-padded text fields, pinned to the original byte layout with static_assert. This keeps the code compatible even on platforms that have no common data dictionary, so the ACMS logic stays readable and maintainable in C++.

VX/ACMS supports the RMS Recovery syntax, so tasks that use it still translate and run. Recovery logic itself is not yet implemented in VX/RMS; RMS support is planned to extend in future updates based on client needs.

VX/DECFORMS is Sector7's reimplementation of OpenVMS DECforms for Linux and Windows. It compiles your existing IFDL form definitions to C++ and provides the FORMS$ Form Driver runtime, so DECforms applications keep running with the same screens and behaviour after migrating off OpenVMS.

No. The migration process does not require changes to application programs. Existing FORMS$ calls link and run unchanged, and once the form descriptions are recompiled the application automatically uses the new forms through the runtime system.

FORMS$ is the DECforms Form Driver callable interface. VX/DECFORMS provides a library of FORMS$ APIs that mirror the original DECforms API, including ENABLE, DISABLE, SEND, RECEIVE, TRANSCEIVE, and CANCEL, so it stays compatible with the way OpenVMS applications call DECforms.

The vxforms compiler parses IFDL source and lowers it to C++ subroutines that call the forms_ runtime library. The generated code preserves the original IFDL identifiers, is compiled with a standard C++ toolchain, and links into the application alongside the Form Driver.

It retains the full original feature set, including scrolled areas, named data, overlapping forms, 132-character mode, help forms, and user-defined routines, plus character, line, and screen-width display attributes and VT100 special graphics. The aim is a functional emulation rather than an altered feature set.

It supports all VT terminals from VT100 upward, including DECterm under DECwindows, and can be extended for non-VTxxx terminals. Its built-in C-based terminal drivers work across Linux and Windows without curses, termcap, or external terminal configuration files.

It supports nearly all DECforms syntax. The one current limitation is right-to-left text formatting, which is not supported at this time. Everything else in the original feature set is preserved.

Yes. Alongside VT-terminal output, VX/DECFORMS can present forms in modern HTML5 browsers, broadening access to legacy applications without changing the underlying form logic.

VX/FMS is a native reimplementation of DEC's OpenVMS Forms Management System for Linux. It reproduces the original FMS behaviour, formatting, and user interactions so migrated applications run without functional changes, and the same sources also build for other Unix platforms through build-time configuration.

No. VX/FMS implements the FDV$ APIs with the same arguments and status conventions as OpenVMS FMS, so existing applications that call the FDV$ interface keep their calling sequence unchanged. Migration is a relink rather than a rewrite.

It translates the FMS mask description language (.flg source) into binary runtime form files (.fbn), the same compiled form output FMS produced on OpenVMS, so form logic, attributes, and layout are preserved and execute identically after migration.

VX/FMS supports VT100, VT220, and all compatible VT-series terminals, DECterm under DECwindows, and ANSI-compatible terminal emulators on Linux, giving identical character-cell user interaction across platforms.

No. The Form Driver renders FMS screens directly with VT and ANSI escape sequences and does not rely on curses, termcap, or terminfo. That is how it keeps exact compatibility with original VMS FMS display behaviour rather than approximating it through a Unix TUI layer.

Scrolled areas, named data, overlapping forms, 132-character wide-screen mode, VMS HELP forms, and User Action Routines are all supported, so the migrated environment retains the core capabilities of OpenVMS FMS.

UARs are user-defined callback procedures triggered by form events. A form binds a UAR by name in the .flg source, and the Form Driver dispatches it at run time. VX/FMS supports all UAR scenarios, including field completion, operator help requests, function-key interactions, and screen refresh, and it also allows dynamic linking of external C++ functions for extra flexibility.

VX/FMS can run as a standalone product or integrate with VX/RT, Sector7's OpenVMS runtime environment on Linux, and it works alongside VX/RMS and other Sector7 migration tools so an entire OpenVMS forms application can move together.