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

3.7.3 Resetting the Audit Log

Use the ACMSMGR RESET LOG command to close the current audit 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

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 do not involve disk or network read or write operations. All data collection is performed in memory on the local node.

ACMS systems 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 4.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 7) 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. 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 information (which is updated based on timer intervals), collection data is modified when it changes.

4.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
  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
  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
  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
  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 Runtime class value for ACC is current number of applications. An example value for an EXC is the current number of executing tasks.
• *
  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 4-1.

Table 4-1 Example 1: Collection with Wildcards

Name	Entity	Class
*	ACC	*
*	ACC	Runtime

In this example, the entries overlap but are not duplicates. This is allowed because the attributes of each collection may be different. But users should be cautious when using the wildcard to avoid redundant processing.

When more than one row applies, 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 4-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 4-2.

Table 4-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.

As an aide to identifying 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 4-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.3-0 Entity/Collection Table Display Time: 9-OCT-1999 11:46:36.49 Node Wt Entity Collect Collect Type Entity Name Class State ------------ -- ----------------------------------------------------------- SPARKS 2 * * runtime enabled SPARKS 4 exc * runtime disabled SPARKS 8 exc VR_APPL runtime enabled

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.

4.1.2 Starting and Stopping Collections

Users start and stop data collections by modifying the data collection 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.

4.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 9.

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

Use the ACMSMGR utility to dynamically modify the state of a collection after the Remote Manager has already been started. Note that changes made with the ACMSMGR interface are not automatically stored in the ACMSCFG file and are lost when the Remote Manager is stopped.

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

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

Use the ACMSMGR SET COLLECTION command to modify the state of an existing collection. The command has the following syntax:

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

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

ACMSMGR 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 ACMSMGR SHOW COLLECTION command to determine which collections already exist and their collection states. The command has the following syntax:

ACMSMGR SHOW COLLECTION

4.1.2.3 Using SNMP to Start or Stop Collections

Use the SNMP interface to dynamically modify the state of a collection after the Remote Manager has already been started. Note that changes made with the SNMP interface are not stored in the ACMSCFG file and are lost when the remote Remote Manager is stopped.

The SNMP interface responds to SNMP commands issued by SNMP consoles. An SNMP console issues an SNMP SET command to the Remote Manager to modify the Collection table.

The SNMP OID (object ID) for the collection state columns are documented in Appendix C. The data type for the field is INTEGER. Possible settings for this field have the following meanings:

• 0 = Collection is disabled.
• 1 = Collection is enabled.
• 9 = Collection record is deleted.

You cannot add a collection record using the SNMP interface.

4.2 Displaying Collected Data

Management data can be displayed using either the ACMSMGR utility or one of the programming interfaces (SNMP or ONC RPC). Data is displayed by entity and, optionally, by class.

4.2.1 Using ACMSMGR to Display Collected Data

Use the ACMSMGR SHOW command to display collected data. See Chapter 10 for a description of each command.

The following ACMSMGR command displays ACC data:

$ ACMSMGR SHOW ACC /NODE=SPARKS /ID

The following example shows output from this command:

ACMS Remote Management Option -- Command line utility ACMS V4.3-0 ACC Table Display Time: 9-OCT-1999 11:59:09.56 Collect Node State Pid Proces Name Start Time User Name Version ------------ -------- -------- --------------- ----------------------- ------------ ---------------- sparks enabled 2020C8BB ACMS01ACC001000 8-OCT-1999 14:44:47.29 SYSTEM V4.3-0

4.3 Managing ACMS Using the Remote Manager

The ACMS Remote Manager provides the ability to modify the running ACMS system using either the SNMP or the RPC interface. In general, only Configuration class variables can be modified at run time. However, not all Configuration class variables can be modified. Chapter 8 lists all Configuration class variables by entity and indicates which ones can be modified.

4.3.1 Types of Variables

Many Configuration class variables can have the following two forms:

