This chapter provides guidelines for grouping tasks into task groups, and for defining applications.

9.1 Designing Task Groups

A task group describes a collection of tasks and the resources available to those tasks. Resources include workspaces, request libraries, forms, user request procedure libraries, message files, and the procedure servers in which processing is done.

9.1.1 Grouping Common Elements in a Task Group

You group tasks together into a task group based on common resources used by the task:

• Procedure servers
  Task groups cannot share procedure server processes at run time. Therefore, group together tasks that use the same server to allow those tasks to share the same pool of server processes.
• DECforms forms
  ACMS enables DECforms form sessions based on the task group in which the form is declared. Therefore, if multiple tasks need to share form data in a DECforms form, you must include those tasks in a single task group.
• Group and user workspaces
  Group and user workspaces cannot be shared between tasks in different task groups. Therefore, include tasks that use the same group or user workspaces into a single task group.

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

9.1.2 Determining the Number of Task Groups in an Application

Combining tasks into a single task group offers the advantage of:

• Decreasing the number of procedure servers required for the application
  Every task group within an application must have at least one procedure server. By creating only a single task group, you save system resources by servicing all the tasks with one procedure server, or with only a few.
• Promoting sharing of resources
  For example, group and user workspace contents can be shared. This is helpful if a sequence of tasks with similar data is necessary. The user need not repeatedly type in the same data.
• Easing application growth
  If new tasks are added that have to share resources with other tasks, you don't have to restructure the task group.
• Easing application building
  With only one task group, building the application is less complicated.

Single task groups have the disadvantage of:

• Increasing build time
  Increasing the task group size increases the time necessary to build the task group. If you have to rebuild your task group often, take into consideration the resources and time required to build.
• Causing possible maintenance problems
  If your task group becomes too large, or the scope of the functions included in the task group become too varied, coordinating task group maintenance can become a problem.
• Inhibiting ability to group tasks logically
  In some instances, it may be beneficial to group tasks according to function. For example, if an application has tasks for accounting and tasks for engineering, separate the tasks into two groups to ease maintenance and create logically defined groups of tasks.

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.

9.1.3 Improving Performance with the Task Group Definition

This section discusses task group definition syntax likely to have significant positive or negative effects on performance.

• RUNDOWN ON CANCEL procedure server subclause
  If you use the RUNDOWN ON CANCEL clause, and a task is canceled while it is executing or retaining context in a server process, ACMS runs down the process and starts a new one if required. To avoid unnecessary server process rundowns, use the RUNDOWN ON CANCEL IF INTERRUPTED clause. Using this clause, ACMS only runs down a server process if ACMS interrupted the server process while it was executing. If a task is canceled while retaining context in a server, the server process is not canceled and can be used by another task. RUNDOWN ON CANCEL is the default.
• USERNAME IS TERMINAL USER procedure server subclause
  The REUSABLE server subclause in the task group definition is the default for both DCL and procedure servers. However, using the clause USERNAME IS TERMINAL USER in application or task group definitions overrides this default and creates procedure servers that are not reusable.
  Every time a terminal user selects a task running in a procedure server defined with the USERNAME IS TERMINAL USER subclause, a new server process must be created for that task instance.
• If your application includes both inquiry and update tasks, you can avoid a good measure of database contention by defining two procedure servers for your application:
  • One whose procedures access the database in read-only mode for inquiry purposes
  • One whose procedures use read-write access for updates
  
  AVERTZ makes this distinction, using the VR_READ_SERVER and the VR_UPDATE_SERVER. With this kind of separation, tasks that only query the database do not contend with tasks that update it. More importantly, the number of server processes simultaneously accessing the database for update is usually fewer with this approach, significantly reducing contention.
  Also, you can create servers that access specific sets of relations in the database. This allows you to further reduce database contention by giving you greater control over the number of servers that are used to access particular areas of the database. AVERTZ employs this technique by using the VR_UPDATE_SERVER to access the RESERVATIONS, VEHICLES, and VEHICLE_RENTAL_HISTORY relations, and the VR_CU_UPDATE_SERVER to access the CUSTOMERS and CU_ID_INC_CONTROL relations.

In the application definition, you describe the application environment by defining control characteristics for the application. Access to tasks is always controlled from the application definition. An application definition does the following:

• Names the task groups that contain the tasks of the application
• Assigns a user name to the Application Execution Controller (EXC), the ACMS system process that controls the application
• Assigns user names to the server processes created by the application

You can optionally assign characteristics that:

• Control access to tasks
• Audit task events
• Enable and disable tasks
• Specify transaction timeouts

