This chapter provides an overview of transaction processing (TP) concepts, ACMS application development concepts, and the ACMS run-time system.

1.1 Transaction Processing Concepts

A business function is the administrative function or business exchange that you want to occur. A business function clearly defines the business exchange in terms of a simple action. For example:

Customer:	"I need to reserve a rental car."
Clerk:	"OK, I'll book that reservation for you right away. Please stay on the line."

A computer transaction supplies the mechanism for accomplishing the business function. Often several computer transactions are required to implement a single business function. A computer transaction can be a single independent database transaction, or it can be a distributed transaction that spans multiple database transactions.

Transaction processing is the implementation of computer transactions. A large part of transaction processing is the application programs written to perform computer transactions. These application programs usually involve updating a database to reflect changes to data and notifying the user that the change has taken place as intended. Transaction processing applications are typically high-volume, online applications that share the following characteristics and design issues:

• A moderate to large number of users work on the same transaction processing system at the same time. This results in a heavy demand for system resources (CPU, memory, and I/O), increasing the need for solutions that share these resources effectively.
• The applications involve predefined, structured work, such as adding items to inventory, updating a reservation list, or displaying employee records. This characteristic has design implications with respect to dividing a business area such as reservation processing into discrete functions, and dividing those functions into the correct sequence of activities required to perform each function.
• All transactions in the application use the same set of databases or files. When multiple users (or devices) require access to the application simultaneously, design issues arise for controlling database access conflicts and contention (often referred to as database concurrency issues). The databases may be centralized or distributed.
• Each transaction in the application can consist of several steps or operations. If one step fails, the transaction fails to complete, and all the effects of the transaction are removed from the database or files. A primary design issue here is how to ensure the data integrity of the database as transactions execute.

The transaction processing application described in the examples of this manual is called the AVERTZ application. This TP application performs a car reservation function for its users.

1.1.1 ACID Transactions

Transaction processing embodies the concept of a user-defined transaction that has a starting point and an endpoint. A transaction is both atomic and recoverable. A transaction is atomic, because either all of its operations take effect or none of them do. A transaction is recoverable, because, after a failure, the system either permanently commits or rolls back any outstanding transactions, leaving the database in a consistent state.

Figure 1-1 illustrates a money transfer transaction in which one account is to be debited while another is to be credited with the same amount. If a failure occurs after the start of the transaction (time t1) and before the end of the transaction (time t2), the system does not know whether debits equal credits at the time of failure. Therefore, the transaction processing system must abort the transaction and not update the database (either the debit or the credit). After the transaction aborts, you can resubmit the transaction for processing. In some cases, you can design the system to resubmit the transaction automatically.

Figure 1-1 Restoring a Database After a Failure

For a computer transaction to ensure that data remains in a consistent and uncorrupted state when a database is updated, the transaction must pass the ACID (atomicity, consistency, isolation, and durability) test:

• Atomicity --- A transaction has atomicity, that is, the operations that make up the transaction either all execute to completion, or appear as if they never occurred. If some operations succeed and others fail, the data in the database will not be in a consistent state.
• Consistency --- A transaction has consistency, that is, it successfully transforms the system and the database from one valid state to another. Consistency in a transaction processing system stems mainly from correct application programming (for example, always debiting and crediting the same amount).
• Isolation --- A transaction has isolation, that is, it behaves the same whether run serially or concurrently. If a transaction is processed concurrently with other transactions, it behaves as if it were the only transaction executing in the system. Transactions must not interfere with each other's database updates.
• Durability --- A transaction has durability, that is, all the changes that it makes to the database become permanent when the transaction is committed.

The ACID properties and the ability to recover in the event of a failure are primary design considerations for any transaction processing system. Compaq's resource managers ensure transactions with ACID properties.

1.1.2 Logical View of a Transaction Processing System

A transaction processing system comprises components that fit together to manage and control complex applications. Figure 1-2 shows a logical view of a TP system.

Figure 1-2 Logical View of a TP System

