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:

• The Command Process (CP) sends a message to the ACMS Central Controller (ACC) to get information about the application.
• The ACC looks at the application specification and attempts to translate it as a logical name.
• The ACC then finds out if the application is running on the first, and possibly only, node named in the application specification. If it is, ACC uses that application.
• If the node is not reachable, or the application is not running, ACC looks at the next node in the application specification. If there are no more entries in the search list, or the logical name is not a search list, or the application specification contains a single hard-coded node name, then the task selection fails.
• If a usable application is found, however, ACMS then looks for an application database file (.ADB file) in the following manner:
  • First, ACMS translates the ACMS$ADB_CACHE logical and looks in the first directory specified in the search list (assuming that the logical translates to a search list).
  • If an up-to-date version of the .ADB is found, the task then executes.
  • If the .ADB is out-of-date, ACMS tries to update it. If this is impossible, perhaps because the directory is write-protected, then ACMS proceeds to the next translation of the ACMS$ADB_CACHE logical name.
  • If, in the process described in the preceding paragraphs, a translation is found that equals "NET", then ACMS uses DECnet to access the .ADB file.
  • If ACMS reaches the end of the search list and has not found a directory that contains the .ADB file, or found an obsolete file and could not update it, then ACMS starts at the beginning of the search list and tries to copy the .ADB file into each directory on the list.
  • As soon as ACMS finds a directory to which it can copy the .ADB file, it does so, and the task then executes.
  • However, if the end of the search list is reached and ACMS finds that all the directories are write-protected, or perhaps the disk is full or there is no disk quota left, then the task selection fails.

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:

• Manually copy the application and forms files for the applications you use most often to the cache directory on the submitter node.
• Cause ACMS to search a local cache directory before it searches the systemwide cache directory by redefining cache logical names.
• Allow remote access to application files that are infrequently used.

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:

• Copy .ADB files to ACMS$ADB_CACHE:[node]*
  You must use a wildcard file name to preserve the creation date. If the local application name is different from the remote name, you must rename the file.
• Copy TDMS .RLB files to ACMS$RLB_CACHE:[node.application]*
  You must use a wildcard file name to preserve the creation date. If the local application name is different from the remote name, you must rename the file. If an index must be attached to the file type, use the RENAME command.
• Copy DECforms .FORM and .EXE files to ACMS$FORMS_CACHE:[node.application]*
  You must use a wildcard file name to preserve the creation date. If the local application name is different from the remote name, you must rename the file. If an index must be attached to the file type, use the RENAME command. ACMS does not perform automatic installation of image form files. If you want to make shared image format a known shareable image, you must issue the INSTALL command manually.
  You must also manually distribute escape routine files that are not part of a shareable image. An escape routine can do anything that is allowed in the environment in which it runs; it can, for example, call routines in shared images, use logicals, and use global sections. Because it has no way of knowing what parts of the environment must be duplicated on a remote node, ACMS cannot automatically distribute escape routine files. See Section 6.6 for a description of managing DECforms escape routines.

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:

• ALL-IN-1
• Customer-written agents running the debugger
• Customer-written agents being executed directly by terminal users

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:

$ DEFINE/EXEC ACMS$FORMS_CACHE - _$ DRB2:[ALLIN1_CACHE.],DRA1:[ACMSDIR.ACMS$CACHE.]

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:

$ DEFINE ACMS$FORMS_CACHE DRA1:[ACMSDIR.ACMS$CACHE.],NET:

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:

• Making escape routines available to the CP agent
• Protecting privileged agents that execute escape routines
• Caching escape routines in a distributed environment

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:

• Linking escape routines with the form image
  You can make escape routines available to the CP agent by linking them into the same image as the form. An advantage to this method in a distributed processing environment is that the escape routines are automatically cached, with the forms files, to the remote submitter node.
  By using this method, however, you allow application code from a remote system to execute in a privileged environment on your system. But if the remote application node and the local submitter node are in a common security domain, this may not be a concern.
  To avoid the possible security problem of executing escape routines that are linked with the forms shareable image, ACMS, by default, does not execute these escape routines. To execute them, you must define the following system-level logical:

  ACMS$ESC_RTN_IN_FORM

  
  If the value of this logical is set to "T", "t", "Y", "y", or "l", then ACMS allows these escape routines to run. If this logical is not defined or has another value, ACMS does not execute the escape routines.

• Linking escape routines in a separate image
  You can also link escape routines in their own shareable image. You then need to make that image available to the CP agent by defining this logical:

  FORMS$IMAGE

  
  If you have more than one escape routine image, you can make the logical a search list of all images. For the ACMS-supplied CP agent, this logical must be in either the system group name table or the system name table. (Refer to DECforms documentation for more information about defining this logical.)
  If you use the FORMS$IMAGE logical to specify escape routine images, these escape routines can be shared by all of the applications that the CP agent references. However, sometimes the different applications may have the same escape routine name for different functions. To settle this possible naming conflict, ACMS provides an additional logical:

  ACMS$ESC_RTN_<node>_<application>

  
  You can use this logical to define an escape routine image for a particular application on a particular node. If the application uses more than one image, this logical can be a search list. When you use this logical name on a system where the NODE_NAME parameter is not defined in ACMSGEN, you must omit the <node> part from the logical name. Therefore, the logical name looks like:

  ACMS$ESC_RTN_<application>

  
  If you do not define this logical, or the specified logical is not on the search list, DECforms then uses the FORMS$IMAGE logical.

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.

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:

• Provide a faster response time for the user
  Providing high-speed links is often far too costly in an application with a widely distributed user base and relatively few users at each of many different sites. As an alternative to providing high-speed links, data compression can reduce the size of network messages, thereby reducing the time taken for the messages to be transmitted over the network. Thus, data compression can result in an improvement in the response time of an application for a user on a distributed front-end system.
• Reduce the cost of using the system
  Many public networks, such as various X.25 packet-switching networks, charge for data sent over the network from one node to another. Clearly, you can realize a cost savings by transmitting less data over the network while still providing the same service to users of applications on that network.

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:

• Data in task argument workspaces that an agent sends to and receives from a task
• Data in send and receive workspaces, send and receive shadow workspaces, and send and receive control text workspaces passed to DECforms forms
• Data in workspaces passed to TDMS requests
• Data in workspaces read or written using stream I/O

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:

• When minimal data is passed in large workspaces. In this case, the workspace should be space filled or zero filled.
• When large workspaces are sent over relatively low speed links.
• When the data in the workspaces contain long strings of consecutively identical bytes.