You control procedure servers in an application by assigning server control attributes in the application definition. These attributes determine the processing characteristics of a procedure server.

Compaq ACMS for OpenVMS Writing Applications gives details about writing application definitions.

9.2.1 Determining the Number of Applications

Combining applications has the following advantages:

• Decreases the number of Application Execution Controllers, and improves the overall use of system resources.
• Minimizes the duplication of similar or identical task groups.
  Each application supports at least one task group. With a single application, you can eliminate some task groups. Fewer task groups require fewer procedure servers, thereby further improving overall resource use.

Multiple applications have the following advantages:

• Allows for moving or separating of applications to separate machines
• Eases maintenance by separating applications by specialized functions
• Conserves resources if you have functions that do not need to process simultaneously
  For example, you can design an application that is active only one day a week, freeing resources on other days.
• Meets needs for financial accounting
  If resource costs are to be shared on an application basis, multiple applications are needed . For example, OpenVMS accounting for an application's users cannot be done because processes and resources are shared among all the users. If separate applications exist you can charge each user individually based on the unique application name.

Application design and hardware configuration together have the greatest effect on the performance of the ACMS system. Tuning the OpenVMS parameters of the ACMS system itself after implementation has a lesser effect. Tuning the definition of your application, however, can have a significant effect on performance. For example:

• Adjust the number of server processes that your application runs
  At definition time, you can establish parameters for an application that reduce the amount of tuning you need to do after implementation. For example, you can set the minimum and maximum values for the server process count to a number likely to eliminate unnecessary server process creation and deletion.
  AVERTZ sets VR_READ_SERVER to a maximum of 3, and to a minimum of 1. VR_UPDATE_SERVER has both a maximum and minimum of 1. As you monitor the performance of your application, you can adjust these values.
• Segregate procedure servers by function
  Providing separate servers for read or write functions is a common design model. You can also choose to provide one or more procedure servers for CPU-intensive procedures. Or, you can provide one or more separate procedure servers for activity with special security considerations.
  The AVERTZ application uses the VR_LOG_SERVER for security and auditing purposes. AVERTZ segregates procedure servers by read or write functions.
• Create separate user names for the various procedure servers
  This use of separate user names allows for specific privileges and quotas.
• Avoid the USERNAME IS TERMINAL USER procedure server subclause
  The REUSABLE procedure server subclause in the task group definition is the default for both DCL and procedure servers. However, using the clause USERNAME IS TERMINAL USER in application or task group definitions overrides this default and creates procedure servers that are not reusable.
  Every time a terminal user selects a task with a processing step running in a procedure server defined with the USERNAME IS TERMINAL USER subclause, a new server process must be created for that user. ACMS, however, places its emphasis on shared and reusable resources. To take advantage of this, your application should run as few server processes as needed to do the work of the application.
• Use the server subclause NO PROTECTED WORKSPACES
  The default is PROTECTED WORKSPACES. The default action is for the server to map only the portion of the task instance workspace pool used by the current task. This portion is mapped at the start of a processing step and unmapped at the end of the step, ensuring that one task cannot access the workspaces of any other task in the group.
  The NO PROTECTED WORKSPACE clause saves workspace mapping time. However, use it carefully since it maps the entire task instance workspace pool for a task group. Use it only after you have thoroughly debugged your procedure server and are certain that task procedures will not accidentally write over workspaces belonging to another task.
• Exercise care with the SERVER MONITORING INTERVAL clause
  This clause determines how often ACMS checks the queues of tasks waiting for procedure servers. You use it in conjunction with the CREATION INTERVAL, CREATION DELAY, DELETION INTERVAL, and DELETION DELAY clauses, which alter the ACMS-supplied defaults for these values. Use of these clauses affects the rate and interval at which new server processes are created or deleted. If you set the server monitoring interval too low, ACMS can use up most of its resources in checking on its own performance.
• Choose whether or not to use the AUDIT subclause
  The AUDIT subclause records application and task activity in the ACMS audit trail log. For example, if you enable application auditing, ACMS records application events, such as online modifications to the application. If you enable task auditing, ACMS records the start and end of task instances. ACMS always audits unusual events, such as unexpected server deaths and unexpected task cancellations, in the ACMS audit trail log.

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 Compaq ACMS for OpenVMS Managing Applications, which includes sections on ACMS system monitoring, tuning, and setting the OpenVMS SYSGEN parameters that ACMS affects.

Performance problems often have their root in database performance. You can determine if your database is responsible for your problems through monitoring. Each of the following database management system documentation sets includes a manual on tuning and performance:

• For RMS files, see Guide to OpenVMS File Applications
• For Rdb databases, see the Rdb documentation
• For DBMS databases, see the DBMS documentation

