VX/ACMS translates the MDF, GDF and TDF files to C++ AND INCLUDES THE RUNTIME. ALL OF THE ACMS SYNTAX IS PARSED AND A SIGNIFICANT NUMBER OF THE STATEMENTS IMPLEMENTED (See below for list of currently implemented statements). At its simplest level VX/ACMS will bind together in a single executable unit the TDF, and the procedures (held in a dynamic library). VX/ACMS can be used to convert the ADU to C++ one time and then the C++ modified from that point on, or if the ACMS is fluid, VX/ACMS can be used as a compiler as part of the application build procesure. VX/ACMS is certified as part of Sector7's continual integration methodology eliminating the need for code freeze and allowing contined development on VMS and recompile/relink on Linux/Windows. VX/ACMS supports DEC FORMS EXCHANGE via Sector7's VX/DECFORMS.
VX/ACMS does not use a tranaction monitor therefore there is no mechanism for distributing transactions to multiple transaction execution engines.
Our clients have asked us to keep the "Step" processing ACMS offers but keep the flow within the executable.
VX/ACMS TRANSLATES ACMS ADF, MDF, GDF and TDF files to C++.
In its current release, each TDF compiled doen to its own executable. The procedure or DCL server (bth kept in external dynamic librries) toethe with the TDF riles make a complete executable Linux.
MDF generates a C style menu structure that exactly mimics the MANU/TASK definitions and then calls a small runtime to display the MDF on the screen or can be processed to be integrated with a dec form that will display the mdf.
GDF files like VMS build the server executables.
VX/ACMS is completely integrated with VX/DECFORMS (Sector7's DECFORMS product for Linux/Windows).
{SEND|RECEIVING|TRANSCEIVE} {FORM RECORD|RECORD} name { SENDING&|RECEIVING } workspace_list with_control_clause
TDMS is not supported as a VX/ACMS exchange step.
VX/ACMS is not designed as a transaction manager, it will operate the same as ACMS but our goal is really to move the ACMS syntax and functionality to modern C++ and allow users to use more modern transaction managers.
VX/ACMS does provide An integrated ADF/GDF/TDF and MDF environment.
MDF menus can be displayed using VX/DECFORMS or with a simple menu dislpay program.
The VX/ACMS runtime library (available in source code form) uses a VXACMS() class and then functions thay look similar and behave identically to VMS ACMS.
VXACMS().Header("","",0);
VXACMS().Menu(mdf_menu_entries);
VXACMS().Rollback();
VXACMS.Commit();
The Sector7 VX/ACMS compiler is also available in source code form and can be simpy modified to emit code more engineered to a specific transaction manager.
VX/ACMS will gain more features as we implement and enhance for our clients.
The ADU command line capability is very simple and could do with more development work, but our goal is to move away from the ACMS command line syntax and not perpetuate it.
To compile all the *.?df files in a directory:
vxacms *.?df -g
-g tells vxacms to call the C++ compiler after it has translted the .?DF to C++.
the emitted C++ looks very similar to the TDF. The strucutre of the TDF is maintained.
All of the TDF control statements are supported
IF THEN ELSE
WHILE DO
SELECT FIRST TRUE
CONTROL FIELD
GOTO
VX/ACMS follows the same rules for scope control as VMS ACMS.
The CDD workspace defintions are in C structure format, allowing the CDD to be dispensed of ad Linux/Windows does not support a common data dictionary.
Workspaces follow the same structure packing rules as VMS ACMS.
BLOCK
EXCHANGE
PROCSSING
ACTION
All follow the same scoping riles as ACMS.
Overloaded C++ makes IF THEN ELSE / MOVE code simpe to read and to modify. String operations use the same operators as numeric and some non types high level languages
if ("Data" == work.item.expect) {
} else {
}
MOVE "Hello" into work.item.expect
work.item.expect = "Hello";
Procedure Servers follow the same restrictions, VX/ACMS allow VX/DCL to be accessible to tasks is allowed by the TDF.
here is an examPle of a small MDF converted to C++
REPLACE MENU acms_menu:sector7 DEFAULT APPLICATION IS "sector7"; DEFAULT MENU FILE IS "acms_mdb:sector7.mdb"; HEADER IS " SECTOR7 TEST MENU SYSTEM " ------------------------"; ENTRIES ARE "DECFORMS" : menu is acms_menu:sector7_decforms_menu; text is "I want to migrate DECFORMS to LINUX"; "ACMS " : menu is acms_menu:sector7_acms_menu; text is "I want to migrate ACMS to LINUX"; "VMS " : task is acms_menu:call_sector_asap; text is "I need to call Sector7"; "EXIT " : text is "Time to go"; command 8; END ENTRIES; END DEFINITION;
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); }
VX/ACMS uses the same compiler fot ADF/MDG/GDF/TDF. The C++ syntax emitted is consistent for all ADU.
Supported SYNTAX
REPLACE GROUP menu_name diagnostic
It seems most users do not really use or want the distributed transaction capability of ACMS and many use ACMS as a hugh level structured programming language.
To address the needs of our clients, VX/ACMS basically compiles the TDF, and allows calling of procedures and tasks, exactly like acms, but in effect each user running the TDF does so in thir own copy of the shared executable.
C functions collected into a 'server' are still called using the dynamic calling mechanism ($FIND_IMAGE_SYMBOL/$CALLG Linux equivalent dlopen/dysym) these routines are called with workspace data are wil obviously behave identically to their comoiled VMS / OpenVMS server specification.
COMMIT/ROLLBACK are specifically for Oracle (not Rdb Oracle, or for the IBM DB2 connect client).
VX/ACMS plays no part in COMMITING or ROLLING BACK transactions, these are now all assumed to be handleD by Oracle.
RMS RECOVERY syntax is supported but currently VX/RMS does not handle recovery.
The following verbs are supported in VX/ACMS (this is a changing list, please contact for the latest updates)
(ACTION, EXCHANGE, PROCESSING are combined)
PROCESSING Statements CONTROL FIELD control_field_variable processing_control_field_clause END CONTROL FIELD DISTRIBUTED TRANSACTION IF ( boolean_expression ) THEN processing_clause ELSE processing_clause END IF IF ( boolean_expression ) THEN processing_clause END IF NO PROCESSING NO TERMINAL USER io_clause NO io_clause NONPARTICIPATING SERVER REQUEST io_clause RMS RECOVERY SELECT FIRST TRUE processing_select_first_true_of_clause END SELECT TERMINAL USER io_clause WHILE ( boolean_expression ) DO processing_clause END WHILE call_statement commit_statement dcl_statement exit_statement get_error_statement goto_statement image_statement move_statement repeat_statement rollback_statement