The ACMS transaction processing system is a TP monitor that runs on the OpenVMS operating system. It is intended for businesses that require high performance, security, data integrity, and both centralized and distributed processing. Retail, banking, financial services, telecommunications, health, customer service, manufacturing, and insurance are some of the industries that can make use of the ACMS system.

With ACMS, businesses can shrink development time for their applications, streamline application maintenance, and lower the cost per transaction. Applications can be configured for distribution over many systems, providing a flexible response to changes in business conditions. The open-ended OpenVMS architecture and networking allow for growth without disruption of services.

This chapter describes the TP style of computing, its differences from traditional timesharing computing, and the key features of an ACMS TP system.

1.1 Transaction Processing

Transaction processing allows businesses to maintain timely and accurate data about their operations. Many users access the same database or databases to perform a series of steps related to a business function. Each activity represents a transaction. Transactions can occur between a user and a computer, or just among computers.

The applications written for transaction processing usually involve updating a database and notifying the user that the change has taken place as intended. Maintaining up-to-date, accurate databases is an essential function of transaction processing applications.

Examples of typical TP applications include processing a customer's request for withdrawal or deposit of funds, maintaining a retail store's online inventory, and cross-referencing and updating of patients' medical records.

In these cases, many users from different locations want access to the same database, at the same time, for a specific business activity. As a result, high availability, rapid response time, and data integrity are important criteria for a TP system.

Other important requirements of a TP system are:

• Systems must be capable of growing.
• Databases must be available and stay reliable throughout transaction processing.
• The TP system must allow for different levels of technical sophistication for its users.

Before transaction processing systems became a reality, first batch processing and then timesharing were the computing styles that handled the large volume of data transactions necessary for business.

In a timesharing system, each user has a separate process, and computer resources are parceled out according to a schedule that makes it appear that each process has the full attention of the central processing unit (CPU). Some processes can interact with a database; others can run word processing, a spreadsheet, or other interactive software. Figure 1-1 shows a typical timesharing system, which has many users using display terminal s and interacting with a CPU.

Figure 1-1 Traditional Timesharing Environment

TP applications are typically high-volume, online applications with repetitive operations on data critical to the mission of a business. In a traditional timesharing system, these applications can tax system resources because each user requires a separate process.

Specialized transaction processing systems were developed to make more efficient use of system resources and to provide utilities for managing and controlling these complex applications. Figure 1-2 illustrates a transaction processing system environment.

Figure 1-2 Transaction Processing System Environment

A TP system, like a typical timesharing system, has many users, but they do not each require a separate process. Instead, a TP monitor manages access to the CPU, functioning like a specialized operating system within your operating system.

The TP monitor can include facilities for terminal and forms management, data management, network access, authorization and security, and restart/recovery. These facilities allow you to control what users do, how often they do it, and when they do it.

1.3 ACMS TP Monitor Features

ACMS is a TP monitor that provides a development, run-time, and application management system for TP applications. It is designed for a modular, flexible development style and efficient use of system resources in large on-line applications.

ACMS combines a structured, high-level application definition language and utilities to build, manage, and control complex applications. The modular nature of ACMS applications makes them more efficient to develop and run, and easier to maintain than traditional applications programs. ACMS applications can be modified by changing individual components, rather than rewriting the entire application.

ACMS is also part of an integrated application development environment which includes presentation services, transaction and database management, programming languages, and tools.

1.3.1 Configuration Options

Terminal, menu, and other input/output (I/O) functions are separated in ACMS from database or file processing and computational functions. The terminal and menu functions are handled on the front end of the transaction processing system, while the data processing and computation are performed on the back end of the system. Figure 1-3 illustrates the operation of ACMS front-end and back-end processing.

Figure 1-3 Front-End/Back-End Processing in a Local ACMS System

The separation of functions in ACMS makes it possible for you to distribute ACMS applications across a network of computers, installing front-end functions on one or more nodes and back-end functions on another set of nodes in the network. In a distributed transaction processing environment, the front end is also called the submitter node, because it is the node from which tasks are selected and sent to the back-end node. The back end is also called the application node, because it is the node on which the application execution and data processing are performed.

Figure 1-4 illustrates an ACMS system environment distributed across a network.

Figure 1-4 Distributed ACMS System

Most TP applications put heavy demands on computer processing power and memory resources. An important requirement for TP applications is that they make efficient use of the resources available. With a traditional TP system, structuring applications to minimize the strain on a system can demand additional design and programming time. ACMS is designed to use computer resources, such as memory and CPU, efficiently to help maximize run-time performance.

ACMS uses dedicated OpenVMS processes to manage terminal I/O, execute processing and data manipulation subroutines, and control the application run-time system.

ACMS has a multithreaded internal design. In a system that uses multithreaded processes, a single process can manage more than one user or process at the same time. On the front end of an ACMS system, a single process can display forms and menus for many users rather than have each user need a separate process to do this work. On the back end, a single process can handle the flow control, or the complex coordination of data processing and computations, of each user's work rather than have OpenVMS manage each user's process separately. Also on the back end, rather than each user using a separate process to access the database, a single process can manage paths into the database for many users at one time. To help you manage heavy system use, ACMS allows you to create additional processes on the back end as the need arises.

