Compaq ACMS for OpenVMS
Concepts and Design Guidelines


Previous Contents Index


Chapter 6
Designing ACMS Tasks

Chapter 5 described the high-level design of tasks. This chapter provides guidelines for the detailed design of the tasks outlined for your application. Details of task design are part of the Programming Specification and include:

6.1 Choosing Single-Step or Multiple-Step Tasks

A task that runs a single image, command, or procedure (such as running the OpenVMS Mail Utility) is a special type of task called a single-step task. A task that consists of both exchange and processing steps, or multiple processing steps, is called a multiple-step task.

A single-step task usually consists of a single OpenVMS image running in a single processing step. The task uses one server process---similar to an OpenVMS interactive process---from start to finish, with all the attendant overhead. A multiple-step task uses specialized processes that allow multiple users to share a single process. The processing of a multiple-step task involves moving from one ACMS process to another. For example, control moves from the Application Execution Controller (EXC) process that directs the flow of a task into the Command Process (CP) or server process in which an exchange step or processing step runs.

When ACMS runs a multiple-step task, only the processing steps of that task require the use of a server process. Exchange steps are handled by another ACMS process capable of handling input/output for a number of users simultaneously. A server process does not need to remain allocated to a task during an exchange step. Other tasks can use the server process during an exchange step.

Design your application to minimize the processes required by ACMS. Specialize the work that a server process does. Arrange for quick processing of the work so that the server is released for use by other users. This can decrease the resources required for the application, especially for complex applications.

Multiple-step tasks usually offer the optimal use of the full range of ACMS functions and the best performance. However, single-step tasks running images or DCL commands can take advantage of some ACMS features, notably menu access and control of the application. Also, although you will usually want to use multiple-step tasks, single-step tasks have certain advantages:

You may want to consider converting such a single-step task to multiple steps. If the existing image is well structured, with terminal I/O and processing in modular paragraphs, the cost of conversion to a multiple-step task running in reusable procedure servers is repaid by the savings in resources.

The rest of this chapter describes design issues which, while not all confined to multiple-step tasks, are more likely to arise with multiple-step tasks.

6.2 Controlling Task Flow

You control flow in and among tasks through:

6.2.1 Step Sequencing

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

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.

6.2.2 Conditional Processing

Both the work part and the action part of a processing or exchange step can be conditional. Conditional task definitions allow you to:

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.

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 Compaq ACMS for OpenVMS Writing Applications for a description of a nested block.

6.2.3 Task-Call-Task Feature

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.

Task calling extends the capabilities of an ACMS task definition. Special uses of the task-call-task feature include:

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

6.2.3.1 Allowing the User to Call a Task

Some applications require that a user interrupt current work, perform some other related task, and then return to the original task. For example, the user doing an update task to change the database may need to run an inquiry task to check on the current status of the data.

Task-call-task provides an easy method for the application developer to implement this functionality. Create DECforms .IFDL code that returns literal text to an exchange step when the user presses a function key. The exchange step tests for the presence of the text string. If the text string is returned, the exchange step goes to a processing step that calls another task.

Exercise this option with care, however. To ensure that no information from the exchange step is lost, you must retain that information in a workspace, or ensure that the form data is not changed by the called task.

6.2.3.2 Customizing Menus

The menu interface supplied with ACMS uses DECforms. You may prefer to customize the ACMS menu by editing the DECforms .IFDL file, or to use another menu interface, such as TDMS. The appendixes in Compaq ACMS for OpenVMS Writing Applications describe customizing the display characteristics of ACMS menus.

However, if you want to pass data between a menu and a task, you must write your own menu. You can use a selection string to pass information from an ACMS menu to a task, but this method has limited functions: values are not returned from the task, and only text is passed.

Instead, you can use task calling for greater functionality from a menu. Create a menu entry that selects a task and use task-call-task in the menu task to select tasks in the rest of the application. The limitation of this method is that the menu task and all called tasks must be in the same task group.

To avoid the task-call-task limitation of a menu task, write an agent program. An agent program allows you to select a task in any ACMS application on any node, as you can with the ACMS-supplied menu. You can also use the same forms capability and the same ACMS processing capabilities. The agent can be single-threaded or multithreaded. However, a single-threaded agent requires one agent process for each user process.

6.2.3.3 Enhancing Security Checking

ACMS task security is based on task Access Control Lists. You can use task calling to enhance that feature, or use an entirely different task security mechanism.

For example, you can prevent nonprivileged users from seeing tasks they are not authorized to select. To do this, write a menu task that determines the user's rights list information and then displays only the names of those tasks that the user is allowed to select.

Or, you can implement an application-specific security mechanism. Write a menu task that prompts for a user name and password, validates these in an application-specific authorization file, and displays only those tasks that are authorized for that user. The task should be local, so that only a menu task can call it.

6.2.3.4 Creating Common Library Tasks

Some applications require similar processing to be performed at multiple points within a task group. Or, applications may require many tasks within a task group to perform the same set of processing or exchange steps. The task-call-task feature allows you to build up a "library" of common functions implemented as tasks. These common tasks can be called from multiple points within a task or from different tasks within a task group. Compaq ACMS for OpenVMS Writing Applications describes task syntax for the task-call-task feature.

6.3 Designing Procedure Servers for Step Procedures

A procedure server is a collection of step procedures which are called by processing steps. Each procedure server consists of one or more server processes, each executing the same server image. The ACMS application definition and task group definition define the procedure server. Server processes are the instances of each procedure server.

Figure 6-1 illustrates the structure of a procedure server.

Figure 6-1 Structure of a Procedure Server


In addition to differing in the number of steps they contain, tasks differ in the processing they require and, therefore, in the kinds of server processes they use. ACMS uses DCL servers to handle the work for images, DCL commands or procedures, and DATATRIEVE commands or procedures. Procedure servers handle the work of calls to subroutines in processing steps.

Both procedure servers and DCL servers can be reusable. A reusable DCL server can run many OpenVMS images, DCL commands or procedures, or DATATRIEVE commands or procedures without starting and stopping the process for each one. However, the,image is always activated at the start of the step and run down at the end of the step. Although both DCL and procedure servers are reusable, procedure servers have several advantages. Procedure servers:

Table 6-1 distinguishes between the uses of server types.

Table 6-1 Processing Requirements and Servers
Server Type Processes:
Procedure Server procedures
DCL Server images, DCL commands or procedures, DATATRIEVE commands or procedures

6.3.1 Designing Procedure Servers

When you design procedure servers, consider the following:

6.3.1.1 Designing Step Procedures

When you design step procedures, consider:

See Chapter 7 and Compaq ACMS for OpenVMS Writing Server Procedures for detailed design guides for writing step procedures.

6.3.1.2 Grouping Step Procedures in a Procedure Server

Group step procedures into procedure servers based on:

6.3.1.3 Setting the Number of Server Processes for a Procedure Server

The number of server processes to allow for a procedure server depends on the frequency of calls to the procedure server and the average length of time a procedure server is allocated to a task. When you design server procedures, you must balance these goals:

6.3.2 Retaining and Releasing Server Context

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.

In rare cases, you may still choose to retain the server process across an exchange step. Keeping this process allocated for more than one step saves the context associated with the server process. Retaining server context allows for the retention of:

While releasing server context complicates the design of tasks, retaining server context tends to degrade overall performance, in some cases severely. Figure 6-2 shows the difference between retaining and releasing server context when a task includes more than one processing step or repeats the same processing step.

Figure 6-2 Effects of Retaining and Releasing Server Context


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

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.


Previous Next Contents Index