Compaq ACMS for OpenVMS
Managing Applications

Previous Contents Index

When a terminal user selects a task, ACMS processes the search list in an application specification from the first specification on the left to subsequent specifications, using the following sequence of actions:

Note that during the preceding sequence of events, ACMS does not attempt to look for another application using the application specification, because a running application has already been found and it is the cache problem that has caused the task cancellation.

Periodically, you may want to delete little-used files in the system cache directory. This could involve rarely used applications or nodes. This ensures that databases and forms that are infrequently used do not consume disk space. However, deleting files in the cache directory can cause slow response time for the first task selected in a remote application while ACMS copies the application and forms files to the submitter node.

On nodes with large disks, you can allow ACMS to automatically distribute all application database and forms files for all applications accessed by terminal users. On nodes with limited disk space, you may want to manually copy the forms and application files most frequently used and use access over the network for other, less frequently used, applications.

However, remember that performance may be affected when one of these less frequently used applications is selected, due to the need for network access to the form and application database files. The following section describes how to determine whether the manual distribution of application and forms files is advantageous for your particular site.

6.5 Tailoring ACMS Distributed Forms Processing to Your Site

You may be a system manager on a submitter node that has limited disk space, and want to avoid allocating the space needed for the automatic distribution of application and forms files. If this is the case, you can perform the following operations:

These methods are described in the following sections.

6.5.1 Manually Distributing Applications

To copy application and forms files when manually populating the system cache directory on a submitter node, you must know the remote file specifications of the application and forms files, and the application names that the files belong to. Assuming you have the needed file specifications and application names, you then take the following steps:

ACMS carefully preserves the original creation date and time on the local copy when it distributes files. You are responsible for this information if you manually distribute application and forms files. If you copy the files over the network using the OpenVMS COPY command, and specify the wildcard output file name and type, the COPY operation maintains the original creation date and time of the file.

If the destination application or forms file names differ from the source file names, you must still use the wildcard output file name and type when you copy the files. You can then use the OpenVMS RENAME command to add the necessary index to the file type of these files or to use the fully translated local application name as the file name of .ADB files. The RENAME command maintains the original creation date and time.

Destination application and forms file names can be different from the source names when an application uses two or more different application or forms files with the same file name and type, or when the local application name differs from the remote application name. If an application node has an application that uses two different forms files with the same file name and file type, there must be some way to distinguish them. This is done by modifying the file type.

For example, if application PAYROLL has two different files both called GENERAL.FORM, the file type is modified to include the index of the task group within the application and the index of the .FORM within the task group. The file index is obtained from the ADU DUMP APPLICATION and DUMP GROUP commands.

For example, the file type is modified to be .FORM_g_r, where g is the index of the task group (leading zeros suppressed) as recorded in the .ADB, and r is the index of the form file (leading zeros suppressed) as recorded in the .TDB. This method of indexing file types is the same for both DECforms and TDMS forms files.

ACMS automatically updates distributed files whenever they become outdated, however, you can prevent ACMS from automatically updating files by write-protecting the directories in which the files reside. ACMS does not update DECforms escape routines or their resources.

6.5.2 Creating Agent-Specific Cache Directories

An agent must have write access to the cache directory to update it. However, you usually do not want nonprivileged agents to update the cache directory. ACMS defines a nonprivileged agent as one that is not authorized as an agent with the User Definition Utility (UDU), and therefore cannot submit tasks for other users. Examples of nonprivileged agents are:

An agent image can be installed with privileges; however, do not assign privileges to an agent haphazardly, since an agent process executes under the terminal user's OpenVMS user name. Theoretically, the user whose name the agent process is running under could cause problems by adding an incorrect file to the system cache, thereby denying service to another user. For example, if you made ALL-IN-1 a privileged agent, ALL-IN-1 users would then be able to access the system cache directory with ALL-IN-1 commands. This could corrupt the system cache directory and its files, or cause other unexpected results.

You can avoid giving nonprivileged agents access to the system cache by creating an agent-specific cache directory. The agent-specific cache directory could be shared between agents (for example, all ALL-IN-1 users), or could be separate for each agent (for example, customer-written agents running the debugger).

Create the agent-specific cache directory in SYS$DISK. Then, define the logical name ACMS$RLB_CACHE or ACMS$FORMS_CACHE to point to either the agent-specific cache directory or a search list of directories.

The logical name can point to a local, agent-specific cache, and then to a central cache to which the agent does not have write access. For example:


Here, ACMS searches the private cache [ALLIN1_CACHE] for the DECforms file. If ACMS does not find the file there, it searches the public cache [ACMSDIR.ACMS$CACHE.]. If ACMS still does not locate the file, it creates a new version in the local cache.

The logical name ACMS$ADB_CACHE, which is normally a system logical name, must be available to the ACC. The ACMS$RLB_CACHE and ACMS$FORMS_CACHE logical names, however, can be defined as system, group, job, or user logical names, provided the logical name can be translated by the agent. They are usually defined as system logical names.