The separation of functions in ACMS makes it possible to increase the speed and reliability of ACMS transactions by distributing the front-end and back-end functions across a network. You can offload forms processing to a smaller front-end computer, like a MicroVAX, and use more powerful computers, like a VAX 8800 or a VAX 9000, for back-end data processing. You can configure each node in the distributed system for the processing of specific tasks.

1.3.3 Easy System Expansion

It is easy to expand an ACMS system to meet your growing business needs. Without rewriting your application code, you can distribute existing ACMS applications or add nodes to an existing network of distributed ACMS applications.

You can install and run ACMS applications on the full range of VAX and Alpha computers, from the small MicroVAX to the powerful VAX 9000 mainframe.

To accommodate more users, you can add small clusters of VAX and/or Alpha computers as front-end nodes to handle additional terminal and forms processing. To increase application processing capabilities, you can add high-performance VAX and/or Alpha computers as back-end nodes.

1.3.4 Availability

By distributing the forms processing functions of an ACMS application, you can make the system more available in the event of system failures. Using the features of DECnet network software, OpenVMS Cluster networks, and volume shadowing, ACMS eliminates single points of system failure and significantly increases the amount of time your applications are available to you.

Figure 1-5 illustrates a configuration in which an ACMS system uses MicroVAX computers in a local area OpenVMS Cluster network as front-end submitter nodes, and uses a back-end OpenVMS Cluster for database or file functions.

The configuration in Figure 1-5 ensures that an application is available under the following circumstances:

• If one node in the local area OpenVMS Cluster becomes unavailable, users are automatically routed to an available front-end node in the OpenVMS Cluster. The front-end terminal I/O is automatically handled by the available node. Using LAT terminals can provide additional failover capabilities on a front end.
• If one back-end node becomes unavailable, ACMS routes transactions to another back-end node. Database or file recovery is provided for the failed node, restoring the database or file to its original condition.
• If a single disk becomes unavailable, volume shadowing transparently provides a replacement for it.

For more information on configuring your ACMS system for high availability, see Compaq ACMS for OpenVMS Managing Applications.

Figure 1-5 OpenVMS Cluster Configuration in a Distributed ACMS System

Some ACMS applications use data that is collected and processed interactively. The application displays a menu or a form on a video terminal through which users enter data. Then the application processes the data and either displays the results of the processing or requests more data.

Other ACMS applications require that data be collected once and then stored in a temporary storage area, or queue, for the application to process at another time. For these types of applications, data can be collected using a device other than a terminal, such as a card-punch time clock, and sent to a special ACMS queuing facility. The ACMS queuing facility lets you place tasks in a queue and then submit the tasks for processing at another time. Using the queuing facilities provided by ACMS, you can design applications to immediately process in real-time (such as capturing data), and alternatively defer processing of work that does not require real-time processing until later.

Applications that benefit from queuing have the following types of requirements:

• Data capture and deferred processing of data
  An example of this type of application is one that processes hundreds of time cards in a very short time during a shift change. In this type of application, processing each data item immediately can affect system performance and be costly in the use of system resources. Employees would have to wait in line while each time card was read into the system and then processed. The ACMS queuing facility lets you capture the data quickly and store it for future processing.
• High application availability
  In a distributed environment, if the back-end node becomes unavailable, the front-end node can continue to submit tasks to queues. When the back-end node becomes available, the ACMS queuing facility automatically submits the tasks for processing.
• Data and transaction integrity
  If the system becomes unavailable while processing a queued task, the ACMS Queued Task Initiator (QTI) continues trying to submit that task. As with all ACMS queued tasks, the dequeue (removal from the queue) and database updates are all tied together as a single transaction, ensuring that database updates will take place once and only once. The changes that the task was making to the database at the time of failure are not made permanent until the task succeeds. This is one way that ACMS can ensure the integrity of your database.

For more information on ACMS queues, see Compaq ACMS for OpenVMS Writing Applications.

1.3.6 Modular Applications

ACMS applications are made up of a set of component definitions that describe and control the work of an application, and a set of subroutines that access databases and files. You use the ACMS Application Definition Utility (ADU) for creating and processing the component definitions of an ACMS application. To write application subroutines, called server procedures, you can use any third-generation language that conforms to the OpenVMS Calling Standard, such as C or COBOL.

ADU includes a high-level, English-like definitional language. You use the statements and clauses of the language to create definitions for each application component of an ACMS application. In addition, you use ADU commands to process the definitions. When you process a definition, you build a binary file from the definition that is interpreted at run time.

ACMS applications are easier to develop and maintain than traditional applications because modular definitions replace system programming calls. Developing sets of component definitions and application subroutines emphasizes the principles of structured programming. As a result, you can divide responsibilities for developing parts of an application among many programmers.

The modularity of ACMS applications also makes maintenance easier. Terminal I/O is separate from data processing, and application logic is separate from system and application management. To change an application, you make changes to a component's definition, rather than rewrite the entire application.

