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, ''Restoring a Database After a Failure'' 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.

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:

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

A transaction processing system comprises components that fit together to manage and control complex applications. Figure 1.2, ''Logical View of a TP System'' shows a 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:

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 and use more powerful computers 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.

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, ''Application Development Life Cycle'' 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.

The following actions constitute an application development life cycle:

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.

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:

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, ''ACMS Application Components'' 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'' 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.

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:

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, VSI DECforms forms, and procedure servers.

The application definition describes:

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.

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.

The VSI 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 VSI 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, ''Panels and Viewports'' illustrates the concept of specifying panel declarations and viewport declarations within the VSI 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.

The VSI 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 VSI DECforms form is loaded by the Form Manager at execution time under the direction of an ACMS task.

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

In VSI 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, ''VSI DECforms Interaction with ACMS'' shows the interaction between VSI DECforms and ACMS when ACMS requests information from VSI DECforms.

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

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, ''Off-Loading Forms Processing to a Submitter Node'' illustrates this configuration.

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.

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, ''The Relational Database Model''). 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.

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:

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.

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, ''A Resource Manager Interacting with ACMS'', 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, ''A Resource Manager Interacting with ACMS'' 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.

The update task executes the following series of steps:

For a full picture of the ACMS execution flow that includes the Form Manager’s role in exchange steps, refer to Figure 1.4, ''Execution Flow of an ACMS Task Definition''.

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.

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:

In Figure 1.11, ''Coordinating Multiple Resource Managers'', 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.

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 VSI 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, ''Coordinating Task Queues with Database Updates'' illustrates two distributed transactions:

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 VSI ACMS for OpenVMS Writing Applications.

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:

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:

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:

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

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.

Most businesses are divided into areas, departments, or functions. The requirements for a TP system are the sum total of the requirements for each business area. Each business area collects and maintains data on its own and shares some of this data with other areas of the business. Derive an application requirements list by studying current business practices and questioning department managers and prospective users of the system.

Note that the AVERTZ sample application handles only the reservation processing business area of the AVERTZ company.

This section describes the business functions that comprise the reservation processing area of the AVERTZ business.

Each business function consists of a set of business activities. These activities are the logical transactions that the application system must perform and that the database must support. To determine database and application requirements, first develop a description of each discrete business function. Then list activities that users perform to carry out each business function.

You determine the number and type of resource managers and their expected interaction from the information supplied about the business functions in the Requirements Specification. With that information, you can design the needed transactions.

At this point, the initial database design should have been completed. You now know whether the information accessed by each business function is stored in one or multiple databases or files. As you map the flow of data for each business function from submitter to resource manager, you determine when to use distributed and nondistributed transactions.

Integral to this process is the determination of whether or not you need distributed transactions. Generally, nondistributed transactions are preferable because distributed transactions are more difficult to design and to control, and because they use more resources. However, in some cases distributed transactions are unavoidable. In other cases, they have advantages which outweigh a similar nondistributed transaction.

The following figures illustrate a range of business organizations, from single-site, single-database businesses to multiple-site, multiple-database organizations. The implications of each type of organization are outlined, particularly from the point of view of distributed and nondistributed transactions.

Figure 4.1, ''A Single-Site Business with a Single Database'' illustrates a single-site business with a single database.

This business probably does not use distributed transactions. For example, a retail shop with a single database for inventory uses nondistributed transactions. However, the existence of a single database does not preclude the possibility of a distributed transaction. For example, the use of a queued task with access to a single database requires that the transaction be distributed.

Figure 4.2, ''A Single-Site Business with Multiple Databases'' illustrates a single-site business with multiple databases.

A single factory, for example, uses a vertically partitioned database for functional partitioning of the data: parts, customers, and employees. This business may or may not require distributed transactions. Most update transactions probably affect only a single database. However, if some update transactions involve more than one database, those transactions are distributed transactions.

Figure 4.3, ''A Multiple-Site Business with Multiple Central Databases'' shows a business with multiple sites and multiple databases.

Your TP system can include elements both of remote access and of task calling to the central application.

The AVERTZ company uses this model. Section 6.6.2, ''Choosing an Access Method to Remote Data'' describes design issues for remote data access.