The user interface is the data input element in the TP system. The user interface usually includes a presentation service such as the DECforms forms management system. The AVERTZ sample application design, for example, incorporates DECforms, which integrates text and simple graphics into forms and menus that application programs use to collect and display information for the user. At run time, the form, the display device, and the application program send data to and receive data from one another.

A transaction processing monitor is a software product such as ACMS that provides an environment in which you develop and run transaction processing application programs. The TP monitor can include facilities for terminal and forms management, data management, network access, authorization and security, and restart/recovery.

The application consists of one or more pieces that receive the input data and initiate the required transaction. For the developer of application programs, the transaction processing environment usually provides:

• Presentation services to convert data from record formats as stored on the computer system to presentation formats that are easily dealt with by terminal users
• Database services that provide basic READ, WRITE, and UPDATE services, plus the coordination and resource scheduling that permits the application developer to access the system's database
• Queuing services that permit an application designer to submit transactions for execution at a later time for processing by other applications

A resource manager controls shared access to a set of recoverable resources, such as a database. A resource manager may be a database management system, file management system, or queuing facility. The data resource is a collection of data items that represent business information. The resource manager provides for reading and writing of data to ensure permanent storage of transaction results. The AVERTZ application uses the Rdb database management system.

Centralized transaction processing refers to a TP system in which all of the components run on the same computer.

Distributed transaction processing refers to a TP system in which one or more of the components run on separate computers and communicate across a network. For example, you can distribute the user interface to a smaller front-end computer, such as a MicroVAX system, and use more powerful computers, such as a VAX 9000 system, for back-end data processing.

Another form of distributed TP involves distributing databases. In some TP design situations, it is desirable to locate multiple databases on different computers. It may also be necessary to coordinate a transaction that spans multiple databases located on different computers.

1.1.3 Application Development Life Cycle

Several phases make up the life cycle of a TP application. For an overall perspective of application development, it is helpful to know where the design phase fits into this life cycle.

Figure 1-3 identifies the phases of the application development life cycle and illustrates the circular nature of a process that requires revisiting and refining an application several times during the course of developing a complex application.

Figure 1-3 Application Development Life Cycle

The following actions constitute an application development life cycle:

• During the orientation and installation phase, you install the product and the supporting products and deliver training in the development of applications.
• During the planning and design phase, you perform requirements analysis, functional analysis, and prototyping for an application.
• During the development and testing phase, you write and test the code that implements the design of the application.
• During the implementation and management phase, you transfer an application from your development system to a production system and fulfill system management requirements for the application.

At the beginning of this book is a map of all the ACMS information that supports the application development life cycle. This map lists the complete ACMS documentation that covers each phase of the life cycle.

1.2 ACMS Application Development Concepts

An ACMS application consists of a set of tasks that relate to the functions of a business. A task is the unit of work that a user selects from an ACMS menu. Each task usually comprises a sequence of steps that perform this unit of work. You use the ACMS task definition language to define tasks.

Figure 1-4 illustrates the basic principles of the ACMS task definition language (TDL)used to write a task definition. The task definition specifies an interface to the presentation service (forms management system) for communication with a terminal or other device. The task definition also specifies an interface to a procedure server for executing procedures (user-written subroutines) that handle database I/O and computational work.

Figure 1-4 Execution Flow of an ACMS Task Definition

The semantics of the ACMS task definition language are based on a call and return model. The task definition performs calls to the presentation service in exchange steps, and to the procedure server in processing steps. The presentation service and procedure server perform a function and return control to the task definition. Upon return of control to the task definition, subsequent parts of a step can evaluate the results of the call and, if necessary, handle any error conditions.

In Figure 1-4, for example:

1. In the first exchange step, the task definition calls the presentation service to display a form on the terminal screen (for example, a form to add a new employee record to a database). When the terminal user finishes filling in the form, the user presses a specified key (or keys) that returns the input data to the task definition.
2. In the processing step, the task definition then calls Procedure 1 in the procedure server to write that input data to the database. Procedure 1 then returns its results (either success or failure). If Procedure 1 succeeds, the task ends with a success status. If Procedure 1 fails to write to the database, the task continues executing at step 3.
3. In the second exchange step, the task definition calls the presentation service to send an error message to the terminal screen (for example, that the employee number of the new record duplicates an existing employee number). The presentation service then returns control to step 3, which ends the task.

