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:

• Defining processing steps that do similar work in one step. See Section 6.2.1.
• Controlling task flow through step sequencing, conditional processing, and task calling. See Section 6.2.
• Using a reusable procedure server for step procedures, and releasing server context. See Section 6.3.
• Defining and using workspaces. See Section 6.4.
• Processing with task queuing. See Section 6.5.
• Using distributed transactions within an application. See Section 6.6 and Chapter 4.
• Using ACMS exception handling. ACMS lets you handle and recover from errors that interrupt the execution of a task. See Section 6.7.

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:

• Some activities, such as extensive data analysis, are better implemented as batch command procedures than as interactive multiple-step tasks. The procedure can be submitted to the batch queue from a single-step task running in a DCL server from the menu.
  Similarly, you can write a single-step task that is invoked as a queued task.
• An existing application written in a high-level programming language can be used with ACMS. Include the existing application in a single-step task by using either:
  • The IMAGE IS clause, either in a processing step of a task definition or as a processing subclause in the task group definition. The existing application requires no modification.
  • The CALL clause, either in the processing step of the task definition or as a processing subclause in the task group definition. Use of this clause requires some modification to the existing application code.
  
  However, if terminal I/O is performed by the image, you cannot invoke the task remotely.

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:

• Step sequencing
• Nested blocks and conditional processing
• Task-call-task facility

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:

• Test values of workspace fields to control task flow from block steps, processing steps, or exchange steps
• Test status values returned from procedures to control task flow
• Test values input by terminal users to control task flow
• Use nested blocks to modularize tasks, performing the work in the nested block only if a condition is met

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:

• Allowing the user to call a task
• Customizing menus
• Enhancing security checking
• Creating a library of common tasks

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:

• Handle, at the starting and stopping of the server process, overhead work such as opening and closing files in initialization, termination, and cancel procedures for all the step procedures running in the procedure server.
• Use workspaces that pass information between steps, requests, procedures, and task instances. The only data available to a DCL server is the contents of the ACMS$SELECTION_STRING system workspace, formatted into parameter symbols P1 to P8.
• Allow for distributed forms processing if terminal I/O is handled by exchange steps.
• Can balance processing throughout multiple procedure servers to allow a more granular level of process tuning.

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:

• Design of the step procedures controlled by each procedure server
• Grouping of step procedures into procedure servers
• Number of server processes allowed for each procedure server (specified in the application definition)

When you design step procedures, consider:

• Minimizing the time within the code
• Trapping all recoverable error conditions and return known values to the task
• Making effective use of initialization, cancel, and termination procedures
• Using event or error logging

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:

• Database transaction type
  Separate read-only and read-write transactions into different procedures servers. When you commit a read-write transaction, Rdb prestarts a new read-write transaction, even if the read-write transactions only read the database.
• Database resources
  If you link all the procedures that use a particular resource into the same procedure server, you have better control over database contention. Each procedure server must maintain information about each resource to which it has access.
• Transaction length
  Do not force short transactions to wait for long transactions. One solution is to keep short transactions in one procedure server so that they can complete quickly. However, if a short transaction must wait for a long transaction to finish, you will have less lock contention if they both execute serially in the same procedure server.
• Processing and security requirements
  Different step procedures can have vastly different requirements for memory and other system resources. If necessary, consider creating procedure servers based on the characteristics assigned to the server user name: the privileges, quotas, and resources required by the step procedures using that server.
• Operation type
  For update transactions, mix insert, modify, and delete transactions in the same procedure server. If you isolate delete transactions in their own servers, you cannot reuse space freed by the deleted records.
• OpenVMS accounting requirements
  You may need to track OpenVMS accounting statistics for work done in various procedure servers.

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:

• Keep the number of server processes to a minimum. Use reusable server processes, and as few as possible to accomplish your application's work. Database contention may result as the number of server processes with access to the database increases.
• Make available enough server processes so that tasks do not have to wait an unreasonable length of time for a procedure server.

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:

• Record locks
• File pointers or currency indicators
• Other process characteristics

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.