A similar business organization can use distributed forms processing for an entirely different TP system. Distributed forms processing places front-end forms at the car rental sites and back-end processing at the central databases. Branch sites do not have applications that communicate by direct remote access to databases or by indirect access through task calling to a central application. See Section 4.3, ''Using Distributed Forms Processing'' for guidelines on distributed forms processing.

A configuration with central databases is easier to maintain and control than one with local databases, but if the central system fails, no application work can be done. However, you can maintain high availability with a VMScluster at the central site. Allow for higher application availability by creating a configuration in which if one central system fails, you can failover to an alternate system.

Note that a similar configuration might include a single central database, rather than multiple databases. While multiple databases indicate the likelihood of the need for distributed transactions, keep in mind that a single database can require distributed transactions if task queuing is used.

Figure 4.4, ''A Multiple-Site Business with Multiple-Site Databases'' describes a system with multiple databases at multiple sites.

This model contains the same elements as the multiple-site, central databases model, but adds local databases at branch sites. An example is a bank that maintains local databases for the accounts of regular branch patrons, but also maintains one or more central databases.

Such a system improves performance and allows local application availability to continue if the link goes down, but is more difficult to manage and control than a system with a database or databases in a central location. This configuration is likely to have a relatively high need for distributed transactions. This configuration might also make extensive use of distributed transactions for initiating queued tasks, particularly for ensuring the integrity of distributed transactions if links fail.

These examples do not exhaust the possible combinations of business sites and resource managers. To design the most successful application, take into account the organization of your business and the type and configuration of your resource managers. Consider not only the current organization, but also likely growth scenarios. You can then maximize your design to take best advantage of that configuration.

Using a distributed transaction to update these two databases ensures that if the first database transaction succeeds and the second database transaction fails, the first is rolled back.

In such a scenario, the use of multiple databases mandates a distributed transaction. Figure 4.5, ''Determining Data Flow for Business Functions'' depicts the data flow for this distributed transaction.

You may identify transactions that do not need to be processed immediately, or that are better left for later processing. In this case, even if your application requires only a single database you may need to design one or more distributed transactions. You do this by designating a distributed transaction that includes both the database and the task queue as resource managers (if you need to coordinate the enqueue or the dequeue of the queued task with modifications to the database).

See Chapter 6, "Designing ACMS Tasks" for details about designing distributed transactions that include queuing.

Chapter 6, "Designing ACMS Tasks" also describes the use of queuing for distributed forms processing in applications which use a front-end node for data entry and then queue tasks for processing by a back-end node. When both nodes are available, the back-end node processes queued tasks at regular intervals. If the back-end node goes down, the front-end node continues to queue tasks, providing users with uninterrupted access to the application for entering data on the front-end node. The tasks remain queued until the back-end node becomes available for processing.

Using the DECdtm transaction services and an ACMS queue file marked for recovery unit journaling, ACMS guarantees that changes made to a database by a queued task are committed only once.

In TP systems, locking is a necessary control technique for regulating concurrent access to shared data in a database. Because multiple users concurrently access a shared database in a TP system, locking issues are of great importance when designing TP applications. The goal is to design the smallest possible transactions (the smallest atomic units of work) to allow quick release of servers and maximum access to records.

You must often segment a business function into multiple transactions to minimize lock contention. While User A updates Record A, the record is locked. User B must wait for User A's transaction to finish before updating Record A.

Figure 4.6, ''Record Locking'' illustrates locking from the point of view of two users needing access to the same record in a database.

Retaining server context can adversely affect performance both by withdrawing the server from use by other task steps, and by handling a transaction that holds locks on databases across steps, thereby blocking other users from the records that are locked.

Keeping in mind the issues of lock contention and of distributed and nondistributed transactions, this section offers guidelines for identifying the transactions related to each business function.

Information supplied to the application is a key factor in task design. Users often supply the initial information. Or, initial information comes from a combination of users and databases.

When you design a task, consider the sequence in which information is gathered. For example, when a customer checks in a car, the AVERTZ clerk must associate that customer to a car, and to information about that car that is stored in a database. The clerk must collect this information before calculating the bill.