The ACMS task definition language allows you to write an ACMS definition as a series of simple, English-like statements. The four types of ACMS definitions are:

• A task definition describes, in steps, the work to be accomplished in the task. For example, a task can collect information from a user and call a procedure to store the information in a file or database.
• A task group definition specifies similar tasks for control purposes and defines resources common to all tasks in the group.
• An application definition describes the environment and control characteristics of tasks and task groups.
• A menu definition describes how users access tasks in one or more applications.

You build the task, task group, and application definitions into binary files that run as an application under the control of the ACMS run-time environment. You build a menu definition into a binary file that is not necessarily tied to a single application.

Figure 1-5 illustrates the ACMS development components for a simple ACMS application with two tasks (for example, one to add a new employee record to a database, and one to update an existing employee record).

Figure 1-5 ACMS Application Components

Figure 1-5 does not show that there can be more than one task group definition specified for a single application. Also, more than one menu definition can specify tasks that point to the same application. Conversely, a single menu definition can specify tasks in different applications.

Because ACMS applications are modular, you develop each part of an application independently. If you need to change a task definition later, the change does not necessarily affect the task group, application, or menu definitions. Many types of changes do not affect other modules.

1.2.2 Composition of ACMS Definitions

A task definition controls the exchange of information with the user, and the processing of that information against the file or database. Each ACMS task definition is made up of one or more steps. ACMS breaks the work to be accomplished by a task into two types of steps:

• Exchange steps usually interact with the Form Manager to handle forms I/O (that is, the exchange of information between the task and the user). An exchange step can interact with DECforms or TDMS forms, or interface with other devices using the ACMS Request Interface or the ACMS Systems Interface for communicating with nonstandard devices. Figure 1-4 illustrates an execution flow with two exchange steps.
• Processing steps call step procedures (user-written subroutines) to handle computations and interactions with databases or files, typically using procedures written in a high-level programming language (any language adhering to the OpenVMS Calling Standard). ACMS uses two types of servers: procedure servers for executing a procedure, and DCL servers for invoking images or DCL commands. Figure 1-4 illustrates an execution flow with one processing step.
  A server process may perform an initialization routine of common work when the server is started, rather than each time a task is selected. ACMS manages pools of servers to save on process creation and image activation.
  Servers are single-threaded and serially reusable (that is, while attached to a task, a server process is not available to other tasks until released by the task). A single server process can be called by many different ACMS tasks in a serial fashion. Once a call is complete, the server is then available to be called by another ACMS task.
  When ACMS starts a processing step, it allocates a procedure server process to a task to execute the procedure in that step. This single-threaded process remains allocated to the task for the duration of one or more processing steps.

In ACMS, a workspace is a buffer used to pass data between the task and processing steps, and between the task and exchange steps.

Task group definitions combine similar tasks of an application that need to share common resources such as workspaces, DECforms forms, and procedure servers.

The application definition describes:

• Task groups that belong to an application
• Characteristics that control the tasks, such as security restrictions on which users can select a particular task
• Servers, such as the number of server processes that can be active at the same time
• Application characteristics, such as whether application activity is recorded in the audit trail log

Menu definitions list both tasks and additional menus that a user can select from a menu. For example, the tasks on a menu can include adding new employee records, displaying employee information, and entering labor data.

When you write definitions for ACMS tasks, ACMS automatically stores the definitions in a CDD dictionary. At run time, the definitions are represented in binary form in databases defined by ACMS. For example, a task group definition is represented by a task group database that contains a binary representation of the task group definition.

1.2.3 ACMS Workspaces

