There are a large number of ACMS and OpenVMS system parameters that affect the internal processing of the ACMS Remote Manager. In general, most of these parameters will not need to be changed. However, you may need to alter some of these parameters in order to tune the Remote Manager system to make it operate more efficiently or to meet your computing needs. You can modify these parameters using both the ACMSCFG and the ACMSMGR utilities.

For a more complete discussion of the available management parameters and their functions, see Section 9.9.

4.6.1 Using ACMSCFG to Modify Management Parameters

Use the ACMSCFG utility to set the values of management parameters when the Remote Manager starts up.

Use the ACMSCFG SET PARAMETER command to modify the value of a parameter. The command has the following syntax:

ACMSCFG SET PARAMETER /parameter-name=value

In this format:

• parameter-name is one of the management parameters listed in Section 9.9.
• value is the new value for the parameter.

Use the ACMSCFG SHOW PARAMETER command to determine the current value of the parameter in the configuration file:

$ ACMSCFG SHOW PARAMETER

4.6.2 Using ACMSMGR to Modify Management Parameters

Use the ACMSMGR utility to dynamically modify a management parameter after the Remote Manager has already been started. Not all parameters can be modified dynamically. Also, changes made with the ACMSMGR interface are not stored in the ACMSCFG file and are lost when the Remote Manager is stopped.

Use the ACMSMGR SET PARAMETER command to modify the value of a parameter. The command has the following syntax:

ACMSMGR SET PARAMETER /parameter-name=value

In this format:

• parameter-name is one of the dynamic management parameters listed in Section 9.9.
• value is the new value for the parameter.

Use the ACMSMGR SHOW PARAMETER command to determine the current value of the parameter in the configuration file:

$ ACMSMGR SHOW PARAMETER

4.7 Managing the Remote Manager Log File

The ACMS Remote Manager maintains a Remote Manager log that contains status messages about all Remote Manager transactions. The audit log is stored in a location determined by the logical name ACMS$MGMT_LOG. If this logical is not defined, the default location is in the default directory for the account under which the Remote Manager process runs.

Depending on the audit tracing levels, the size of this file can vary. It is strongly suggested that ACMS system managers monitor this file to ensure that it does not grow too large.

If the Remote Manager is unable to write to the log file, it prints a message to file SYS$ERRORLOG:ACMS$MGMT_SERVER.OUT and terminates. This can occur if a logical name is defined incorrectly, if the output device is full, or if the Remote Manager does not have sufficient privilege to write to the file.

4.7.1 Setting Audit Levels

Facilities within the Remote Manager write audit messages based on the parameter settings, as shown in Table 4-1.

Table 4-1 Audit Level Parameters

Parameter	Function
DCL_AUDIT_LEVEL	Controls auditing for the DCL subprocess (used internally to modify the ACMS run-time system).
MGR_AUDIT_LEVEL	Controls auditing for the main Remote Manager process.
MSG_PROC_AUDIT_LEVEL	Controls auditing for the message processing thread (used internally to handle communications from ACMS processes).
PROC_MON_AUDIT_LEVEL	Controls auditing for the process monitor.
RPC_AUDIT_LEVEL	Controls auditing for the RPC interface.
SECURITY_AUDIT_LEVEL	Controls auditing for security access (authorization and authentication).
SNAP_AUDIT_LEVEL	Controls auditing for data snapshot threads.
SNMP_AUDIT_LEVEL	Controls auditing for the SNMP interface.
TIMER_AUDIT_LEVEL	Controls auditing for the timer thread.
TRAP_AUDIT_LEVEL	Controls auditing for the trap thread.

The value of each parameter determines what level of information is stored in the Remote Manager log. Table 4-2 shows the four levels of auditing and the integer value for each.

Table 4-2 Auditing Levels and Their Values

Auditing Level	Integer Value
Informational	1
Warning	2
Error	4
Fatal	8

Auditing values can be combined by logically ORing the integer values in order to have multiple levels of auditing in effect for a given facility. Table 4-3 shows the valid auditing values.

Table 4-3 Auditing Level Combinations and Their Values

Auditing Level	Value
None	0
Info	1
Warn	2
Info, Warn	3
Error	4
Info, Error	5
Warn, Error	6
Info, Warn, Error	7
Fatal	8
Info, Fatal	9
Warn, Fatal	A
Info, Warn, Fatal	B
Error, Fatal	C
Info, Error, Fatal	D
Warn, Error, Fatal	E
All	F

Parameter settings are stored in the ACMSCFG file and can also be modified dynamically using the ACMSMGR utility. For example, in order to specify that all messages and events generated by the security routines should be stored in the log, use the following command:

$ ACMSCFG SET PARAMETER/SECURITY_AUDIT_LEVEL=F

Alternatively, to dynamically modify an auditing level, use the following ACMSMGR utility command:

$ ACMSMGR SET PARAMETER/SECURITY_AUDIT_LEVEL=F

4.7.2 Displaying Audit Messages

