VX/ACMS - OpenVMS ACMS(TDF,MDF,GDF,ADF) to C++

Description:

VX/ACMS is a full-featured ACMS migration tool that translates ADF, MDF, GDF, and TDF files into C++ while maintaining a runtime environment that mirrors the original VMS/OpenVMS ACMS. This allows seamless execution of ACMS applications on Linux and Windows without the need for a transaction monitor. Whether you’re migrating an existing ACMS-based system or integrating ACMS logic into a modern development workflow, VX/ACMS ensures minimal changes and maximum compatibility.

‍

Translating ACMS to C++

VX/ACMS translates MDF, GDF, and TDF files into C++, preserving the logic and structure of the original ACMS code. This means existing ACMS applications can be migrated with minimal rewriting, ensuring a smooth transition to modern platforms.

• The translation process can be used one-time (converting the ADU to C++ and maintaining the C++ code from that point onward).

• Alternatively, VX/ACMS can be part of a continuous integration workflow, recompiling and relinking the ACMS system as part of an automated build process.

• The compiled C++ structure closely follows the original ACMS syntax, making it easy to read and maintain.

To compile all ACMS .?df files in a directory:

vxacms *.?df -g

The -g flag tells VX/ACMS to call the C++ compiler after translating the ACMS files into C++.
‍

Executable Structure and Runtime

Binding ACMS Components Together

At its simplest level, VX/ACMS bundles the TDF, MDF, and procedures (stored in dynamic libraries) into a single executable unit. This mirrors how ACMS applications operate in VMS, but instead of requiring a transaction monitor, VX/ACMS integrates these components directly into the C++ runtime.
‍

Maintaining ACMS Step Processing

Many users value the step-based processing of ACMS. VX/ACMS preserves this approach but ensures that the execution flow remains within a single compiled executable. This eliminates the need for external transaction monitors while maintaining the integrity of ACMS workflows.
‍

Handling Menus and User Interfaces

• MDF (Menu Definition Files) generate a C-style menu structure, closely mimicking MANU/TASK definitions.

• The menus can be displayed in VX/DECFORMS or processed into standard console-based menu systems.

Here’s an example of an MDF menu converted to C++:

vxacms_mdf_menu_t mdf_menu_entries[] = {
  "DECFORMS", "MENU", "ACMS_MENU:SECTOR7_DECFORMS_MENU",
  "I want to migrate DECFORMS to LINUX", "",
  "ACMS", "MENU", "ACMS_MENU:SECTOR7_ACMS_MENU",
  "I want to migrate ACMS to LINUX", "",
  "VMS", "TASK", "ACMS_MENU", 
  "I need to call Sector7 1-800-VMS-UNIX", "",
  "EXIT", "COMMAND", "8", "Time to go", "",
  VXACMS_MDF_END_MENU
};

extern "C" void SECTOR7() {
  VXACMS().ReplaceMenu("SECTOR7");
  VXACMS().DefaultApplication("sector7");
  VXACMS().DefaultMenuFile("acms_mdb:sector7.mdb");
  VXACMS().Header("SECTOR7 TEST MENU SYSTEM", 0);
  VXACMS().Menu(mdf_menu_entries);
}

This conversion ensures that legacy ACMS menus function identically within the Linux/Windows runtime.
‍

ACMS Control Flow in C++

TDF Translation to C++

All TDF control statements are supported, and the structure of the translated C++ code remains nearly identical to the original TDF logic.

Supported TDF control structures include:

• IF THEN ELSE

• WHILE DO

• SELECT FIRST TRUE

• CONTROL FIELD

• GOTO

The CDD workspace definitions are translated into C structures, ensuring compatibility even in environments that do not support common data dictionaries.

Example:

if ("Data" == work.item.expect)}  // Process condition
else {  work.item.expect = "Default Value";}

‍‍This ensures that ACMS logic is maintained in a readable, maintainable C++ format.
‍

Handling Procedure Servers

Dynamic Linking for ACMS Procedures

Procedure servers follow the same restrictions as ACMS, with support for dynamic linking. VX/ACMS uses Linux equivalents for dynamic calls (dlopen and dlsym), ensuring that compiled ACMS procedures behave identically to their VMS counterparts.

Example:
‍

void *handle = dlopen("server_library.so", RTLD_LAZY);
void (*procedure)();
procedure = (void (*)())dlsym(handle, "server_procedure");
procedure();
dlclose(handle);

‍‍This approach allows ACMS tasks to call VX/DCL, provided the TDF allows it.

Transaction Handling

Oracle Transaction Support

• VX/ACMS does not handle transaction commit/rollback—this is assumed to be managed by Oracle or another modern transaction manager.

• The original ACMS commit/rollback structure remains intact, but all transaction management is now the responsibility of the database layer.

Example:

VXACMS().Rollback();
VXACMS().Commit();

This keeps the original ACMS commands but relies on Oracle for execution.

Handling RMS Recovery

• VX/ACMS supports RMS Recovery syntax, but VX/RMS does not currently implement recovery logic.

• Future updates will extend RMS support based on client needs.
‍

The Future of VX/ACMS

Expanding Capabilities

VX/ACMS will continue to evolve based on client feedback. Upcoming enhancements may include:

• Extended ACMS command-line support

• Improved handling of MDF menus

• Better integration with third-party transaction managers

Moving Beyond Traditional ACMS

The ADU command-line interface is currently minimal, as VX/ACMS is designed to move away from traditional ACMS syntax rather than perpetuate it. Future versions may offer more robust command-line tools, but the focus remains on modernizing ACMS applications in C++.|
‍

Conclusion

VX/ACMS is the ideal solution for migrating VMS/OpenVMS ACMS applications to Linux and Windows. By translating ACMS structures into C++, it preserves legacy workflows while ensuring compatibility with modern environments. VX/ACMS eliminates the need for a transaction monitor, integrates with VX/DECFORMS, and provides seamless execution of ACMS applications in a single compiled executable.

For organizations looking to modernize their ACMS applications while maintaining familiar workflows, VX/ACMS provides a powerful, efficient, and scalable solution.