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 -gThe -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.