So, an ACMS task often starts with an exchange step that asks the user for information–either new information, or a key field for access to information previously stored in a database. For example, all three of the AVERTZ business functions represented on the main menu (RESERVE, CHECKOUT, and CHECKIN) begin by invoking the single DECforms form to gather basic customer information. See Section 5.3, ''ACMS Tasks for the AVERTZ Application'' for an outline of all components in the AVERTZ application.

Moreover, key identifying information is often required in several locations in an application. Modular design allows you to isolate a common sequence of operations into a task that can be called as needed by other tasks. In the AVERTZ application the CHECKOUT and CHECKIN menu choices invoke the Checkout and Checkin tasks, respectively. Both choices invoke the form to gather identical information (customer name or reservation ID). Therefore, both the Checkout and Checkin tasks immediately call the get reservation task to identify the customer's reservation. Once the reservation has been identified, control returns to the Checkout or Checkin task to handle the operations specific to checking out or checking in a car.

Similarly, you can use your business functions to identify other exchange steps and order them sequentially within the outline of a task. If you plan to create called tasks for repeated sequences of operations, you can begin planning the exchange steps to be isolated in the called tasks.

Just as the order of the business activities described in Chapter 3, "Creating a Requirements Specification" affects the sequence of exchange steps in the task, the nature and order of the transactions described in Chapter 4, "Creating a Functional Specification" affects the processing steps.

Transactions result, directly or indirectly, from information gathered in exchange steps. When you order your transactions to reflect the business activities which they carry out, take into account the characteristics of transactions. For example, do not include an exchange step within a distributed transaction. Even if your analysis indicates that an exchange step fits logically within the transaction, the cost of maintaining locks in the database s while awaiting a user response is likely to be prohibitive.

You often need the information derived from an exchange or processing step to decide the next operation. This often entails the use of REPEAT STEP, GOTO, GOTO STEP <step-label> syntax, nested blocks, or conditional logic. As you outline your tasks, consider the information flow.

Note where work flow leads to an exchange or processing step that can cause ambiguity for the user. For example, in the AVERTZ reservation task the user can specify the exact rental site by entering the site ID. A user who does not know the site ID can alternately enter a city name. If there is more than one rental site in the city, a list appears with all the site IDs for that city. The user can then choose a site. The reservation tasks handles this anticipated problem with conditional logic and GOTO PREVIOUS EXCHANGE syntax. If the user knows the site ID, the task flows directly to displaying customer information. If not, the task gets the possible site IDs and loops back.

You sometimes have the choice of placing the work of the application at the task level or at the step-procedure level. For example, you can use task syntax or procedure code to handle conditional logic. Conditional logic is best placed in the task definition, if the resolution of the conditional logic avoids calling a step procedure. More complex conditional logic related, for example, to the results of computations, is better placed in procedures.

A customer can make a reservation in advance, or can take a car immediately upon reserving it. The process of checking out a car is common to either of these situations. Therefore both the Reservation task and the Checkout task call a common task, the Complete Checkout task. See Section 5.3.5, ''The Complete Checkout Task''. Figure 5.4, ''The Structure of the VR_RESERVE TASK'' shows the flow of the VR_RESERVE_TASK.

The Checkout task in the AVERTZ application, named VR_CHECKOUT_TASK, is used when a customer who has previously made a reservation arrives to take a car. Recall that the customer can also check out a car immediately upon making a reservation. Checking out a car at reservation time does not use VR_CHECKOUT_TASK. So, the checkout business function is initiated either by the VR_RESERVE_TASK or the VR_CHECKOUT_TASK. In either case, it is completed by the VR_COMPLETE_CHECKOUT_TASK. See Section 5.3.5, ''The Complete Checkout Task''.

Figure 5.5, ''The Structure of the VR_CHECKOUT_TASK'' shows the flow of the VR_CHECKOUT_TASK.

Figure 5.6, ''The Structure of the VR_CHECKIN_TASK'' shows the flow of the VR_CHECKIN_TASK.

VR_GETRESV_TASK operates only in the context of the Checkout or Checkin tasks. Once its work is completed, control returns to whichever of those tasks called it.

