Compaq ACMS for OpenVMS
Concepts and Design Guidelines


Previous Contents Index

6.3.3 Working in a Task or a Step Procedure

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 and Compaq ACMS for OpenVMS Writing Server Procedures for more information about step procedures.)

Use step procedures for:

Use tasks for:

Some types of work can be done either in the step procedure or the task depending on circumstances:

6.4 Designing and Using Workspaces

A workspace is a buffer used to pass data between the form and the task, and between the task and the processing steps. A workspace can also hold application parameters and status information. Workspaces are passed to step procedures and tasks as parameters. You must define the workspace structure and store in CDO or DMU format.

6.4.1 Workspace Size

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.

6.4.2 Workspace Structure

You can design your workspaces:

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

6.4.3 Using Task, Group, or User Workspaces

There are three types of workspaces:

Use task workspaces whenever possible. Task workspaces have the lowest CPU and memory costs. If you need group and user workspaces, use them for relatively static information. Table 6-2 summarizes the features of each type of workspace.

Table 6-2 Workspace Types
Characteristic Task Group User
Availability For the duration of the task instance For as long as the application is started (active) For the user's ACMS session within the application
Purpose Passes information between:
  • Steps in a task
  • Exchange steps and forms
  • Processing steps and procedure servers
  • Parent tasks and called tasks
Stores relatively static information required by many tasks in a group Stores user-specific information
CPU cost Copied once from the .TDB at task start, not copied back at taskcompletion. Copied from the permanent workspace pool to the temporary pool at task start. Copied back to the permanent workspace pool only if accessed for update by the task. Copied from the permanent workspace pool to the temporary pool at task start. Copied back to the permanent workspace pool only if accessed for update by the task.
Memory cost Exists only in the temporary workspace pool One copy in the permanent pool and one copy for each task referring to the workspace in the temporary pool One copy for each user in the permanent workspace pool, one copy for each task instance referring to the workspace for each user in the temporary workspace pool

6.4.4 Declaring and Referring to Workspaces

You can declare a workspace in the task definition using the WORKSPACE IS clause. Or you can declare the workspace in the task group definition with WORKSPACE IS and then refer to the workspace in the task definition with the USE WORKSPACE clause. It is usually more efficient to declare the workspaces in the task group definition rather than in the task definition. The difference s in these two approaches for each type of workspace are as follows:

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

6.4.5 Specifying Access for Workspaces

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

6.5 Using Task Queuing

ACMS typically does interactive processing of the tasks in your application, but you may find that certain tasks have requirements that you can meet through the use of task queues. These requirements include:

For these and other similar requirements, you can use the ACMS queuing facility to capture and initiate the tasks in your ACMS application.

Combine queuing with normal processing within a task when the data does not need to be synchronized. For example, in a task that ends with an update of multiple records, you can put the final processing step into a queued task; all the preceding steps can be interactive, even if they included write or modify operations. See the Compaq ACMS for OpenVMS Writing Applications for details about implementing a queued task, as well as a queued task example based on the AVERTZ application. The AVERTZ company offers a quick-checkin service for its customers. During peak periods, when many cars are being returned at the same time, customers can enter into the system their reservation information and the odometer reading from the car. The application stores the checkin information as a queued task that is processed at a later, less busy time. Section 6.6 describes the use of a queued task within a distributed transaction.

6.6 Designing Distributed Transactions

A business function usually involves several database operations. By including a set of operations within the bounds of a transaction, you are instructing ACMS to ensure that all updates are performed as an atomic transaction. ACMS uses the DECdtm services to ensure the integrity of a distributed transaction. Chapter 4 describes how to identify transactions for your business functions, including distributed transactions. This section offers details about the design of distributed transactions.

6.6.1 Locating Transaction Control

A distributed transaction must start and end in the same part of the application. You can start and stop a distributed transaction in a:

6.6.2 Choosing an Access Method to Remote Data

You have access to remote data included in a distributed transaction by using:

Figure 6-9 Using Rdb Remote Access for a Distributed Transaction


Figure 6_8 and Figure 6-10 illustrate the advantages of using the step procedure as an agent. In the example illustrated by Figure 6-8, using the ACMS SI:


Previous Next Contents Index