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:

• Rdb, a relational database management system
  Rdb is a full-function relational database management system for general purpose, multiuser, centralized or distributed TP applications. It is relatively easy to use, yet provides high performance and the ability to restructure data relationships.
  Use Rdb if the structure of your database is expected to change significantly over time. You can use the SQL data definition and manipulation language with Rdb databases.
• DBMS, a CODASYL-compliant network database management system
  DBMS is a high-performance database management system for general purpose, multiuser TP applications in which the relationships between different parts of the database are very complex.
  Use DBMS for applications that involve complex but relatively stable data relationships and predictable information requests.
• RMS, a record management system
  RMS is the OpenVMS operating system's default file management system with optional journaling. (Journaling is the process of recording information about operations on a file into a recoverable resource.) Access to data stored in RMS files can be either sequential or random, with the random access being either by key (for indexed files) or by record number (for relative files).
• Other database products or file management systems that support the OpenVMS Calling Standard

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:

• Ensures the integrity of shared metadata and the procedures used to analyze, maintain, manage, and design business metadata
• Provides a centralized repository for information management shops
• Offers a dynamic aid to software application development

As a member of a family of layered software products, ACMS makes use of high-level programming languages and tools.

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.

Compaq also provides a group of programming productivity tools, called DECset, that help you code, test, manage, and maintain applications. DECset tools include:

• DEC/Code Management System (CMS)
  CMS is a program source file library for software management and version tracking.
• DEC/Module Management System (MMS)
  MMS is a tool that automates and simplifies the building of software systems.
• Language-Sensitive Editor (LSE)
  The Language-Sensitive Editor (LSE) is a multilanguage editor that helps you quickly and accurately write application programs. Templates for commands and statements in a variety of languages and layered products, including ACMS, SQL, and DECforms, are provided with LSE.
• Source Code Analyzer (SCA)
  SCA is a multilanguage, interactive cross-reference and static analysis tool that can help you understand the complexities of a large software project.
• Performance and Coverage Analyzer (PCA)
  PCA is a tool that analyzes program test coverage and the run-time behavior of your application.
• DEC/Test Manager (DTM)
  DEC/Test Manager is a tool that organizes and automates the performance and evaluation of software tests.

For more information about programming productivity tools, see A Methodology for Software Development Using OpenVMS Tools, or the documentation for each individual product.

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:

• Training for application designers, developers, and system mangers
• Training on related OpenVMS layered products
• Design and development consulting services
• Software support and problem-solving
• Software tool kits designed to help in the building of a TP system

For information on available TP system support services, see your Compaq representative.

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.

The next three chapters describe the development, implementation, and management of ACMS applications.

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.

The components of an ACMS application are:

• Task definitions to describe units of work
• Task group definitions to describe the resources required by a group of tasks
• Application definition to describe the environment and control characteristics of tasks and task groups
• Menu to display a list from which terminal users can choose an available task

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:

1. Map business functions to tasks.
2. Define the tasks.
3. Define the resources for groups of tasks.
4. Define the run-time characteristics for an application.
5. Define the forms and menus.
6. Debug and test the 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 workspaces.

2.2.1 Defining Task Steps

Task steps perform the basic work involved in each of the events that make up a business transaction. You can separate the work to be accomplished by a task into the following types of task steps:

• Exchange steps handle data input/output, interacting with DECforms or TDMS forms, or with other presentation services and devices using the ACMS Request Interface.
• Processing steps handle computation or interaction with databases or files. Processing steps can use either a procedure written in a high-level programming language (such as COBOL, FORTRAN, or BASIC), DCL commands, or OpenVMS images.
• Block steps collect the task steps (exchange and processing) into functional groups. Grouping task steps makes the structure of the task definition more modular and, therefore, easier to develop and maintain.

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:

• An exchange step to display a form that prompts the user to supply information such as a stock number and a description of an inventory item
• A processing step to write the information the user supplies to a database or file

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:

1. An exchange step in which the user supplies information to a form on a terminal, in this case the item whose inventory record is to be updated
2. A processing step in which a procedure reads the item's inventory record from the database or file
3. An exchange step in which the inventory record is displayed in a second form on the terminal and the user updates the record
4. A processing step in which the updated record is written to the database or file

Figure 2-5 shows the sequence of exchange and processing steps for a simple inventory update task a warehouse clerk might select from the menu in Figure 2-3.

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

2.2.1.1 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

In addition to the step procedures that run in processing steps, you can write special procedures to maximize system resources, including:

• Initialization procedures to open all the files and to ready any databases needed by a group of tasks
• Termination procedures to close at one time all the files and any databases used by a group of tasks
• Cancel procedures to clean up context held by a task in a server when the task cancels before completing successfully

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.

2.2.1.2 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:

• OpenVMS utilities, such as MAIL
• Existing programs you want to run under ACMS without converting immediately into ACMS multiple-step tasks
• Third-party software required by some ACMS application users, such as spreadsheets

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:

• Steps in tasks
• Tasks in a task group
• Forms and tasks
• Processing steps and databases or files

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:

• When a user selects a task, ACMS stores any text the user supplied in the ACMS$SELECTION_STRING system workspace.
  For example, when a user selects a task from a menu by entering a number and then text, the text is stored in the ACMS$SELECTION_STRING system workspace. The task the user selected can access the string stored in the workspace.
• When a task runs, ACMS stores the status of task steps in the ACMS$PROCESSING_STATUS system workspace.
  You can use the workspace to check for the status of a task step and take appropriate action.
• ACMS stores information about a user and the user's device in the ACMS$TASK_INFORMATION system workspace.
  For example, you can define a task that uses information about the user to determine what type of work to perform.

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:

• Procedures called by the tasks in the group.
• DECforms forms used by the tasks in the group.
• TDMS request libraries used by the tasks in the group.
• Message files used by the tasks in the group.
• Procedure servers available to the task group and any special server attributes, including server name and server image file specification, names of all step procedures handled by the server, and optional initialization, termination, or cancellation procedures.
• Workspaces available to the task group.

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.