| Previous | Contents | Index |
Data snapshot files grow in proportion to the data that is written to them. The more collection information that is being stored, and the more entities and classes that are part of those collections, the larger the files will grow. As a result, it is important for systems managers to periodically check the size of the data snapshot files to ensure that there is sufficient disk space.
Data snapshot files are indexed RMS files, and when closed, you can manage them using standard OpenVMS file utilities and commands. However, while they are open (either being written to by active snapshots or being read by the ACMSSNAP utility) you cannot copy, rename, move, or delete the files.
To close an open snapshot file, you must stop all Remote Manager
snapshot threads and ACMSSNAP utility processes that are accessing the
file. To stop a snapshot thread, either set the storage_state field to
DISABLED or delete the related row in the Collection table. Note that
setting the coll_state field to DISABLED prevents data from being
written to the snapshot file but does not stop the snapshot thread nor
close the file.
5.4 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 9 lists
all Configuration class variables by entity and indicates which ones
can be modified.
5.4.1 Types of Variables
Many Configuration class variables can have the following two forms:
The programming interfaces expose stored and active values as separate
variables.
5.4.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 5.4.1.2.)
5.4.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 9 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 5.4.1.1.)
5.4.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.1 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 4.4.2 for a list of functions and the rights
identifier required for each.
5.4.3 Using ACMSMGR to Modify the ACMS Run-Time System
The ACMSMGR utility can be used to dynamically modify Configuration class parameters for ACMS run-time entities. More than one value can be modified at once, on one or more nodes. The command executes synchronously; that is, it does not complete until an attempt has been made to update all parameters. Multiple node updates are processed serially; all updates are performed on one node before any updates are attempted on subsequent nodes.
Use the ACMSMGR SET command to modify a Configuration class variable. The syntax of the command is as follows:
ACMSMGR SET entity [/parameter=value,...] |
For example, the following command disables ACMS auditing on the node specified by ACC:
$ ACMSMGR SET ACC /AUDIT_STATE=DISABLED |
Two qualifiers are provided to control whether the active (/ACTIVE) or stored (/STORED) value of a variable is to be modified. One qualifier can be specified in a single command. For example, to modify both the active and stored values of the ACC Configuration class variable node_name, separate commands must be issued, as follows:
$ ACMSMGR SET ACC/NODE_NAME=SPARKS/ACTIVE $ ACMSMGR SET ACC/NODE_NAME=SPARKS/STORED |
If a specified qualifier does not apply (for example, /ACTIVE is specified for a nondynamic variable), a warning message is displayed. For a complete list of Configuration class variables, see Chapter 9.
The ACMSMGR START and STOP commands can be used to dynamically start and stop the following processes:
In addition, ACMS procedure servers can be replaced (stopped and
restarted) using the ACMSMGR REPLACE command. Different qualifiers are
available for each command and process. For more information about
ACMSMGR commands, refer to Chapter 11.
5.4.4 Using SNMP to Modify the ACMS Run-Time System
The SNMP interface can be used to dynamically modify Configuration class parameters for ACMS run-time entities. Updates to Configuration class parameters are synchronous; the SNMP command does not complete until an attempt has been made to update the parameter.
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 Configuration class parameters.
There are both active and stored values for many of the Configuration class variables. In the ACMS MIB, each value is given a separate variable (OID).
Because the SNMP protocol offers only GET and SET commands, the SNMP interface handles the following operations differently from the RPC interface in order to perform the full range of management activities:
Not all operations that can be performed by the RPC interface can be
performed by the SNMP interface. The following sections indicate which
operations are not available in the SNMP interface.
5.4.4.1 Starting and Stopping Processes Using SNMP
To start or stop the following ACMS processes, issue an SNMP SET command on the Configuration class variable acms_state, and specify the state as either 1 (to start the process) or 0 (to stop the process).
You cannot start or stop CP processes.
To start an ACMS application, issue an SNMP SET command on the exc-appl-name field in the excTable, specifying a row that is not currently in use and that is less than the value of the acc-max-appl-active field in the accTable.
To stop an ACMS application, issue an SNMP SET command on the exc-acms-state field, specifying a value of 0.
You cannot start or stop application procedure servers or task groups.
5.4.4.2 Adding and Deleting Rows Using SNMP
Currently, no tables allow rows to be added using SNMP.
The Collection, Error Filter, and Trap tables allow rows to be deleted using SNMP.
To replace an ACMS application procedure server, issue an SNMP SET
command on the ser-replace-flag field in the Server table, specifying a
nonzero value.
5.4.5 Using ONC RPC to Modify the ACMS Run-Time System
The RPC interface can be used to dynamically modify Configuration class parameters for ACMS run-time entities. Configuration class parameter updates are synchronous; the RPC command does not complete until an attempt has been made to update the parameter.
There are both active and stored values for many of the Configuration class variables. In the ACMSMGMT_RPC.X IDL file, each value is given a separate variable.
Separate RPC commands for each entity type are provided for modifying Configuration class variables. In addition, RPC commands are provided to perform start, stop, add, delete, replace, and reset functions. Chapter 8 provides details about all of the RPC commands.
1 Log file entries are filtered by trace level, which is configured using the audit level parameters in the Remote Manager Parameter table (see Section 4.7). |
The Remote Manager collects, consolidates, and stores informational messages generated by all ACMS processes in an error log. This log assists in troubleshooting and system management by providing a single, comprehensive view of error information across multiple ACMS nodes.
The error log contains all messages generated by ACMS processes and applications at run-time. The log is stored in a location determined by the logical name ACMS$MGMT_ERR_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.
The ACMSMGR utility enables you to filter the entries written to this
log, as well as display and manage the current contents of the log.
5.5.1 Setting Error Filters
Error filters are used to limit the amount of error messages that are sent to the Remote Manager. If an ACMS run-time process generates an error contained in an error filter record, the message is not sent to the Remote Manager or subsequently written to the error log.
Error filter records are durably stored by the ACMS run-time system on the target server node. Once specified, the filter records remain in place until explicity deleted (using the ACMSMGR DELETE FILTER command).
Stored in the Error Filter table, each error filter record consists of the target server node, name of the Remote Manager user, and one of the following:
Use the ACMSMGR ADD FILTER command to insert single records in the Error Filter table or create multiple records using an error filter file. The following example shows how to add a single error filter record for the node SPARKS:
$ ACMSMGR ADD FILTER/NAME="ACMSACC-I-QTI_STOPPING"/NODE=SPARKS |
To load multiple records with an error filter file, create an ASCII file that contains a one-column list of symbolic names, code equivalents, or a combination of both preceded with the filter file header string. For example:
%%ACMS Filter File V1.00 ACMSEXC-E-NO_TDB ACMSACC-I-QTI_STOPPING %xFDBC78 . . . |
You can then use the ACMSMGR ADD FILTER command to load the error filter file entries, as follows:
$ ACMSMGR ADD FILTER/FILE=DISK$1:[ACMS.ERROR]FILTER.DAT/NODE=SPARKS |
The Remote Manager process on the server node must have access to the error filter file in order for the file to be loaded into the Remote Manager tables. |
Certain system messages, such as event flags (ACMSACC-I-EVENT), often
spawn further status messages indicating the cause of the event
(ACMSACC-W-FORCEOUT). Error filtering is explicit; that is, only the
specified messages are suppressed. If you want to filter the initial
and subsequent system messages, you must add each message to the Error
Filter table.
5.5.1.2 Displaying Error Filter Records
To display existing filter records, use the ACMSMGR SHOW FILTER command. This command lists all the filter records for a particular node and displays both their symbolic name and code equivalent. The following example shows all the filter records for node SPARKS:
$ ACMSMGR SHOW FILTER/NODE=SPARKS ACMS Remote Management -- Command line utility ACMS V4.4-0 ACMS Error Filter Table Display Time: 20-APR-2001 11:39:31.13 Node Filtered Message Name (Code) sparks ACMSACC-W-AUDSYSSTARTS ( FD8748) sparks SYSTEM-W-TOOMUCHDATA ( 298) sparks SYSTEM-W-NOMOREREG ( AE8) |
You can create an error filter file from existing records using the ACMSMGR SAVE FILTER command. This feature can be used to distribute the same set of error filters across separate nodes in a cluster. For example, the following command saves the current set of error filter records on node SPARKS to a file on node VLCROW:
$ ACMSMGR SAVE FILTER/FILE=VLCROW::DISK$1:[ACMS.ERROR]FILTER.DAT/NODE=SPARKS |
Error filter records remain in effect until deleted. Use the ACMSMGR to delete an error filter record, as follows:
$ ACMSMGR DELETE FILTER/CODE="%xFDBC78"/NODE=SPARKS |
Use the ACMSMGR SHOW ERROR command to display messages from the error log. This command accepts a number of qualifiers, including a qualifier that identifies the node from which to get error messages (/NODE) and a qualifier that specifies the beginning time of messages to display (/SINCE).
The following example shows how to display error messages from the node SPARKS:
$ ACMSMGR SHOW ERROR/NODE=SPARKS |
You can display error 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 ERROR command using the /LOCAL qualifier.
The following example shows how to display error messages on the current node when the Remote Manager process is not running:
$ ACMSMGR SHOW ERROR/LOCAL |
For a complete description of the ACMSMGR commands and qualifiers, see
Chapter 11.
5.5.3 Resetting the Error Log
Use the ACMSMGR RESET ERROR command to close the current error 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 ERROR/NODE=SPARKS |
| Previous | Next | Contents | Index |