Use the SHOW LOG command in the ACMSMGR utility to display Remote Manager audit messages. This command accepts a number of qualifiers, including a qualifier that identifies the node from which to get audit messages (/NODE) and a qualifier that specifies the beginning time of messages to display (/SINCE).

The following example shows how to display audit messages from the node SPARKS:

$ ACMSMGR SHOW LOG/NODE=SPARKS

You can display audit messages from a node other than the current node only if the Remote Manager is running on the target node. If the Remote Manager is not running on the target node, you must first log in to the target node, and then issue the SHOW LOG command using the /LOCAL qualifier.

The following example shows how to display audit messages on the current node when the Remote Manager process is not running:

$ ACMSMGR SHOW LOG/LOCAL

For a complete description of the ACMSMGR commands and qualifiers, see Chapter 11.

4.7.3 Resetting the Log

Use the ACMSMGR RESET LOG command to close the current Remote Manager log file and open a new version. You may want to reset the log if it has grown too large.

The following example shows how to reset the log on node SPARKS:

$ ACMSMGR RESET LOG/NODE=SPARKS

This chapter describes how to use the Remote Manager to monitor and manage ACMS run-time processes.

5.1 Managing Data Collection

Data collection is the mechanism by which ACMS run-time data is made available to the ACMS Remote Manager and, consequently, to other processes. Data collections themselves do not involve disk or network read/write operations. All data collection is performed in memory on the local node. However, system managers can choose to save collected data at periodic intervals and write that data to a snapshot file (see Section 5.2).

ACMS system managers control what data is collected by manipulating entries in the Collection table. In the Collection table, the data to be collected is specified by a combination of entity, class, and name.

• Entity refers to an ACMS run-time process type, such as ACC, EXC, or CP.
• Class refers to the class of data to be collected (see Section 5.1.1).
• Name refers to a process or application name that uniquely identifies a particular ACMS run-time process.

Using the combination of entity, class, and name gives ACMS system managers a great deal of flexibility in configuring the data to be collected.

Data collection can be managed either statically, through the ACMSCFG file, or dynamically, using one of the supported interfaces. For example, the ACMSMGR SET COLLECTION command can be used to dynamically enable or disable data collection on a local or remote node. Similarly, SNMP management tools can issue SNMP SET commands to dynamically modify entries in the Collection table. Users can also write their own programs and use the remote procedure call acmsmgmt_set_collection_1 (see Chapter 8) to dynamically manage data collection.

In general, management information is not collected unless an ACMS system manager has specifically enabled it. The exceptions are identification and configuration information (ID and CONFIG). By default, these two classes of data are enabled for all ACMS entities. Having these classes enabled by default is an optimization that imposes little run-time overhead and ensures that process startup information is available. Compaq recommends that you leave these classes enabled.

Data collection for other entities and classes is not enabled by default. When the ACMS system is started, the ACMS processes read either the configuration file (if the Remote Manager is not already running) or the Collection table to determine which classes of data to collect. Thereafter, external processes use the SNMP or RPC management interfaces to enable or disable data collection for a given entity, class, and name.

For each entity and class for which collection is enabled, a table of data values is populated by the appropriate ACMS processes (determined by name) and can be accessed by external entities using one of the data access interfaces (SNMP or RPC).

ACMS entities that collect data do so continuously when collection has been enabled for that entity/class/name combination. With the exception of event notifications (generated as the result of ACMS process startup or shutdown) and POOL, ERROR, and snapshot information (which is updated based on timer intervals), collection data is modified when it changes.

5.1.1 Entities, Classes, Names, and Collections

ACMS system managers control data collection by modifying entries in the Collection table. The Collection table is keyed to entity, class, and name.

An entity is an ACMS run-time process or object. The valid ACMS entities are:

• ACC
• CP
• EXC
• QTI
• SERVER
• TASK GROUP
• TSC
• * (all)

The asterisk (*) wildcard value is valid and specifies all entities. When specifying an entity, you are specifying its process type.

A class is a set of run-time data values that entities set. Referring to data by class is a convenient method of referring to a set of related data values. However, the actual values contained in a class are entity specific. The following are valid classes:

• Configuration (CONFIG)
  This class is a set of values that can be changed for the process and that controls some fundamental aspects of the execution. Configuration values are entity specific. An example of a Configuration class value for ACC is the maximum number of applications that may be running. An example value for a Server is the maximum number of instances.
• Identification (ID)
  This class is a set of values that do not change for the process as long as it is running and that help identify the process. Examples of Identification class values are process name, PID, and version.

• Pool (POOL)
  This class is a set of values related to the current or historical MSS or workspace pool processing for the process. MSS pool values are the same for all entities except ACC. An example of a Pool class value for ACC is the current free amount in the MSS shared pool. An example value for other processes is the current free amount in the MSS process pool.
• Run-time (RUNTIME)
  This class is a set of values that reflect either current or historical run-time processing for the process. Run-time values are also entity specific. An example of a Run-time class value for ACC is current number of applications. An example value for an EXC is the current number of executing tasks.
• Error (ERROR)
  This class is a set of values pertaining to a specific error reported by a process. Error values are the same for all entities. An example of an Error class value is the date and time when an error occurred.
