ACMS to Tuxedo Rehosting

ACMS to Tuxedo Rehosting Roadmap

Rehosting systems that include Digital's Application Control Management System (ACMS) poses a set of daunting challenges for the IT manager. Because of the proprietary nature of ACMS, and the languages and tools used to develop an ACMS application, it might be thought that ACMS applications are impossible to rehost from the VMS platform.

Sector7 applies experience and knowledge about the ACMS environment to create this roadmap for ACMS rehosting to the Tuxedo transaction monitor environment.

This page gives an overview of ACMS and Tuxedo, with emphasis on the differences between the two environments, and provides a description of Sector7's rehosting strategy to take an ACMS application forward to Tuxedo.

ACMS and Tuxedo Comparison

Both are full-featured middleware transaction monitors supporting ACID transactions

A - Atomicity
C - Consistency
I - Isolation
D - Durability

ACMS Overview

ACMS is a robust client/server implementation of a transaction monitor. The ACMS Command Process controls the interaction with terminals and users, the Execution Controller Process controls the running of "tasks" or "transactions," and Server Processes manage the implementation of the business logic of the application. ACMS can be tightly integrated with the forms products DECforms or TDMS for screen presentation, and database managers Rdb or DBMS, or OpenVMS RMS for data storage. Each process within the ACMS system can run on a separate node in the network, if required, making ACMS distributable for optimal performance. ACMS tasks and servers run only on OpenVMS; however, clients can be written for other operating systems using the ACMSxp client interface. ACMS also includes management services allowing for control of all processes, the state of the system and applications, etc.

The ACMS Command Process manages clients and their connection to ACMS. The Execution controller manages the execution of tasks, and Server Processes contain the code which implements the business logic of the application. Server Processes are used to interact with resources such as databases or server tasks run on behalf of a client. Communication between these processes happens over an existing DECnet or TCP/IP network, using proprietary protocols within ACMS.

ACMS defines work or transactions in units called "tasks." Each task represents a unit of work to be performed which can be committed or rolled back depending on the decisions made by the code. A task can interact with multiple servers or resources as it executes.

ACMS processes and tasks are defined and controlled using proprietary languages. Tasks, Groups, Applications and ACMS menus are each defined using a language devoted to that task. Each language is called a Definition Language, so there is the Task Definition language (or TDL), Group Definition Language or (GDL), etc. These languages are not used or parsed by any other product.

Data is passed among client, task and server in workspaces. Workspaces are defined in the Task Definition Language. These workspaces are shared among the client, task and server using the build facilities within ACMS. Allocation of space for the workspaces is, in general, handled by ACMS in a way that is transparent to the programmer.

ACMSxp Overview

ACMSxp is a separate product from ACMS. It is a transaction monitor that runs on UNIX, and it provides client Application Programming Interfaces or APIs which run on many different operating systems, including Windows-based systems. These client interface APIs can be used to access ACMS applications as well.

Workspaces must be defined using ACMSxp to allow for endian conversion between platforms.

The major differences between ACMSxp and ACMS are:

Tuxedo Overview

Tuxedo is a three-tier client/server architecture providing transaction processing syntax. A Tuxedo system is divided into Client, Server, and the resources required for data storage, etc. Rather than tight integration with any particular technology, Tuxedo simply provides APIs for both client and server to allow them to use Tuxedo services. Tuxedo runs on multiple operating systems and platforms. OpenVMS systems are allowed to act as clients only. Tuxedo's resource manager allows for enhanced interaction with database managers which support the XA standard for database interfaces. Tuxedo also provides a set of management services which allow control and administration of the system and applications.

In Tuxedo, units of work are called "transactions." Transactions are defined by the client, by either implicit or explicit calls to Tuxedo APIs indicating when a transaction begins and ends. A transaction can be committed or rolled back as a unit, and can interact with multiple servers or resources.

Data is passed between client and server in workspaces. Workspaces are defined in simple language header files. These workspaces are shared between the client and server using the build facilities within Tuxedo. Allocation and management of space for the workspaces must be handled by the client using Tuxedo APIs. The workspaces must be defined to Tuxedo on a field-by-field basis to allow for datatype and endian conversion between platforms.

Tasks vs. Transactions

The basis of any transaction monitor is how units of work are defined. In ACMS, units of work are called "tasks" and are defined in the Task Definition Language. In ACMSxp, tasks are defined using STDL. These languages are procedural and describe the flow of the task. The tasks communicate with the requesting client and with appropriate servers as required, using TDL statements. The task contains the logic to commit or roll back the transaction, depending on state information received from client or server processes.

In Tuxedo, units of work are called "transactions." Transactions are defined by the client explicitly calling a Tuxedo routine to begin a transaction, or implicitly by the client calling a Tuxedo routine to send information to a Tuxedo server. Within a transaction, the client may communicate with servers as required, and the client is responsible for making the decision to commit or roll back the transaction.

Migration Techniques

Based on Sector7's experience in rehosting VMS applications, we have developed the following roadmap for converting ACMS applications to the Tuxedo environment. This procedure allows the units of work from ACMS to be translated into corresponding units of work under Tuxedo, maintaining the integrity and design of the application.

The first step is to convert the ACMS workspaces to C include files and/or COBOL copybooks. This allows the workspaces to be used unchanged without requiring the ACMS compilers. This minimizes code changes required to access the workspaces.

The next step is to encapsulate the ACMS tasks in C routines. One routine is created for each ACMS task. The routine created contains the Tuxedo code necessary to begin the task, allocate workspaces, make calls to the required Tuxedo servers, test the return status, commit the transaction, and deallocate any workspaces. Encapsulating all this requires the least changes to the calling programs. The interface to the routine is similar to the interface to the ACMS call task API. The programs which call the task are modified to call the newly-developed routine instead of the ACMS API.

The corresponding server procedure is then converted to the Tuxedo environment. In most cases, this involves simply changing the return statement(s) of the procedure to return control to the Tuxedo environment rather than to the calling routine. The business logic generally remains untouched.

It is usually possible to convert one task or group of tasks at a time, and test that part of the system, rather than forcing testing to wait until all the tasks are converted to Tuxedo. This reduces the final testing time and allows any problems to be identified and fixed quickly.

After the client and server routines are converted, the user interface elements are converted to non-proprietary drivers. Sector7 has experience in converting DECforms and TDMS to Java or SP2 screens. In addition, ACMS menus can be converted to the desired target presentation tool. Please see here for information about TDMS conversion.

Last updated: 12/01/04 09:05 AM