Figure 5.7, ''The Structure of the VR_GETRESEV_TASK'' shows the flow of the VR_GETRESV_TASK.

The Complete Checkout task in the AVERTZ application is named VR_COMPLETE_CHECKOUT_TASK. This task is used both in the reserve car and checkout business functions. VR_COMPLETE_CHECKOUT_TASK completes or cancels the reservation, based on the choice made by the user after choosing a car (either in the reservation task or the Checkout task).

To do this, the task the procedures listed in Table 5.2, ''Step Procedures Used in AVERTZ Application'' to complete the checkout of the car.

VR_COMPLETE_CHECKOUT_TASK operates only in the context of the Checkout or Reservation tasks. Once its work is completed, control returns to whichever of those tasks called it.

Figure 5.8, ''The Structure of the VR_COMPLETE_CHECKOUT_TASK'' shows the flow of the VR_COMPLETE_CHECKOUT_TASK.

Within a multiple-step task, step sequencing is important for dividing the task into exchange and processing steps. Multiple-step tasks also allow you to use conditional statements to write structured, modular task definitions. You can create a complex task by using many exchange and processing steps. Or, create a series of less complex tasks and use the task-call-task feature to connect the tasks. Task calling improves clarity and maintainability, and provides for sharing of called tasks as subroutines.

Typically, a task definition consists of an alternating flow of exchange and processing steps, matching the business functions being handled by the task. This sequence is likely to take best advantage of the ACMS run-time system: exchange steps handle terminal I/O, while processing steps handle computation and database I/O.

However, there is some overhead associated with going into either an exchange step or a processing step. The number of step invocations at run time affects your run-time performance. Therefore, minimize the number of steps, to the extent that you do not compromise maintainability or server process performance. If your task has consecutive steps of the same type, consider combining them into a single step.

You also control step sequencing with syntax that redirects the task flow from the literal order of steps within the task definition: for example, REPEAT STEP, GOTO, or GOTO STEP<step-label>. Redirection of task flow often results from conditional action (described in Section 6.2.2, ''Conditional Processing'').

For example, the AVERTZ reservation task contains an initial exchange step that allows the user to choose a rental site by entering a site ID or a city. If the user enters a city and the city contains more than one site, the user can choose from a list of sites for that city. Once the user identifies a single site by any of these three means, the user enters customer and reservation information. All this activity takes place in a single exchange step rather than in a series of exchange steps. Conditional logic handles the identification of a single site, and the REPEAT STEP clause takes the user back to the point at which customer and reservation information is gathered if a single site was not immediately identified.

Do conditional logic in the task definition rather than in the step procedure if this avoids the need to invoke a processing step. By moving conditional and flow control logic out of the server procedure and into the task definition, you reduce the amount of time the task needs to go to the procedure server, freeing the server for other tasks to use. For example, if a customer has not updated any customer information, have the task skip over the processing step which performs a database update.

However, a procedure handles complex low-level business logic more efficiently than the task syntax does. See Section 6.3.2, ''Retaining and Releasing Server Context''.

Nested blocks enhance the modularity of task definitions. By using a nested block step, you can group processing and exchange steps into a block which is used only under particular conditions. ACMS processes the block only if a certain condition is met.

See VSI ACMS for OpenVMS Writing Applications for a description of a nested block.

In processing steps, you can call another task in the same task group, instead of calling a procedure in a procedure server. This is the task-call-task feature. A called task is similar to a subroutine in a 3GL program, based on the call and return model. Execution of the calling task continues when the called task completes. With task-call-task, control passes to the task you call (along with whatever workspaces you name as parameters), and then returns to the place from which you made the call.

Calling from one task to another is useful for applications that need to implement sophisticated task-to-task flow control mechanisms.

Task-call-task is particularly useful for providing modular code. The called tasks in the AVERTZ application illustrate this use of task-call-task. The Reservation task and the Checkout task both call the Complete Checkout task to handle identical processing related to checking out a car or canceling the reservation. Similarly, the Checkout task and Checkin task both call the Get Reservation task to gather information on the customer that is needed either at checkout or checkin of a car.

The following sections explain the use of task calling for these purposes.

