HP OpenVMS Systems Documentation
Compaq ACMS for OpenVMS
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:
Use the ACMSCFG SHOW PARAMETER command to determine the current value of the parameter in the configuration file:
$ ACMSCFG SHOW PARAMETER
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:
Use the ACMSMGR SHOW PARAMETER command to determine the current value of the parameter in the configuration file:
$ ACMSMGR SHOW PARAMETER
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.
|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.
|Auditing Level||Integer Value|
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.
|Info, Warn, Error||7|
|Info, Warn, Fatal||B|
|Info, Error, Fatal||D|
|Warn, Error, Fatal||E|
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
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
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.
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
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.
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:
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.
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.
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.
Weighting does not apply to data snapshot collections. Data is written for each row in the Collection table that is eligible for snapshots (with both storage_state and coll_state ENABLED).
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.
22.214.171.124 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.
ACMSCFG ADD COLLECTION /ENTITY=entity /CLASS=class /NAME=name /COLL_STATE=state
ACMSCFG SET COLLECTION /ENTITY=entity /CLASS=class /NAME=name /COLL_STATE=state
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.
ACMSCFG SHOW COLLECTION
You cannot use the ACMSCFG utility to add, delete, or modify Collection and Identification class records.