The ACMS remote request code in the agent process can only allow an agent to update a cache to which it has write access. If ACMS finds an out-of-date file in the central cache, it updates the file in the agent-specific cache.

If you are supporting multiple caches by using search lists, control where application and forms files are placed the first time they are copied from the application node. This is controlled through the use of a write-protected directory in the search list.

6.5.3 Accessing Remote Application Files

You can allow remote access for infrequently used application and forms files by adding the characters "NET:" to the end of your search list. For example, if you want to allow remote access to all DECforms files that are not found locally in DRA1:[ACMSDIR.ACMS$CACHE.], you define the ACMS$FORMS_CACHE logical as follows:


The "NET:" designation tells the ACMS run-time system that if the application or forms file is not found in the local ACMS$CACHE directory, it must open the application or forms file using remote DECnet file access. This requires that there be a process on the application node for each agent for each application and forms file. ACMS reads the .ADB files once and then keeps them in memory. See Section 6.4 for information on how ACMS updates remote application and forms files.

6.6 Managing and Caching DECforms Escape Routine Files

With DECforms, application program subroutines can be called during the processing of an external request. These subroutines, called escape routines, are executed in the context of the agent process. Because of this, application and system managers must consider the following:


Many agents, including the ACMS-supplied CP agent, perform work on behalf of multiple users. These agents are multithreaded or asynchronous. However, DECforms escape routines provide only a synchronous interface. When you use an escape routine in a multithreaded agent, be careful not to do anything that might delay the CP agent in processing other users' requests. For example, do not use an escape routine to perform terminal or disk I/O, because this stalls other users.

6.6.1 Making Escape Routines Available to the CP Agent

The two methods for making escape routines available to the CP agent are: link them with the form image, or link them in a separate image. There are advantages and disadvantages to each method, as follows:

6.6.2 Privileged Agents that Execute Escape Routines

Certain agents, such as the ACMS-supplied CP agent, run in a privileged environment. Any escape routines that execute in a privileged agent also execute in the same privileged environment. Be sure to develop escape routines to execute in a privileged agent in the same way as you develop any other privileged code. Carefully review the code for any possible security violations before you run it live on the system.

Place the escape routine images in a write-protected directory; also write-protect the images themselves. After you place the file in a protected directory, you can define the logicals that make the escape routines available to the agent process.

You may not, however, need to place escape routines executed by a nonprivileged agent in a protected directory. In some cases, such as debugging, you may want the person running the CP agent to be able to change the escape routines executed. Use the methods described previously to make the escape routine images available to the CP agent.

Chapter 7
Using Data Compression

This chapter describes the data compression feature that can improve system response time and reduce the cost of transmitting data across networks.

For information on designing ACMS applications, refer to Compaq ACMS for OpenVMS Concepts and Design Guidelines.

7.1 Overview of Data Compression

This section provides an overview of data compression, by describing the purpose of data compression and how this feature works.

7.1.1 Purpose of Data Compression

In wide area networks, data must often be transmitted over relatively slow links. Also, many public networks charge for each packet of data transmitted over the network. In these situations, compressing the data before sending it over the link can accomplish one or both of the following:

7.1.2 How ACMS Uses Data Compression

You can enable data compression selectively between systems in a network. You might, for example, have a mixed configuration that has both wide area and local area networks. If both the submitter and application nodes exist on the same local area network, the cost of compressing data far outweighs the cost of transmitting uncompressed data over the network.

You can control data compression on a per-process basis. For example, data compression might be beneficial if you enable it for a forms-based agent such as the Command Process (CP). On the other hand, data compression might not be appropriate for a specialized user-written agent, if that agent processes data that is not compressible using the ACMS data compression algorithm.

ACMS provides system management tools that allow you to control the use of the data compression. One mechanism enables you to verify that data compression is enabled and used correctly. Another mechanism allows you to monitor the efficiency of the data compression algorithm in terms of the amount of data compression that is achieved.

ACMS compresses the following types of workspace data:

ACMS does not compress other data such as DECforms send and receive record names or TDMS request names.

7.1.3 How Data Compression Works

The amount that data can be compressed must be offset against the cost involved in compressing the data before it is sent over the network, and decompressing the data after it has been received. The cost is measured by CPU and memory usage.

To implement data compression, ACMS uses a simple run-length encoding algorithm that aims to provide a reasonable data compression ratio in typical applications, while not consuming excessive CPU or memory resources. In most cases, a higher compression ratio provides better performance in terms of less CPU usage and improved response time. See Table 15-2 for more information about the compression ratio.

Due to the overhead of the information necessary to describe the compressed data, compressed data sometimes occupies the same or more space than its original uncompressed form. In this situation, ACMS uses the uncompressed form when constructing a message to transmit over a network. However, when data compression is enabled, ACMS always sends less data, even if the workspaces data cannot be compressed; at the very least, the message overhead is optimized for space rather than for speed of processing.

In general, applications benefit most when using data compression under the following conditions:

Previous Next Contents Index