Much of the benefit of ACMS multiple-step tasks comes from releasing the server process when a processing step has completed. If a user is filling in information on a form or reading information from a form, the task does not need a server process. A multiple-step task needs a server process only at the time of computation or interaction with files or databases.

While releasing server context complicates the design of tasks, retaining server context tends to degrade overall performance, in some cases severely. Figure 6.2, ''Effects of Retaining and Releasing Server Context'' shows the difference between retaining and releasing server context when a task includes more than one processing step or repeats the same processing step.

In a multiple-step task, a server process is allocated when the first processing step begins. If the task releases context, the server process is released when the task completes the processing step.

Releasing server context between processing steps means that a server process otherwise tied to the task is released to handle other tasks. Because processing time is typically much shorter than the time required for terminal I/O, a server process can handle many processing steps during the time required for a single exchange step. Releasing server context allows the application to require fewer server processes. Fewer processes accessing the data minimizes data contention.

The first processing step of an update task could lock the records used by the task, so that one user cannot make changes to the records while another is trying to make changes. However, locks held by the step procedure in a processing step are part of the context associated with the server handling the work in that step. Therefore, designing your task to lock records between processing steps requires retaining server context.

Avoid retaining server context as much as possible, because of the negative effects on application performance. However, retaining server context is a useful way to design update tasks when the records in the database are not updated frequently. Also, requirements for server context are different in distributed transactions. See Section 6.6, ''Designing Distributed Transactions''.

If the application does update the records frequently (such as in a car rental application or in a parts inventory), design the update task to read a record in the first processing step, then reread for update in the second step, checking for changes.

This section offers guidelines about choosing where to do work that could be initiated either from a task or a step procedure. See Chapter 7, "Designing Server Procedures" and VSI ACMS for OpenVMS Writing Server Procedures for more information about step procedures.

In the execution of an application, workspaces pass from the Command Process for exchange steps to the server process for processing steps, and back throughout the execution of a task. Information for use by these processes is stored within workspaces.

Part of the cost of communication across the network lies in the size of these workspaces. Consider this network cost when you design workspaces. Workspaces have to be stored in global sections or made up into packets to be passed over the network in a distributed transaction. Consider the total size of all the workspaces you are passing to the form or processing step.

Note that passing one workspace of 500 bytes is less expensive than passing 5 workspaces of 100 bytes each, providing all 500 bytes are required. Avoid passing unnecessary data, however large or small the workspace you use. Passing a 2250-byte workspace that requires three network packets is not unduly costly if you intend to use most or all of the data in the workspace. Passing 250 bytes that require one network packet is wasteful if you do not need the data.

Note that no single workspace can be larger than 65,536 bytes. The total size of all workspaces (including system workspaces) cannot exceed 65,536 bytes for a task instance. This effectively limits the size of a single workspace to 65,536 bytes, minus the size of all ACMS system workspaces, because all system workspaces are always present (for example, the system workspace size is 519 bytes in ACMS Version 4.2).

The AVERTZ application declares all workspaces in the task group definition, and refers to them as needed in the task definition.

ACMS allows a called task to accept arguments in the form of task workspaces. User-written agents or tasks may pass workspaces to other tasks. You can specify READ, WRITE, or MODIFY access for each workspace you include in a TASK ARGUMENT clause. Use MODIFY for passing and returning data, READ for passing data, and WRITE for returning data.

Specifying READ access on task workspace arguments can provide performance benefits, since ACMS does not have to return the workspace to the parent task or agent when the called task completes.

In creating workspaces for task calls, bear in mind the trade-off between workspace size and the various access types. For large workspaces, it is more efficient to pass data using a READ workspace and return data using a WRITE workspace than it is to pass and return data in a single MODIFY workspace. Conversely, it is more efficient to pass a single MODIFY workspace containing a small amount of data than it is to pass several separate READ and WRITE workspaces. The default is MODIFY.

The called tasks in the AVERTZ application are the Get Reservation task and the Complete Checkout task. Both tasks receive data from a parent task in the VR_SENDCTRL_WKSP workspace. However, neither task needs to return any data to the parent task in this workspace. Therefore, the VR_SENDCTRL_WKSP workspace is defined in both tasks as a task argument workspace with READ access. Both tasks also receive data from a parent task in the VR_CONTROL_WKSP workspace. Also, both tasks return information to the parent task in this workspace. Therefore, the VR_CONTROL_WKSP workspace is defined in both tasks as a task argument workspace with MODIFY access.

