HP OpenVMS Systems Documentation
Compaq ACMS for OpenVMS
ACMS is part of a family of software products designed to help you manage data in all areas of your organization. Layered on the OpenVMS operating1 system, these products work together with high-level programming languages to provide a total information management system you can tailor to your needs. Depending on your needs, you can choose from a variety of products for front-end I/O functions as well as back-end data management functions.
The following sections introduce some of the products you can use with
ACMS to build a transaction processing system.
1.4.1 Data Management Products
DECdtm services for OpenVMS, the distributed transaction manager, ensures the integrity of data on back-end nodes in an ACMS application. The application and databases can be installed on a single node or distributed in a Compaq network. DECdtm services support the following data management systems, which you can use individually or in combination:
The CDD data dictionary system provides a central storage location for data descriptions and definitions shared by ACMS, other related products, and programming languages.
The CDD data dictionary:
You can write and debug application programs using a variety of high-level programming languages, including COBOL, FORTRAN, and C, and the OpenVMS Debugger. You can use any high-level language that adheres to the OpenVMS Calling Standard.
Oracle Trace is a tool that collects data and creates detailed reports on events that occur when an ACMS application runs. The information you collect with Oracle Trace can help you tune your ACMS system and improve performance.
For information on using Oracle Trace with ACMS applications, see
Compaq ACMS for OpenVMS Managing Applications.
1.5 Professional Services and Support
Compaq offers services to help with the design and development of ACMS applications, as well as support during the implementation and management of applications during run time. Services include:
For information on available TP system support services, see your
1.6 Overview of the ACMS Application Development Life Cycle
The application development life cycle is an approach and process for developing complex software applications in discrete segments, called phases.
The first phase in the life cycle for ACMS applications is the preparation of the design and development environment. This phase involves the installation of ACMS and other related software tools.
The second phase in the life cycle is the planning and design of the forms, databases, and applications. In building the TP system, system designers determine what business functions the application must address, and map those business functions to software and hardware capabilities.
The third phase in the life cycle is the development and testing of the forms, databases, and applications that were designed during the planning and design phase. In addition to developing forms and databases, application developers also define ACMS application components, generally for several different applications.
The fourth phase in the life cycle is the implementation and management of the TP system. System managers set up hardware for users, and move the TP applications into the user environment. Once the applications are in the users environment, the system manager maintains that environment.
Figure 1-7 shows how the phases fit together for a complete transaction processing development system.
Figure 1-7 Interaction of the Phases of the ACMS Application Development Life Cycle
With the ACMS software you can develop applications to automate business functions. An ACMS application is made up of a set of components and third-generation programming language code.
You use the ACMS Application Development Utility (ADU) to develop these components. ADU provides a high-level English-like definitional language that you use to write definitions for each component. After you write the component definitions, you use ADU to create binary versions of the files. These binary files are called database files. Although these binary files are known as database files or databases, they differ from traditional databases in which you can store and access data. For example, after you write a menu definition, you use ADU to build the menu database. At run time, ACMS uses the database files to run and control the application.
Figure 2-1 shows the relationships of the component definitions. One or more tasks make up a task group, and one or more task groups make up an application.
Figure 2-1 ACMS Application Components
Because ACMS applications are made up of sets of components, they are more efficient to run and easier to maintain than traditional application programs. ACMS task definitions separate forms processing from data processing. At run time, this separation helps ensure an efficient use of system resources. Maintaining the application is also simplified. Because each application component is a separate definition, you can modify applications by changing individual components, rather than rewriting the entire application.
This chapter provides an overview of the steps you take to build an ACMS application:
Each application is designed to meet a business need and automate a business function. In ACMS, the functions of a business relate to the tasks in an application. By analyzing the business needs, an application designer can make decisions about how best to map the business functions to ACMS tasks. The application design takes into consideration how users will work with the application as well as how the application will use system resources. When the design is complete, the job of defining ACMS application components and writing programming language code begins.
For more information on ACMS application design decisions, see
Compaq ACMS for OpenVMS Concepts and Design Guidelines.
2.2 Defining Tasks
In ACMS, a set of tasks in an application relates to a set of business functions. Tasks in a retail sales application might be recording a new sale and updating the inventory database. Each task, in turn, is made up of a series of steps that perform the actual work. The user can select one of these tasks from a menu. Figure 2-2 shows the basic structure of an ACMS transaction processing application.
Figure 2-2 Structure of an ACMS Application
Tasks are the building blocks of an ACMS application. They are the units of work a user selects from an ACMS menu.
From a user's point of view, a task is a single business transaction performed repeatedly during the course of a day, such as recording a sale or updating an inventory database or file. Figure 2-3 shows a simple menu that a sales or inventory clerk using a retail sales application might see. The clerk can choose between tasks for recording a sale or updating inventory records.
Figure 2-3 Simple ACMS Menu
Although tasks appear as individual items on the menu, they are typically made up of a series of steps that result in a change to a database or file. To share data among the parts of an application, ACMS provides special buffers called workspaces. Workspaces, for example, pass data between steps in the task and between tasks that work together in an application. The steps involved in updating an inventory database or file, for example, might retrieve the current record of an item, enter the updated information, and receive notification that the change was made correctly. ACMS uses workspaces to pass the updated information and notification.
The following sections provide an introduction to task steps and
2.2.1 Defining Task Steps
You use the ACMS task definition language to define these steps in an ACMS task definition. Task definitions describe the exchange of information between the terminal user and the application, and the processing of that information against the file or database. Typically, you define a task that includes more than one step. For example, you can define a two-step data entry task that consists of:
Figure 2-4 shows a form you might see after selecting the Sale task from the menu in Figure 2-3. An exchange step displays the form and prompts the sales clerk to enter a stock number, a description of the item, and whether the sale is cash or charge. A processing step records the sale, subtracts the item from the store's inventory, and prints an invoice for the customer.
Figure 2-4 Simple Form for a Sales Task
You can define more complex tasks in multiple-step tasks, which contain a sequence of exchange and processing steps. For example, a task that displays and updates an inventory record is made up of two exchange steps and two processing steps:
Figure 2-5 Task Steps for an Inventory Update Task
After the warehouse clerk selects the inventory update task, an
exchange step displays a query form and prompts the clerk to supply the
inventory item to be updated, in this case widgets. A processing step
calls a procedure that reads the widget inventory record. A second
exchange step displays the inventory, in this case 0 widgets, in an
update form, and allows the warehouse clerk to update the record to
reflect the arrival of 100 widgets. The final processing step calls a
procedure that stores the updated record in the inventory database or
126.96.36.199 Writing Server Procedures
Processing steps can run server procedures written in a high-level programming language. ACMS supports all programming languages that conform to the OpenVMS Calling Standard, such as COBOL, FORTRAN, or C. You use OpenVMS utilities to write, debug, and compile server procedures.
When all the procedures you need for a task or group of tasks are ready, you link the procedures to create a single procedure server image. At run time, ACMS creates at least one special process called a procedure server process, and activates and loads the procedure server image. When a user selects a task that uses the procedures, ACMS runs the programs. Figure 2-6 shows the parts of a procedure server.
Figure 2-6 Parts of a Procedure Server
When you create a procedure server, you include any initialization, termination, and cancel procedures as part of the procedure server image. These special procedures can help conserve system resources because the work they do is done once for the group of tasks that use the procedure server.
For more information on creating procedure servers, see Compaq ACMS for OpenVMS Writing Server Procedures.
188.8.131.52 Using DCL Servers
Processing steps can run OpenVMS images, DIGITAL Command Language (DCL) commands, and DCL command procedures. Tasks with these types of processing steps require a DCL server. You define a DCL server in a task group definition.
DCL servers are useful for running:
For more information on defining servers in task groups, see
Compaq ACMS for OpenVMS Writing Applications.
2.2.2 Defining Workspaces
Workspaces are temporary storage areas used to pass information in an application. Workspaces can pass data between:
For example, you use workspaces when you pass data from a form on a terminal to and from a database or file. A workspace can contain data provided by a user at a terminal through an exchange step or a processing step in the same task group. Tasks read information from workspaces and write information to them.
ACMS maintains three system workspaces that are available to tasks. Each system workspace has a different purpose:
All tasks belong to one or more task groups. A task group is a collection of one or more related tasks that have similar processing requirements and share resources. A task group definition contains such information as:
See Compaq ACMS for OpenVMS Writing Applications for information on defining task groups.
2.4 Defining Run-Time Characteristics for an Application
The application definition describes the run-time characteristics for an ACMS application, its servers, and its tasks. The run-time characteristics include information about which users can access tasks in the application and whether an audit of the application runs.
Defining the control characteristics of an application separately from its tasks and task groups allows you to use the tasks in different run-time environments.
You create an application definition using ADU. After you create the definition, you use ADU to build the definition into a binary application database file. ADU compiles information from the task group database file and the application definition to provide the ACMS run-time system with control information, pointers to task groups, and information required to run tasks.
You can change many of the characteristics of an application while the application is running. The changes remain in effect until the application is stopped. You make the changes permanent by modifying the application definition.
For more detailed information on defining ACMS applications using ADU, see Compaq ACMS for OpenVMS Writing Applications and Compaq ACMS for OpenVMS ADU Reference Manual. For information on changing the characteristics of a running application, see Compaq ACMS for OpenVMS Managing Applications.