Compaq ACMS for OpenVMS
Concepts and Design Guidelines


Previous Contents Index

Figure 6-10 Remote Update Using Rdb Remote Server


6.6.3 Distributed Transactions in the AVERTZ Application

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.

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

6.7 Handling Exceptions

ACMS raises an exception if it detects an error condition while a task is executing. You can use the exception handler component of the task definition language to control task execution after an exception is raised in a task. Use of exception handlers in tasks is optional. If you do not specify an action to take when an exception is raised, ACMS cancels the task. You use exception handler action clauses to direct the flow of the task after an exception is raised. For example, you can use an exception handler to retry a distributed transaction that times out.

The three types of exceptions are:

See Compaq ACMS for OpenVMS Writing Applications for details about implementing exception handling.


Chapter 7
Designing Server Procedures

This chapter provides guidelines for mapping your defined transactions to step procedure implementations. It helps you decide when and where a step procedure performs the desired operations, such as database recovery and validation.

7.1 Writing Server Procedures

Procedures for ACMS tasks that use RMS files, Rdb, and DBMS databases are similar in the following ways:

Compaq ACMS for OpenVMS Writing Server Procedures describes these programming considerations in detail.

7.2 Returning Status to the Task Definition

In most situations, a task needs to know whether or not the work done in a processing step is successful so that it can determine what to do next. The step procedure must pass a value back to the task. The value can be tested in the task, and the task can take an action based on the result of the test. A procedure returns a value to a task definition in one of the following ways:

User-defined workspaces are more flexible than the return status facility, but require additional memory. The return status facility uses the predefined ACMS$PROCESSING_STATUS workspace, but offers a limited set of values to pass.

The chapter on writing step procedures in Compaq ACMS for OpenVMS Writing Server Procedures describes ACMS$PROCESSING_STATUS in detail. ACMS$PROCESSING_STATUS is also used to return messages based on the result of a returned status.( See Section 7.3.)

7.3 Returning Messages to Users

You can return messages in several ways:

Compaq ACMS for OpenVMS Writing Server Procedures describes the details of step procedure coding used to process messages by any of these methods. Compaq ACMS for OpenVMS Writing Applications describes the task syntax needed for processing messages.

7.4 Handling Errors

You typically write an error handler to process errors returned by a resource manager, such as Rdb, DBMS, or RMS, when starting and ending a database transaction or recovery unit, and when accessing data in a database or a file.

Some errors are expected, and are handled by resuming normal program execution. For example, a resource manager might return an error if a record does not exist in a file or a database. In this case, the procedure can return an error status to the task. In the action part of the processing step, the task retrieves the error message text associated with the error status and then transfers control to an exchange step to display the error message for the user. Alternatively, if the error condition is handled by an exception handler on the processing step or on an outer block step, the procedure can raise a step exception by calling the ACMS$RAISE_STEP_EXCEPTION service. The action clauses in the exception handler can then process the exception condition and resume execution elsewhere in the task.

Resource managers can also return a number of recoverable errors that a procedure should check for and handle. For example, resource managers return deadlock errors if the OpenVMS lock manager detects a deadlock condition between two or more processes. If the database transaction or recovery unit is participating in a distributed transaction, the procedure can raise a transaction exception by calling the ACMS$RAISE_TRANS_EXCEPTION service. After ACMS aborts the distributed transaction, an exception handler in the the task can automatically retry the transaction. Alternatively, if the database transaction or recovery unit is not participating in a distributed transaction, the error handler can roll back and retry the database transaction or recovery unit within the procedure.

Finally, resource managers can return a number of nonrecoverable errors. For example, suppose the failure of a disk on which a file or database storage area resides. The procedure server cannot continue until resolution of the problem. If a non-recoverable error is detected, a procedure can log the error in the ACMS audit log by signaling the error condition, and then cancel the task by raising a non-recoverable exception using the ACMS$RAISE_NONREC_EXCEPTION service.

Compaq ACMS for OpenVMS Writing Server Procedures describes the details of handling errors and raising exceptions in step procedures.