The Get Reservation task returns information to the parent task in the VR_RESERVATIONS_WKSP workspace after reading reservation information from the database. The VR_RESERVATIONS_WKSP workspace is defined as a task argument workspace with WRITE access in the Get Reservation task, because the task does not receive any data from the parent task in this workspace. However, the Complete Checkout task also receives data from the parent task in the VR_RESERVATIONS_WKSP workspace, in addition to returning information to the parent task in this workspace. Therefore, the VR_RESERVATIONS_WKSP workspace is defined as a task argument with MODIFY access in the Complete Checkout task.

See VSI ACMS for OpenVMS Writing Applications for a complete description of workspaces.

The AVERTZ sample application maintains a history log database, in addition to the main database. Any customer or reservation information written to the main database must be written to the history log database as well, for auditing purposes. The AVERTZ application uses distributed transactions to ensure that both databases commit the same information.

VSI ACMS for OpenVMS Writing Applications details the writing of distributed transactions in an ACMS task.

VSI ACMS for OpenVMS Writing Server Procedures describes how to prevent the interruption of a procedure server while it is executing, and the conditions under which a procedure is run down.

You can declare only one form in each source file, but you can declare multiple layouts, panels, and viewports within a form.

See the VSI DECforms documentation on the VMS Software Documentation webpage at https://docs.vmssoftware.com for detailed descriptions of these topics.

The VSI DECforms Forms Manager is a run-time system that provides the interface between the terminal and an ACMS application. The Forms Manager controls the appearance of the display, user input, and data transfer between the form and ACMS. When data is being used in the form, it is placed in form data items. The Forms Manager maps the data items to corresponding ACMS workspace fields through a structure definition called the form record.

You control local TDMS run-time support by defining a logical name. For each ACMS application, you decide whether you want the EXC or the CPs to provide local TDMS run-time support. If you decide that the CPs should provide local support, define the system or group logical name ACMS$LOCAL_TDMS_IN_AGENT to equate to the characters T, t, Y, or y, or to an odd-numbered value.

The EXC process evaluates the logical name when the process is invoked. Therefore, you must define the logical name before starting the application.

The following sections illustrate both methods of defining the logical name for local TDMS run-time support. The DCL-command method defines the logical name systemwide; the ADU-clause method defines it for just one application.

 $ DEFINE/SYSTEM/EXEC ACMS$LOCAL_TDMS_IN_AGENT  Y
 

 $ DEFINE/SYSTEM/EXEC ACMS$LOCAL_TDMS_IN_AGENT  0
 

 APPLICATION LOGICAL IS "ACMS$LOCAL_TDMS_IN_AGENT" = "1";
  
 APPLICATION USERNAME IS ...;
 TASK GROUPS ARE
   .
   .
   .
 END TASK GROUPS;
 END DEFINITION;
 

 APPLICATION LOGICAL IS "ACMS$LOCAL_TDMS_IN_AGENT" = F;
 APPLICATION USERNAME IS ...;
 TASK GROUPS ARE
   .
   .
   .
 END TASK GROUPS;
 END DEFINITION;
  
 

VSI ACMS for OpenVMS Writing Applications describes the details of RI use.

Also, if you use the task-call-task facility, you must include both parent and called tasks in the same task group

Consider using multiple task groups during the development of an application, and then combining those groups when the application is put into production. Using multiple task groups during development has advantages such as decreased build time. Combining the task groups before the application is put into production allows you to realize the benefits of fewer, or a single task group.

Some OpenVMS and ACMS system parameters also require monitoring before they can be set optimally. Working set sizes for the Application Execution Controller (EXC) and server processes can be monitored after installation of your application and changed to meet your requirements. For information about tools with which to make these observations and change corresponding parameter values, see VSI ACMS for OpenVMS Managing Applications which includes sections on ACMS system monitoring, tuning, and setting the OpenVMS SYSGEN parameters that ACMS affects.