• *
  The asterisk is a wildcard value that specifies all classes.

A name specifies one or more specific processes of an entity type. The name field is entity specific. An example name for EXCs is the application name. An example name for CPs is process name. The asterisk (*) wildcard value is also supported and matches all names.

Entity, class, and name are used in combination to determine which processes will collect which values. Duplicate rows (that is, rows with the same entity, class, and name) are not allowed, but it is possible to have overlapping entries in the Collection table if the asterisk wildcard value is used. Consider the example in Table 5-1.

Table 5-1 Example 1: Collection with Wildcards

Name	Entity	Class
*	ACC	*
*	ACC	Runtime

In respect to typical data collections, the entries in this example overlap but are not duplicates. This is allowed because the attributes of each collection may be different.

In respect to data snapshots, the entries in this example would result in separate snapshot threads if the storage state were enabled for both collections. Each thread would write ACC run-time information, which may or may not be intended result. Therefore, users should be cautious when using wildcards to avoid redundant processing.

When more than one row applies to a data collection, the most specific row will be used, based on the column precedence of name, then entity, and then class. Within a particular column, wildcards are the least specific. In Table 5-1, both rows are equivalent in name and entity, but the second row is more specific in class. In this case, the values from the first row will be used for all classes except the Runtime class. The values from the second row will be used for the Runtime class.

Consider the example in Table 5-2.

Table 5-2 Example 2: Collection with Wildcards

Name	Entity	Class	Collection State
*	*	Runtime	Enabled
*	EXC	Runtime	Disabled
VR_APPL	EXC	Runtime	Enabled

In this example, the first row enables run-time data collection for all entities. The second row disables it for all EXCs. The third row enables it for the VR_APPL. As a result, among applications, only the VR_APPL will collect run-time data.

To help identify which row is the most specific and therefore will apply to a given process, the ACMSMGR command SHOW COLLECTIONS includes a column that represents the weight of a given row. A row with higher weight overrides a row with lower weight when they apply to the same class and process. Consider the following example, which is the same as the example in Table 5-2 but includes the weights (in the column labelled "Wt") of each row.

SPARKS> ACMSMGR SHOW COLLECTION ACMS Remote Management -- Command line utility ACMS V4.4-0 Entity/Collection Table Display Time: 19-APR-2001 11:46:36.49 Node Wt Entity Collect Collect Storage Storage Type Entity Name Class State Storage Location State Interval ------------ -- ------ -------------- ------- -------- ------------------ -------- -------- SPARKS 2 * * runtime enabled acms$mgmt_snapshot enabled 3600 SPARKS 4 exc * runtime disabled acms$mgmt_snapshot disabled 10 SPARKS 8 exc VR_APPL runtime enabled acms$mgmt_snapshot disabled 10

In this example, the last row has the highest weight, and will override the other two rows for the RUNTIME class for the VR_APPL.

5.1.2 Starting and Stopping Collections

Users start and stop data collections by modifying the collection state (coll_state) field in the Collection table. The Collection table is accessed through either the ACMSCFG utility prior to management startup or through the ACMSMGR utility after Remote Manager startup.

By default, the ACMSCFG file includes entries to enable collection for the Identification and Configuration classes for all processes. Unless specific action has been taken to disable these collections, identification and configuration information is always available for all running processes.

Before a collection can be modified, it must be added to the entity collection table. By default, if the collection state is not specified when a collection is added, the collection state is DISABLED. Otherwise, the collection state is whatever was specified.

When the data collection state is set to ENABLED, the Remote Manager sends messages to the appropriate ACMS processes (based on the entity and name fields in the Collection table row) to begin collection for the class. When the data collection state is set to DISABLED, a similar message is sent to stop collection for the class. Once collection has started, it continues until the data collection state is set to DISABLED.

The requesting user must have ACMS$MGMT_WRITE privilege in order to start or stop a collection.

5.1.2.1 Using ACMSCFG to Start or Stop Collections

Use the ACMSCFG utility to set the state for a collection when the Remote Manager starts up. Some ACMSCFG commands are described here; for details on all ACMSCFG commands, see Chapter 10.

Use the ACMSCFG ADD COLLECTION command to create a new collection record. The command has the following syntax:

ACMSCFG ADD COLLECTION /ENTITY=entity /CLASS=class /NAME=name /COLL_STATE=state

Use the ACMSCFG SET COLLECTION command to modify the state of an existing collection record in the configuration file. The command has the following syntax:

ACMSCFG SET COLLECTION /ENTITY=entity /CLASS=class /NAME=name /COLL_STATE=state

Use the ACMSCFG DELETE COLLECTION command to delete a collection. The command has the following syntax:

ACMSCFG DELETE COLLECTION /ENTITY=entity /CLASS=class /NAME=name

Deleting a collection can cause the Remote Manager to disable the class for a process because collections are disabled by default. The collection state for a process becomes disabled when no collections remain to specifically enable the class.

Use the ACMSCFG SHOW COLLECTION command to determine which collections already exist and their collection states. The command has the following syntax:

ACMSCFG SHOW COLLECTION