7.4.1 Avoiding Cancel Procedures

Avoid cancel procedures as much as possible. Traditionally, cancel procedures have been used to clean up procedure execution, to free nontransaction-based resources, and to rollback an active database transaction or recovery unit. Whenever possible, however, you should try to avoid designing and writing step procedures that require server cancel procedures to clean up server processes following an exception. Reasons for avoiding cancel procedures are:

Use the following guidelines to design and write tasks and step procedures that avoid cancel procedures:

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

7.5 Performance Considerations

Use precompiled data manipulation language or SQL module language in step procedures for database access, if the language you are using supports them.

Using the DBQ$INTERPRET and RDB$INTERPRET services is discouraged, because these services must interpret and compile the DML statements at run time. This can be costly in CPU usage and response time.

If you need to update a local database and a remote database in a distributed transaction, you can increase performance by using the ACMS SI services to call a task to update the remote database. Writing the step procedure using the following guidelines allows you to update both databases simultaneously:

  1. Call the ACMS$START_CALL service to start the remote task.
  2. Update the local database while the remote task is updating the remote database.
  3. Call the ACMS$WAIT_FOR_CALL_END service to wait for the remote task to complete.

7.6 Performing Terminal I/O from a Procedure Server

One of the major advantages of implementing an application with ACMS is that you can easily separate your terminal I/O from your database I/O. You do this by performing terminal I/O in exchange steps and database I/O in processing steps. This design offers better performance and the ability to distribute tasks over multiple nodes.

However, sometimes terminal I/O is unavoidable in a processing step---for example, if you are incorporating an existing program into an application. In such cases, it may be simpler to make the existing program a single-step task that does terminal I/O than to convert the program to a multiple-step task, which requires removing the terminal I/O from the program and placing it in exchange steps. Compaq ACMS for OpenVMS Writing Server Procedures gives details about how to handle terminal I/O from a processing step.


Chapter 8
Designing User Interfaces

This chapter provides guidelines for designing DECforms menus and forms. It also describes issues in the design of nonstandard ACMS user interfaces, such as customer-written interfaces created using the ACMS Systems Interface (SI) or Request Interface (RI).

8.1 Designing a User Interface

A good user interface is one that is consistent and easy to use. When choosing and designing a user interface:

8.2 Choosing a User Interface for ACMS

ACMS provides great flexibility in collecting user input for processing in an application. You can use any combination of the following tools to capture data for use in an ACMS application:

Compaq recommends the use of DECforms. ACMS support of DECforms is asynchronous, allowing for the most efficient use of resources. (See Section 8.3.1.) Figure 8-1 illustrates the use of various interfaces to ACMS.

Figure 8-1 Interfaces to ACMS


Submitter services select tasks and optionally send and receive data at the beginning and end of the task. Tasks interface with presentation services using the following exchange types:

DECforms and TDMS limit you to collecting user input from DECforms-supported and TDMS-supported terminals. Compaq TP Desktop Connector (formerly ACMS Desktop) supports tasks written to use forms I/O or request I/O from desktop systems running their native operating systems. Request I/O and the RI provide the flexibility of choosing an interface from other I/O devices to ACMS without affecting the multiple-step task structure or the ease-of-maintenance features inherent in an ACMS application.

You can also perform terminal I/O from step procedures running in the processing steps of your task. However, because this method ties up a server process, it can result in loss of performance, and might require the Application Execution Controller (EXC) to start additional server processes. Also, you cannot use remote tasks if you include terminal I/O in a step procedure. See Chapter 7 for more information about I/O from step procedures.

8.3 Using DECforms

DECforms helps separate form from function. The form in which data is gathered and displayed to the user is completely separate from the function that the application must perform in processing the data.

8.3.1 DECforms Structure and Design

With DECforms, a form describes not only the fields and background text displayed on the screen, but also provides such features as:

A DECforms form consists of the following:

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

The main design issues for DECforms are:

See the DECforms documentation for detailed descriptions of these topics.


Previous Next Contents Index