OpenVMS ACMS implemented over Tuxedo - OpenVMS Migration

VX/ACMS translates the TDL into Tuxedo C++ classes and programs.

Learn More


Migration involves mapping the ACMS Components to new platform in coordination with the VX/ACMS runtime capabilities.  Automation benefits initial migration tasks and allows ongoing coordination between existing and new platform.

Automated migration will:
- read ACMS Task and Group Definitions
- generate C++/Java program representing each Task Group
- generate C++/Java function represented each existing ACMS Task Name.


Generated sources contain:
    logic embedded in the Tasks replaced with C++/Java flow control statements.

    exception handling scope and behavior using same features in C++/Java.
Task entry points are:
    defined using ACMS$TASK()
    exposed to Tuxedo as a "service"
    initialized when Tuxedo calls SRVINIT() on their TaskGroup instance
    made ready using ACMS$INIT().


Executing Task entry points may call other Task services and will call Procedure services built using routines migrated from the ACMS ProcedureServer defined sources as same business logic and functionality are migrated to new platform.

Mechanisms for activation of these task entry points are similar to those generated for the Task Definitions.

Group Definition (.GDF) and Application Definition (.ADF) sources are used to generate ProcedureServer sources and Procedure routines to be linked with the migrated application sources.  Generated ProcedureServer registers each of the routines as Tuxedo services and manage the Task-Workspace mapping.

ACMS relies on the CDD to store definitions for all components.  By providing that same capability the CDD definitions are reused to generate native structures and to retain those definitions for metadata query.

Workspace elements will be referenced as native structure members within the generated sources.  Concurrency is maintained for data in local storage of the native structures and updated as needed in the execution lifecycle across the scope of Task, User, and Group workspaces. System workspaces are managed by VX/ACMS runtime directly.


Generated sources use ACMS$WORKSPACE() to define local storage and map workspace name (name) local storage (WKS *) to WKS structure WKS$name. Native structures allow compilers to map field names within workspaces, field data-type, size, and  offset in a manner that allows ongoing maintenance of the Task and Procedure sources thereafter.

Data concurrency for this local storage is maintained by ACMS$WS() and ACMS$INIT() calls within the generated sources and related functionality in the VX/ACMS runtime.

Generated sources and runtime recognize workspace definitions and named data elements, anticipate workspace and its relative position in the argument list, retrieve workspace data by name using ACMS$WS(),assign default values from CDD and IFDL FIELD definitions, and perform data conversion between data types to provide expected functionality and ensures maintainable sources.

CDD structure and information are generated to sources that use available information at build time to create the TaskGroupServer instances.

Control logic generated from .TDF and .GDF reference native structure members equivalent to workspace field names and interpret data according to CONTROL FIELD Task definition statements.


VX/ACMS preserves definitions of ACMS users, ensures the new platform will provide authentication, and perform authorization at granularity expected by ACMS definitions.  In addition, VX/ACMS allows integration of ACMS users into enterprise-wide authentication systems as required for interoperability on the new platform.

Standard authentication service will reuse existing information to meet security and permission requirements:

    migrated ACMSUAF.DAT (with supplied migration utility)
    Rights Identifiers (Username, UIC)
    Access Control Lists

Customer authentication may select LDAP or other enterprise logon facilities and
integration with these customer sources requires additional effort within the scope of each project.  Scope of that activity, technologies and capabilities they provide, will determine integration effort and any additional capabilities required.



Authorization phase controls determine which users can run which tasks based on permissions assigned to each user.  Rights Identifiers are assigned to an Application for both the TaskServer (Execution Controller or EXC) and as associated with ProcedureServer instances.
The appropriate Rights Identifiers are granted to individual VMS usernames and are checked when EXC prepares to initiate or cancel a Task to ensure the user has the proper Rights Identifier before permitting the action. 
Matching the new platform configuration controls and opportunities for modification of authorization details require analysis to determine if any gaps exist.