The Requirements Specification specifies the business need and the requirements that must be met to solve that business need. The Requirements Specification is high level and can be produced in a limited time frame. It does not contain specific design details unless these are considered to be a business requirement. It bridges that gap between a customer's business need and the Functional Specification and Programming Specification.

A.1 Overview

This section presents an overview of the system and basic requirements.

A.2 Business Objectives

This section covers the business needs to which the eventual solution will respond, and the business goals with related measurements.

A.2.1 Business Needs

Identify the business needs of the customer.

A.2.2 Business Goals and Measurements

Identify the business goals of the customer and how they are measured.

A.3 Solution Requirements

The following sections describe the scope of the analysis in terms of business areas being looked at and the business functions carried out by these business areas:

• Business area A
  • Business functions
  • Communication being used (forms, letters, telephone, computer...)
  • Average time required to carry out each business function
  • Frequency of each business function
  • Drawbacks of current approach
• Business area B
  As for business area A

• Information flow
  • What information
  • Where information originates
  • Where information terminates
• Execution time
  • Throughput
  • Response-time
• Availability
  • Reliability
  • Recoverability
• Processing immediacy
• Security
  • Access
  • Audit/Tracking
  • Authentification
• Usability
  • Learning
  • Using
• Flexibility
  • Maintainability
  • Enhancement cost
  • Maintenance cost
  • Ease of change
  • Evolution (expected change)
• Business constraints
  • Company policies
  • Development costs
  • Operational costs
  • Time scale and deadlines

This section covers the business-related system environment needs. It also covers the business related general solution needs, which typically are defined by strategies external to the project. Training, documentation, and support requirements are presented here. It specifies any requirements that will not be met by the project and explains why they will not be met:

A.4.1 Environment

• Current systems
• Geographic distribution
• Space constraints

• Phased or one-off
• Timetable
• Rollout
• Responsibilities

• Acceptance criteria

• Maintainability
• Service response

• Coexistence/interoperability
• Implementation requirements
  • Cost
  • Tools
  • Training
  • Product
  • Internationalization
  • Standards
  • Business rules
• Operation requirements
  • Centralized/decentralized operation
  • Number and organization of operational staff
• Compatibility between processes and existing user habits

List any limitations to implementing the solution.

A.5 Alternative Solutions Rejected

Any other solutions with the reason why they were not selected.

The Functional Specification specifies, in non-technical terms, what the solution does for the customer. It is a detailed specification of the functionality to be addressed by the solution. This document defines what functions the system will be capable of performing. It is the blueprint for the subsequent design and programming of the system.

Functional specifications are used for monitoring progress during system development, and are the basis of final customer acceptance of the complete system. A definitive Functional Specification ensures that the Customer's functional needs are correctly identified.

B.1 Overview

The overview is a brief description of the system allowing the readers an understanding of the aims of the system. The system can also be depicted pictorially, typically using data flow diagrams. A brief description is given of each external entity covering its interactions with the system. Processes and data stores are also described. The overview consists of:

• Introduction
• Solution description
• Objective and customer goals
• Existing methods and processes
• Required methods and processes
• Impact
• Implementation requirements

This is the main section of the Specification. It provides sufficient detail to constitute the definition of the system. It describes what is required, how the requirements will be met, and includes a logical model of the proposed solution.

B.2.1 External Interfaces

• General principles and common characteristics
• Layout of the different reports and screens
• Help information

Transform the business transactions defined in the Requirements Specification into logical transactions:

• Create a logical database design
• Refine the business transactions into database transactions
• Identify details of distributed transactions
• Determine transaction volumes and their origination
• Define transaction availability
• Define the concurrency
• Define the transaction and data immediacy
• Define the distributed forms processing
• Define the deferred processing

• Data volumes
• Availability
• Fault tolerance
• Throughput
• Response time

This section describes the characteristics of the system's users, software and hardware requirements for installing, operating and interfacing the system, and security requirements:

• Organizational
• User
• Physical
• Hardware environmental requirements
• Software environmental requirements
• Security

This section describes the customer's quality requirements in terms of:

• Ease of use
• Maintainability
• Reliability
• Evolvability
• Compatibility

Any general requirements not covered in the sections above are described here:

• Performance
• Packaging
• Implementation
• Installation

Any stated requirements not met or specific limitations imposed for the new system are listed here.

B.7 Documentation

This section describes the publications to be provided for the system, including user, system, and technical documentation.

B.8 Training

This section describes training requirements and how they will be met. The training may include user, operation, and technical training.

B.9 Definitions

B.10 Glossary