• Stored variable (see Section 4.3.1.1)
• Active variable (see Section 4.3.1.2)

The programming interfaces expose stored and active values as separate variables.

4.3.1.1 Stored Variables

Stored variables are maintained by the ACMS run-time system on disk, either in the ACMSGEN file or as part of an ADB or TDB file. For example, mss_maxobj is a run-time variable that is stored in the ACMSGEN file. The auditing state for a particular application is a run-time variable that is stored in the application database (ADB).

As you might expect, the ACMS Remote Manager allows ACMSGEN stored values to be modified, but it does not allow modifications to values that are stored in application executables.

Changes to stored values are durable but not dynamic. That is, if the stored value of a variable is modified, the value survives the restart of the ACMS run-time system. However, changes to stored values do not take effect immediately. Some or all of the ACMS run-time system needs to be restarted before the new value takes effect.

For example, to change the value of the mss_net_retry_timer parameter in the ACMSGEN file using ACMSMGR, use the following command:

$ ACMSMGR SET ACC/MSS_NET_RETRY_TIMER=50/STORED

To change the value in ACMSGEN file using the RPC interface, set the mss_net_retry_timer_stored field in the acc_config_rec using the ACMSMGMT_SET_ACC procedure. To change the same value using an SNMP console, set the acc_mss_net_retry_timer_stored field in the ACC Table.

Note that none of these changes would effect the running system. To effect the running system, you must change the active value (see Section 4.3.1.2.)

4.3.1.2 Active Variables

Active variables are maintained in memory by the ACMS run-time system. All Configuration class variables are active because they have an in-memory value. Although the ACMS Remote Manager allows most active values to be modified, not all changes to active values are dynamic. Refer to Chapter 8 to determine whether a particular active value is dynamic. Changes to nondynamic active variables are essentially useless.

Changes to active values are never durable; that is, they never survive a restart of the system.

For example, to change the active value of the mss_net_retry_timer using ACMSMGR, use the following command:

$ ACMSMGR SET ACC/MSS_NET_RETRY_TIMER=50/ACTIVE

To change the value using the RPC interface, set the mss_net_retry_timer_active field in the acc_config_rec using the ACMSMGMT_SET_ACC procedure. To change the same value using an SNMP console, set the acc_mss_net_retry_timer_active field in the ACC table.

Note that none of these changes would survive a system restart. To change a value and have it survive a system restart, you have to change the stored value (see Section 4.3.1.1.)

4.3.2 How the Remote Manager Makes Changes

The ACMS Remote Manager applies changes to the ACMS run-time system either by using the ACMSGEN parameter file and utility, or through the ACMSOPER utility. In either case, the ACMS Remote Manager server applies updates to the running system by creating temporary command procedures that are executed by a spawned DCL subprocess (process name ACMS$MGMT_DCL).

The temporary command procedures are written to and read from the directory pointed to by the logical name ACMS$MGMT_TEMP. If this logical is not defined when the Remote Manager starts, it will define the logical to point to SYS$MANAGER.

Temporary command procedures are given names unique to the procedure instance that creates them, but the names are not unique across nodes. These names are deleted after they have been executed.

If the Remote Manager server does not have access to the directory pointed to by ACMS$MGMT_TEMP, all update attempts fail. However, the definition of the logical can be changed without restarting the Remote Manager. Changing the definition at run time should be done cautiously. One or more updates could fail if the logical is changed in the middle of an update operation.

If the ACMSMGR or RPC interface is used, any errors that occur during the system update are returned to the user and are written to the Remote Manager log file.¹ Depending on the current setting of the dcl_audit_level parameter, some messages may not be written to the log.

User accounts (including proxy accounts and the ACMS$SNMP account, if SNMP is being used) must be granted the ACMS$MGMT_WRITE or ACMS$MGMT_OPERATE rights identifier in order to modify Configuration class values. See Section 3.4.2 for a list of functions and the rights identifier required for each.