Chapter 2 provides an introduction to developing ACMS applications. For detailed information on developing applications using ADU, see Compaq ACMS for OpenVMS ADU Reference Manual and Compaq ACMS for OpenVMS Writing Applications.

1.3.7 Data and Transaction Integrity

TP systems must ensure that data remains consistent and work remains intact if the system or database becomes unavailable. Using data management products and the DECdtm Services for OpenVMS (a collection of OpenVMS services that provide for the management of distributed transactions), ACMS provides full data and transaction integrity and consistency.

A resource manager controls shared access to a set of recoverable resources, such as a database. In an application that accesses a single database or set of files, resource managers ensure integrity by providing rollback recovery. Resource managers available to ACMS include RMS, Rdb, and DBMS. When a database transaction updates a database, the resource manager commits the change when the transaction ends. Committing the change makes it permanent. If the system or database becomes unavailable before the database transaction ends, the resource manager rolls back the database, returning it to the state it was in before the transaction started.

For applications that use distributed transactions, that is, a single grouping of operations on more than one recoverable resource or resource manager, the DECdtm services provide rollback recovery following a two-phase commit protocol. Two-phase commit protocol ensures that, when changes are made to data during a distributed transaction, either all resource managers commit the distributed transaction or all work will be rolled back.

The two phases of the protocol are:

• Prepare phase, in which each resource manager indicates a willingness to commit
• Commit phase, in which each resource manager is instructed by the controlling transaction manager to either commit and roll forward, or abort and roll back

Typically, you use DECdtm services when you design an application that:

• Processes data in more than one database or file on a single node or across a network
  If a transaction is prevented from completing anywhere on a network, the entire transaction is rolled back to its starting point, and your work can be recovered.
• Queues tasks and their data
  DECdtm services guarantee that a queued task is entered on the queue and that the task is not removed from the queue until the data is processed successfully exactly once.

DECdtm components include a transaction manager and resource managers. The transaction manager oversees the phases of a two-phase commit for either a database transaction or an ACMS queuing facility operation. Resource managers (such as Rdb, DBMS, and RMS) manage the access to their recovery data and databases.

Each node in the network has its own DECdtm transaction manager and one or more of the supported resource managers. For each transaction, a DECdtm transaction manager tracks which resource managers are being used to process data. If an event on the system keeps the transaction from completing anywhere on a network, all databases affected by that transaction are rolled back to their original state.

You can also design applications that use the ACMS queuing facility to place tasks in a queue file. The ACMS queuing facility uses DECdtm services to ensure that every task on the queue is processed exactly once. In a distributed system, tasks and their data can be entered on the front-end queue. If the back-end node becomes unavailable, the tasks and their data are held in the queue. When the back-end node becomes available again, the tasks are submitted for processing.

1.3.8 Security

ACMS ensures that your data remains secure by giving you control over which users have access to ACMS. Using OpenVMS and ACMS authorization facilities, you can:

• Authorize users to use ACMS
• Control terminals connecting to ACMS
• Limit the applications a user can run

For example, you can give a personnel employee access to a task that updates a confidential file, but ensure that the employee cannot view sensitive information in the file, make unauthorized changes to the file, or gain access to the file outside the context of the task.

For a more detailed introduction to defining access to ACMS and applications, see Chapter 4. For details on managing an ACMS system, see Compaq ACMS for OpenVMS Managing Applications.

1.3.9 Presentation Services

Users select and run ACMS tasks from menus. Figure 1-6 shows a sample ACMS menu.

Figure 1-6 Sample ACMS Menu

To create menus, ACMS supports DECforms, a forms product running on the OpenVMS operating system, as its primary presentation service. In addition, ACMS provides support for VAX Terminal Data Management System (TDMS). DECforms is the first commercial implementation of the proposed ANSI/ISO standard Form Interface Management System (FIMS), a system for interaction between applications and display devices. Using DECforms, you can write a forms application program (which describes the function of a display) separately from the user interface of the display (such as a menu or form).

ACMS uses standard menus in both DECforms format and TDMS format. You can easily customize these standard menus. For more information on using DECforms or TDMS, see the appropriate product documentation. For an example of using DECforms to create standard ACMS menus, see Chapter 11.

ACMS provides support for other presentation service products. Using the ACMS Request Interface and the ACMS Systems Interface, you can create applications that use forms management products, such as FMS, or special devices, such as electronic badge readers.

The Request Interface allows you to use presentation services other than DECforms or TDMS for I/O functions limited to one user per process. ACMS provides an easy-to-use programming interface with the Request Interface to forms products such as FMS (Forms Management System), SMG (Screen Management Facility), terminal interface products from other vendors, and menus in an ALL-IN-1 office integration system.

The Systems Interface allows you to use presentation services for single-user or multiple-user I/O functions. The Systems Interface provides a set of software system services that give systems programmers the flexibility to design customized interfaces for complex systems or devices, such as badge or bar code readers.

For more information on using the Request Interface, see Compaq ACMS for OpenVMS Writing Applications. For more information on using the Systems Interface, see Compaq ACMS for OpenVMS Systems Interface Programming.