Resource managers (RMs) are the software products that store and manage the data accessed by ACMS applications. A resource manager controls shared access to a set of recoverable resources, such as a database.

All of the resource managers supported by the ACMS software provide access to recoverable data, because they support ACID transactions (that is, the transactions are atomic and fully recoverable). Step procedures can access the following resource managers either locally or remotely:

• Rdb database management system
• DBMS database management system
• RMS file management system
• ACMS queuing facility

The resource managers supported by the ACMS software are not part of the TP system, but are instead data management systems layered on the operating system (OS). This OS layering of resource managers permits database sharing among TP and non-TP applications, decision support systems, and remote nodes requesting data.

Because ACMS supports Rdb as its primary database management system, the following section discusses Rdb concepts. For additional Rdb conceptual information, refer to the Rdb documentation.

1.4.1 Rdb Database Management Concepts

A database management system searches for data in a database by following a path. In some systems, the designer specifies detailed path information. In other systems, the software determines this information for itself. In all systems, designers can take steps (such as specifying advanced features) to improve the performance of the database application. Although there are three database types (hierarchical, network, and relational), this discussion covers only the relational database model.

A relational database such as Rdb represents data as a set of independent tables. A table (also called a relation) is a collection of rows (records) and columns (fields). At each row-column intersection, you can store a single data item (such as a customer's last name). Each table usually contains many individual data records (for example, one record for each customer).

In an Rdb database, relationships among data items are not physically stored. Instead, data is stored in the tables, and relationships between two or more records are established by matching the values of fields common to those tables (such as the CAR_ID field in Figure 1-9). Because the CAR_ID field is common to both records, it is easy to associate a particular car with information about who is renting it.

Figure 1-9 The Relational Database Model

A relational database permits quick and easy maintenance of a database that changes frequently (for example, one that is affected by tax laws or government regulations). To increase the complexity of relationships that can be drawn among data in the database:

• Change existing row-column information --- For example, you can add new columns to an existing row in the CARS table, with information about the car's features, such as engine size.
• Add new tables with relationships to existing tables --- For example, you can create a new table with columns about each location in the car rental firm, enter data records with information for all locations, and then use a common column (location code) to combine information about specific locations and the cars at those locations.

The major data manipulation language for a relational database is SQL. This language is an ANSI standard that allows different vendors' database management systems to use the same language.

1.4.2 ACMS Interaction with a Resource Manager

To access a database, ACMS interacts with a procedure server process. The procedure server process, in turn, interacts with the resource manager of the database. As shown in Figure 1-10, processing steps call step procedures (user-written subroutines) to handle interactions with the resource managers of databases or files.

ACMS uses a procedure server process for executing a procedure. When starting a processing step, ACMS allocates a procedure server process to the task to execute the procedure for that step. The procedure server process remains allocated to the task for the duration of one or more processing steps in the task.

In an update task, you need at least one exchange step to prompt the user for a key value, and another to display the requested record for modification. You need one processing step to retrieve the record from the database, and another to write the record back to the database with the user's changes. Figure 1-10 shows the interactions between ACMS and the procedure server process, and between the procedure server process and the resource manager, to execute a simple update task.

Figure 1-10 A Resource Manager Interacting with ACMS

The update task executes the following series of steps:

1. An exchange step calls the Form Manager (not shown) to display a panel on which the user can supply a key value (for example, an employee number).
2. A processing step calls Procedure 1, which in turn retrieves the employee record from the database through its resource manager. The procedure uses the employee number as a key into the database.
3. An exchange step calls the Form Manager to display a panel with the information contained in the employee record. The user can modify this information (for example, change the employee's address).
4. A processing step calls Procedure 2, which in turn writes the modified employee record to the database.

For a full picture of the ACMS execution flow that includes the Form Manager's role in exchange steps, refer to Figure 1-4.

1.4.3 Distributed Resource Managers

One form of distributed TP involves distributed databases. Because of size, manageability, or performance considerations, it is sometimes necessary to partition a single large file or database into a number of smaller ones. In some cases it is also desirable to situate separate databases on different nodes.

ACMS transactions can span multiple resource managers either locally or remotely. An ACMS application uses the DECdtm transaction-management services to guarantee atomic updates to two or more independent databases. Moreover, these databases can be of different types. For example, a distributed transaction can involve Rdb, DBMS, and RMS resource managers.

1.5 ACMS Distributed Transactions

One part of ACMS application development is deciding whether ACMS transactions need to be distributed transactions (that is, multiple database transactions coordinated by the DECdtm services). The DECdtm services are part of OpenVMS and provide the transaction management system support for distributed transactions. These services support a two-phase commit protocol that guarantees atomicity of distributed transactions.

In its role as the transaction coordinator, a DECdtm transaction manager communicates with the resource managers and implements the two-phase commit protocol needed to ensure atomicity of distributed transactions. With this protocol, a transaction can be committed only when all the resource managers involved in the transaction have acknowledged that they are ready and able to commit the requested modifications to the databases.

ACMS makes use of DECdtm transactions to coordinate transactions that involve:

• Multiple resource managers
  For example, it is possible to coordinate modifications to two Rdb databases located on the same or different nodes.
  It is also possible to coordinate modifications to different databases, such as an Rdb database, a DBMS database, and an RMS file, located on different nodes or on the same node.
• ACMS task queues and resource managers
  For example, ACMS can coordinate the insertion of queued task entries into an ACMS queue file (marked for RMS recovery-unit journaling) with changes made to an RMS file or a database such as Rdb or DBMS.
  ACMS can also coordinate the removal of queued task elements from an ACMS queue file (marked for RMS recovery-unit journaling) with the changes made to a file or database.
  An ACMS queue file is an RMS indexed file. To use recovery-unit journaling on an ACMS queue file, you must have installed the RMS Journaling layered product.

Any of the following components can start and end a distributed transaction: a task definition, the ACMS Queued Task Initiator (QTI), a user-written agent, or a step procedure.

1.5.1 Coordination of Multiple Resource Managers

In a distributed network of TP systems, a DECdtm transaction manager on each node coordinates the actions of transaction participants, such as resource managers, on that node. The transaction manager on the node where the transaction was started is responsible for coordinating the two-phase commit protocol for the transaction.

In the execution of a transaction, participants can include:

• Multiple resource managers on a local node, spanning one or more processes
• Multiple transaction managers on other nodes in the network, and their associated resource managers

In Figure 1-11, the transaction manager on node 1 coordinates the transaction started by the application program on node 1 with the participating transaction manager on node 2. The transaction boundary of this single distributed transaction encompasses two resource managers: an Rdb resource manager on node 1, and a DBMS resource manager on node 2. Coordination by DECdtm ensures that either the update occurs to both databases or that the update does not occur at all.

Figure 1-11 Coordinating Multiple Resource Managers

ACMS provides a queuing facility to capture and initiate tasks in an application. In nondistributed transactions, to guarantee "exactly once" semantics, you must use the unique queue-record identifiers generated by the ACMS queued task facility. (See Compaq ACMS for OpenVMS Writing Applications.) In distributed transactions, however, using the queue element identifiers is not necessary.

In a distributed transaction, DECdtm transaction managers coordinate transactions involving queuing and dequeuing activities, and related database updates. For DECdtm services to coordinate the removal of queued task entries from a queue file with the changes made to databases by those queued tasks, you must mark the queue file for RMS recovery-unit journaling using the SET FILE/RU_JOURNAL command.

Figure 1-12 illustrates two distributed transactions:

• Transaction 1 with a queuing operation
  The transaction manager on node 1 coordinates transaction 1 (started by the application program on node 1). Transaction 1 updates the local Rdb database and inserts a queued task element into an ACMS queue file (an RMS indexed file).
• Transaction 2 with a dequeuing operation
  At some later time, the transaction manager on node 1 coordinates transaction 2 (started by the QTI of the ACMS system on node 1). Transaction 2 removes the queued task element from the ACMS queue file. Transaction 2 then invokes the task on node 2 that updates the Rdb database on node 2, all as a single transaction.

Before reading an entry from a queue file marked for recovery-unit journaling, the QTI starts a DECdtm transaction. After reading the record in the queue file, the QTI then starts the specified task.

If the task completes successfully, the QTI deletes the queued task record from the queue and ends the transaction. If the task fails, the QTI aborts the transaction, causing any database or file modifications made by the queued task to be undone.

The QTI starts another transaction to process a failed queued task record. Depending on the reason for the failure, the QTI either sets the queued task entry to a retry state, removes the queued task record from the queue file and moves it onto an error queue, or simply deletes the queued task record from the queued file. For more information about the QTI, refer to Compaq ACMS for OpenVMS Writing Applications.

Figure 1-12 Coordinating Task Queues with Database Updates

An interactive transaction contains exchange steps within the bounds of the transaction.

Both the Rdb and DBMS database products support only a single active recovery unit in any one server process at a time. Therefore, once a server starts a database transaction, either as an independent transaction or as part of a distributed transaction, the server processes involved in the transaction must remain allocated to the task until the end of the transaction.

When a task retains context in a server during an exchange step, the server process remains idle during that time and cannot be allocated to another task. In order to avoid the following performance and database contention issues, tasks do not usually include exchange steps within the bounds of a database transaction or a distributed transaction:

• Retaining context during an exchange step.
  While a task is retaining context in a server during an exchange step, the server process cannot be allocated to another task. The result is that other task instances that are waiting to use the server may have to wait a long time before they can continue executing. If ACMS increases the number of server processes to resolve the delay, the degree of contention for resources in the database increases because additional processes are now competing for those resources.
• Locking resources in the database.
  As a transaction executes, the resource managers acquire locks on resources in the database to maintain the consistency and integrity of the data there. Other server processes that need to access the same resources may have to wait a long time to acquire locks on those resources before they can continue executing.

In a task that contains processing steps that begin and end independent database transactions, the default is to release context in the server after each step, freeing the server process for use by another task instance. In a task that uses distributed transactions, you cannot release context in the servers participating in the transaction until the end of the transaction. However, at the end of the transaction, the task must release context in the server processes participating in the transaction.

Despite the performance issues, your application might need to make use of interactive transactions in certain situations, such as the need to lock a record while the user is updating its contents. If so, and you are using independent database transactions, you can retain context in a server at the end of a processing step and over a subsequent exchange step. If you are using distributed transactions, you can include an exchange step within the bounds of a distributed transaction.

1.7 Recovery

ACMS uses the term database transaction to describe the part of a transaction that insures that database operations can be recovered. The term recovery unit has the same meaning for RMS files. The transaction does not permanently change a database or file until the successful completion of all operations in the database transaction or recovery unit, respectively. Then all changes are made at once.

In a nondistributed transaction, a procedure calls Rdb, DBMS, or RMS directly to both begin and end a database transaction or recovery unit.

In distributed transactions, however, DECdtm services control recovery for the transaction. The beginning and the end of the distributed transaction boundary are specified in the task definition.

ACMS provides an exception handling capability for the ACMS task definition language that a task can use to recover from transaction failures. This capability, called exception handling, identifies action statements to be executed as the result of an exception. The exception handler part of a step controls task execution following an exception in the work or action portion of the current step.

ACMS distributed transactions are subject to possible DECdtm failures such as resource manager process failure (either before the end-of-transaction or after it, when participants in the transaction are preparing to commit), coordinator node failure, or network failure. DECdtm services provide a planned recovery action for all such failures. The four rules that govern DECdtm recovery are as follows:

Before the end-of-transaction is issued:

1. If any failure occurs before the application initiates end-of-transaction, the transaction rolls back.

After the end-of-transaction is issued:

2. If any participant in the distributed transaction does not vote YES (that is, votes NO or aborts), the transaction rolls back.
3. Once a participant votes YES, it cannot complete the transaction independently; any prepared participant must await the coordinator's decision.
4. Once the coordinator logs the commit record, the transaction commits.

The ACMS run-time system has eight specialized processes, discussed in Compaq ACMS for OpenVMS Getting Started. Of these eight, however, three processes determine the performance, availability, reliability, and usability of the system:

• Command Process (CP)
• Application Execution Controller process (EXC)
• Procedure server process (SP)

The CP, EXC, and SP processes are also the processes that are most affected by design decisions. Application-specific definitions and programs run in these three processes.

Figure 1-13 provides an overview of these processes and their uses. The following sections discuss the three processes and the design issues related to each.

Figure 1-13 Three Processes of the Run-Time System

The Command Process handles the user interface for an ACMS application. Except for those applications that use a user-written or custom ACMS agent, or that use ACMS queuing, the Command Process is responsible for:

• Signing in the user to ACMS and, for controlled terminals, verifying that the user is an authorized OpenVMS user.
• Displaying menus, command prompts, and help text for users as they determine what tasks are available for them to select
• Handling the initiation of tasks once the user has selected a task, including both remote and local tasks
• Handling forms interaction during the execution of the task, including task-specific help as well as input and output dialog
• Handling a user's exit from the ACMS system

Understanding the behavior of the Command Process can help ensure that your user interface design takes advantage of ACMS to meet the design's primary goal. The goal of user interface design is to enable the user to work as effectively as possible: minimize learning time and maximize the work that the system does for the user.

The ACMS implementation of the Command Process might affect your design in two areas:

• Support of front-end distibution (off-loading forms processing).
  In front-end distribution, the Command Process is responsible for initiating tasks on a remote application node. The presentation service in the Command Process then handles the packaging and unpackaging of data for exchange steps that is sent over the network to and from the remote node. In a distributed environment, workspace size is an important consideration because the workspace is passed across the network.
• Support for multiple Command Processes per system.
  ACMS allows you to have multiple Command Processes active at one time on a given system, so that the resources allocated to the user interface activity can be tailored according to the number of users and the complexity of the work. ACMS allows you to define how many terminals are handled by each Command Process.
  You can allocate the Command Processes statically at the time the ACMS system is started, or you can allow dynamic creation and deletion of Command Processes as the load varies. Each additional Command Process requires additional memory resources, and may affect CPU resources through paging if sufficient memory is not available.

The Application Execution Controller handles flow control for the application. There is only one Application Execution Controller for each ACMS application, that is, for each run-time application database file. All tasks in the application are handled by the Application Execution Controller unique to that application. Therefore, processing design decisions can have a significant affect on the behavior of the Application Execution Controller.

The Application Execution Controller:

• Interprets the task definition, represented in binary form in the task group database file, to determine what calls to make to a presentation service for form display or to procedure servers for database activities
• Interprets the control statements in the task definition to make these decisions (if-then-else, while-do, and so forth)
• Allocates workspaces for task, group, and user workspaces, and manages these workspaces
• Handles the creation and deletion of server processes, to the extent that a given application uses dynamic rather than static allocation of servers

Understanding the implementation of the Application Execution Controller can help yo make decisions relevant to processing design.

1.8.3 Procedure Server Process (SP)

The procedure server process handles computation and database activity for the application. One or more processes can represent each procedure server definition. You can statically or dynamically assign the number of physical processes corresponding to a server definition.

These processes contain customer-written code. Data design or processing design decisions that affect the implementation of this code have a dramatic affect on the application's performance. Therefore, understanding server implementation can help you make good data design and processing design decisions.

The procedure server process is a single-threaded process, allocated to one task for the duration of one or more processing steps. The length of time that the server is allocated to a task, therefore, has a direct effect on the number of server processes needed in the application. The procedure server process is the only ACMS process that interacts with data files or databases. The length of time that a server is allocated to a task, therefore, can also have a direct effect on the amount of data contention in the application.

Once released by a task, the procedure server process can be assigned for use by another task. Consequently, there is no guarantee that a task will return to the same procedure server process for subsequent processing steps. The application code cannot assume that the server procedure's context will be the same once the task releases the server and subsequently attaches to a server again.