ACMS tasks can use three types of workspaces: task, group, and user. Task workspaces commonly pass information between processing steps and exchange steps. They can be used only by a single task, but may be passed as parameters to other called tasks. Task workspaces exist only for the duration of the task. A system workspace is a special task workspace that ACMS provides that contains information about the state of the task and about the task submitter.

You can use group and user workspaces to share information among several tasks in a task group. They are available to all the tasks in a task group. A group workspace is allocated when the first task needs it and remains available for the life of the application.

A user workspaceis allocated to a terminal user the first time the user selects a task in the task group, and remains available until the user logs out or the application stops. User workspaces store information that pertains to an individual user.

1.3 ACMS Integration with DECforms

Although ACMS supports several presentation services, ACMS supports DECforms as its primary presentation service. DECforms provides such features as FIMS compliance, device-class independence, storage of form context between exchanges, input verification (values, ranges, and types), and escape routines.

1.3.1 DECforms Concepts

The DECforms architecture provides a full separation of form from function. This separation allows you to write an application program (the function) without being concerned with the intricacies of the user interface (the form) for that program.

Normally, the term form means a document with blanks for the insertion of information. In DECforms, however, the form is a specification that may govern the complete user interface to an application program. The form specification completely describes all terminal screen interactions, the data that is transferred to and from the screen, and any display processing that takes place.

A panel consists of the information and images that are physically displayed on the user's terminal screen. A panel is composed of such items as fixed background information (literals), fields (blanks for insertion of information), attributes, function key control, and customized help messages.

You can partition the display into rectangular areas called viewports by specifying viewport declarations within the form definition. You can adjust the viewport to any size and locate it anywhere on the display (such that viewports overlap one another). For a panel to be visible, it must be associated with a viewport.

Figure 1-6 illustrates the concept of specifying panel declarations and viewport declarations within the DECforms form definition. You specify a viewport name within each panel declaration. By doing this, you map each panel to a specific viewport. At run time, each panel appears on the terminal screen within its viewport.

Figure 1-6 Panels and Viewports

The DECforms Form Manager is the run-time component that provides the interface between the terminal display and an ACMS application. The Form Manager controls panel display, user input, and data transfer between the form and ACMS. A DECforms form is loaded by the Form Manager at execution time under the direction of an ACMS task.

ACMS begins a session with DECforms when an ACMS task first references the form. The syntax that references the form is contained in the ACMS task definition.

1.3.2 ACMS Interaction with DECforms

In DECforms, the form record is a structure that controls data transfer between ACMS and the form. The form record identifies which form data items (variables associated with the form) are to be returned to ACMS.

Figure 1-7 shows the interaction between DECforms and ACMS when ACMS requests information from DECforms.

Figure 1-7 DECforms Interaction with ACMS

The following steps are the sequence of events that occur when ACMS requests information from DECforms:

1. To request information, ACMS calls the Form Manager with a RECEIVE or TRANSCEIVE call. In that call, ACMS performs the following operations:
   1. Tells the Form Manager the name of the form needed to collect data.
   2. Tells the Form Manager the record identifier being received.
   3. Gives the Form Manager the ACMS workspaces used to transfer data.
2. The Form Manager displays a panel on the user's terminal screen. The displayed panel is specified in the form that ACMS names in its RECEIVE or TRANSCEIVE call to DECforms.
3. The Form Manager accepts input from the user's terminal.
4. The Form Manager uses the form record to store the user's input data in the appropriate form data items.
5. The Form Manager completes the request by returning data to the ACMS workspaces.

To distribute forms processing, you can off-load a presentation service such as DECforms onto a front-end system (or submitter node). From there, users select tasks that are submitted over the network to a back-end system (or application node). The back end contains the application and resource managers that perform the application execution and data processing, respectively. Figure 1-8 illustrates this configuration.

Figure 1-8 Off-Loading Forms Processing to a Submitter Node

In a multithreaded system such as ACMS, a single process can manage more than one user or process at the same time. Consequently, a single process on the submitter node can display forms and menus for many users. A single process on the application node can handle flow control for many users at one time.