Before you begin, you must have already installed the ACMS kit on your system. Also ensure that you have the minimum supported version of TCP/IP installed on your node, and that it is operational. If TCP/IP is not installed and operational, the ACMS Remote Manager will not run. For information about TCP/IP setup, see Section 2.2, ''TCP/IP Setup''.

Server nodes are automatically client nodes. Therefore, you do not need to perform the tasks in Section 2.1.2, ''Client Node Setup'' for nodes that you set up as server nodes.

$ @SYS$STARTUP:ACMS$MGMT_ENV.COM

All ACMS Remote Manager client nodes require that TCP/IP be installed and operational. For information about TCP/IP setup, refer to Section 2.2, ''TCP/IP Setup''. Other than TCP/IP connectivity to the server node, no additional TCP/IP setup is required. The Portmapper does not need to be running on the client node.

The following sections describe how to set up an ACMS Remote Manager client node. You can skip these sections if you are installing the ACMS Remote Mangement server; server nodes are automatically client nodes.

Once you have completed these tasks, you can try to communicate with a Remote Manager on a server node using the procedure in Section 2.1.3, ''Communicate with the Remote Manager''.

Note that you cannot obtain ACMS system management information or perform system management functions on nodes that are client nodes only. Client nodes can get information from and perform operations on server nodes only.

Perform this task if the Portmapper has not previously been set up on the node you are using, or if it has been set up incorrectly.

$ TCPIP TCPIP> SHOW SERVICE PORTMAPPER

Service             Port  Proto    Process       Address   State

PORTMAPPER           111  TCP,UDP  TCPIP$PORTM   0.0.0.0   Enabled

$ TCPIP TCPIP> SET NOSERVICE PORTMAPPER

$ @SYS$STARTUP:TCPIP$SHUTDOWN
$ @SYS$STARTUP:TCPIP$STARTUP

$ @SYS$MANAGER:TCPIP$CONFIG

  VSI TCP/IP Services for OpenVMS Configuration Menu

  Configuration options:

           1  -  Core environment
           2  -  Client components
           3  -  Server components
           4  -  Optional components
           5  -  Shutdown VSI TCP/IP Services for OpenVMS
           6  -  Startup VSI TCP/IP Services for OpenVMS
           7  -  Run tests

           A  -  Configure options 1 - 4
          [E] -  Exit configuration procedure

  Enter configuration option: 3


  VSI TCP/IP Services for OpenVMS SERVER Components Configuration Menu

  Configuration options:
           1  -  BIND           Disabled
           2  -  BOOTP          Disabled
           3  -  TFTP           Disabled
           4  -  FTP            Enabled
           5  -  LPR/LPD        Disabled
           6  -  NFS            Disabled
           7  -  PC-NFS         Disabled
           8  -  PORTMAPPER     Enabled
           9  -  TELNET/RLOGIN  Enabled
          10  -  SNMP           Enabled
          11  -  NTP            Disabled
          12  -  METRIC         Disabled
          13  -  POP            Disabled
          14  -  FINGER         Disabled
          15  -  RMT            Disabled
          16  -  LBROKER        Disabled
          17  -  DHCP           Disabled
           A  -  Configure options 1 - 17
          [E] -  Exit menu

  Enter configuration option: 8


  PORTMAPPER SERVER configuration options:

         1 - Enable service on all nodes
         2 - Enable service on this node

         E - Exit PORTMAPPER configuration

  Enter configuration option: 2

$ @SYS$STARTUP:TCPIP$SHUTDOWN
$ @SYS$STARTUP:TCPIP$STARTUP

Perform this task if SNMP is not set up on the node you are using, or if SNMP is set up incorrectly.

$ TCPIP TCPIP> SHOW SERVICES

Service   Port  Proto   Process      Address    State

...
ESNMP      242  UDP     ESNMP        0.0.0.0    Disabled
SNMP       161  UDP     TCPIP$SNMP   0.0.0.0    Enabled
...

$ TCPIP TCPIP> SET NOSERVICE SNMP

TCPIP> SET NOSERVICE ESNMP

$ @SYS$STARTUP:TCPIP$SNMP_SHUTDOWN
$ @SYS$STARTUP:TCPIP$SNMP_STARTUP

$ @SYS$MANAGER:TCPIP$CONFIG

  VSI TCP/IP Services for OpenVMS Configuration Menu

  Configuration options:

           1  -  Core environment
           2  -  Client components
           3  -  Server components
           4  -  Optional components
           5  -  Shutdown VSI TCP/IP Services for OpenVMS
           6  -  Startup VSI TCP/IP Services for OpenVMS
           7  -  Run tests

           A  -  Configure options 1 - 4
          [E] -  Exit configuration procedure

  Enter configuration option: 3


  VSI TCP/IP Services for OpenVMS SERVER Components Configuration Menu

  Configuration options:
           1  -  BIND           Disabled
           2  -  BOOTP          Disabled
           3  -  TFTP           Disabled
           4  -  FTP            Enabled
           5  -  LPR/LPD        Disabled
           6  -  NFS            Disabled
           7  -  PC-NFS         Disabled
           8  -  PORTMAPPER     Enabled
           9  -  TELNET/RLOGIN  Enabled
          10  -  SNMP           Enabled
          11  -  NTP            Disabled
          12  -  METRIC         Disabled
          13  -  POP            Disabled
          14  -  FINGER         Disabled
          15  -  RMT            Disabled
          16  -  LBROKER        Disabled
          17  -  DHCP           Disabled
           A  -  Configure options 1 - 17
          [E] -  Exit menu

  Enter configuration option: 10


  SNMP SERVER configuration options:

         1 - Enable service on all nodes
         2 - Enable service on this node

         E - Exit PORTMAPPER configuration

  Enter configuration option: 2

  Do you want to provide the public community [Y]: <site dependent>
  Do you want to provide another community [N]: <site dependent>
  Enter contact person(s): <site administrator>
  Enter the location of the system: <site location>

$ TCPIP
TCPIP> SET CONFIG SNMP/COMMUNITY="PUBLIC"/TYPE=WRITE
TCPIP> SET CONFIG SNMP/COMMUNITY="PUBLIC"/TYPE=TRAP
TCPIP> SET CONFIG SNMP/FLAGS=SETS

$ @SYS$STARTUP:TCPIP$SHUTDOWN
$ @SYS$STARTUP:TCPIP$STARTUP

 $ SNMPGET :== $SYS$SYSTEM:TCPIP$SNMP_REQUEST
<your node name> PUBLIC GET -W 20 $ SNMPSET :== $SYS$SYSTEM:TCPIP$SNMP_REQUEST
<your node name> PUBLIC SET -W 20

$ SNMPGET 1.3.6.1.4.1.36.2.18.48.5.1.10.1
1.3.6.1.4.1.36.2.18.48.5.1.10 = 14

$ SNMPSET 1.3.6.1.4.1.36.2.18.48.5.1.10.1 -I 15
1.3.6.1.4.1.36.2.18.48.5.1.10 = 15

Both of these procedures are required to start and run the ACMS Remote Manager successfully.

In addition, the postinstallation procedure modifies ACMSTART.COM to execute ACMS$MGMT_SETUP.COM to ensure that important logicals are defined whenever the ACMS run-time system is started.

$ @SYS$STARTUP:ACMS_POST_INSTALL

Do you want to SETUP and CONFIGURE the ACMS Remote System Manager [Y]?

Do you want to allow Proxy Authorization [Y]?

All clients must be authenticated and authorized to access the ACMS Remote Manager. Proxy access allows ACMS proxies to be used for this purpose. Proxy access is described in detail in Section 4.4.1.2, ''Proxy Accounts''.

(ACMS$MGMT_CONFIG) Enter the file specification for the configuration
   file used by the ACMS Remote Manager
Equivalence string [ SYS$SPECIFIC:[SYSEXE]ACMS$MGMT_CONFIG.ACM ]:

The configuration file contains the default startup configuration for both ACMS data collections and the Remote Manager. Section 4.2, ''Configuring Remote Manager Startup'' describes how to use the ACMSCFG utility to manage this file. The default location is SYS$SYSROOT:[SYSEXE]ACMS$MGMT_CONFIG.ACM. The information in this file is not node dependent; however, you may choose to configure the nodes in your cluster differently. If you configure all nodes in the cluster the same, you can put this file in the cluster common root. Otherwise, the default value places it in the node-specific root.

(ACMS$MGMT_TEMP) Enter the directory where the temp command procedures
   will be created
Equivalence string [ SYS$SPECIFIC:[SYSMGR] ]:

The Remote Manager uses temporary command procedures (see Section 5.3.2, ''How the Remote Manager Makes Changes'' to update the ACMS run-time system. The default location of the command procedures is SYS$MANAGER. This directory should not be a cluster common directory.

(ACMS$MGMT_LOG) Enter the directory for the ACMS Remote Manager's Log file
Equivalence string [ SYS$SPECIFIC:[ACMS_RM.LOG] ]:

The Remote Manager log file (described in Section 4.7, ''Managing Log Files'' contains a variety of messages generated by the Remote Manager at run time. The default location of the audit log is SYS$SYSROOT:[ACMS_RM.LOG]ACMS$MGMT_LOG.LOG. If you choose to place this log in a cluster common directory, be sure that the file name is different for each node.

(ACMS$MGMT_CREDS_DIR) Enter the directory for the ACMS Remote Manager
Credential's Equivalence string [ SYS$SPECIFIC:[ACMS_RM.CREDS] ]:

Client credential files (described in Section 4.4.1.1, ''Logging In'' contain encrypted client identity information used for client authorization. The default location for these files is SYS$SYSROOT:[ACMS_RM.CREDS]. Credential files are created with unique names and can be safely placed in a cluster common directory.

 Please enter the UIC for the ACMS$SNMP account, in the form [ggggg,nnnnnn]  UIC:

Please enter a password of at least 8 characters, using only
the following characters: ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789$_

Password:

The password for this account is never used. Enter any combination of the characters shown. However, keep in mind that you will be prompted to verify whatever you type.

After you run the postinstallation procedure, you should rerun SYS$STARTUP:ACMSTART.COM to ensure that the newly created ACMS$MGMT_SETUP.COM is run.

The ACMS$MGMT_CONFIG system logical points to the configuration file. This logical is defined in the ACMS$MGMT_SETUP.COM procedure, which is executed by the ACMSTART.COM procedure. If this logical is not defined, the ACMSCFG utility will not be able to locate the file. If you have not already run ACMSTART.COM, do so before issuing any ACMSCFG commands.

The ACMS_POST_INSTALL.COM procedure creates a configuration file with default values in SYS$SYSROOT:[SYSEXE]ACMS$MGMT_CONFIG.ACM.

The configuration file contains the startup configuration for ACMS data collections and provides many defaults for the Remote Manager. Section 4.2, ''Configuring Remote Manager Startup'' describes how to use the ACMSCFG utility to manage this file.

$ STARTMGR

$ @SYS$STARTUP:ACMS$MGMT_STARTUP

$ SHOW SYSTEM/PROCESS=ACMS$MGMT_SVR

If this process is not running, refer to Section 2.4, ''Troubleshooting the ACMS Remote Manager Startup''.

The Remote Manager web agent software is bundled with the ACMS for OpenVMS Alpha Run-time and Development kits. To install the web agent software, choose to install the WBEM-related files component of either kit.

This section contains excerpts from an ACMS Development kit installation. Refer to the VSI ACMS Version 5.0 for OpenVMS Installation Guide for detailed information about the entire ACMS installation procedure.

If you have not already installed the VSI Management Agents for OpenVMS software, do so now. You can download this software from the web page listed in Section 3.1, ''Overview of the Remote Manager Web Agent''.

Follow the associated instructions to copy, unpack, and install the appropriate VSI Management Agents for OpenVMS PCSI kit. Once the software is installed, issue the following command to start the management agent process:

$ SET DEFAULT SYS$SPECIFIC:[WBEM]
$ @WBEM$RUN_WEBSERVER.COM

Note that the WBEM server (WBEM$SERVER) is the only process started by this procedure. None of the other Management Information Base (MIB) processes included in the WBEM kit (such as WBEM$CPQHOST) are used by the Remote Manager agent. If you plan to use software on this system that relies on the MIB processes, run the WBEM$STARTUP.COM procedure, as described in the WBEM installation material.

The installation procedure automatically grants the ACMS$MGMT_READ rights identifier to the ACMS$WBEM account when it is created. This enables all SHOW commands to be executed from the web agent. In order to enable all other non-read operations (such as SAVE, SET, START, STOP, RESET, ADD, and DELETE), grant one or more of the following rights identifiers to the ACMS$WBEM account:

See Section 4.4.2, ''Authorization'' for more information on the use of rights identifiers.

Enter the following command to start the Remote Manager web agent process where queue-name is a valid OpenVMS batch queue:

$ SUBMIT/NOTIFY/LOG=SYS$SYSROOT:[WBEM]/QUEUE=queue-name -
_$ /USER=ACMS$WBEM SYS$SPECIFIC:[WBEM]RUN_ACMS_HMMO.COM

If the process is already running, this command restarts the process.

In order for the Remote Manager web agent to access a Remote Manager server system, the logical ACMS$MGMT_ALLOW_PROXY_ACCESS on the host system must be set to a value of 1, which enables proxy access.

Also, an ACMS proxy entry for the ACMS$WBEM account is required. For example, the following proxy entry grants the user ACMS$WBEM access to the local host from any known system:

$ MCR ACMSUDU
UDU>SHOW /PROXY *::ACMS$WBEM
Remote User: *::ACMS$WBEM                   Local User: ACMS$WBEM

The rights identifiers on the local ACMS$WBEM account control the level of access allowed on the host system.

Use the following command to stop the web agent process:

$ @SYS$SPECIFIC:[WBEM]STOP_ACMS_HMMO.COM

If you also want to stop the WBEM server process, enter the following command:

$ @SYS$SPECIFIC:[WBEM]WBEM$STOP_WEBSERVER.COM

From a browser on the web client system, enter the following URL to connect to the web server system where server-host represents the address of the OpenVMS Alpha system on which the web agent software is running:

http://server-host:2301/acmshmmo/eng/acms_index.html

This address can be expressed in any of the following forms:

node (node name)
node.company.com (URL)
165.112.94.78 (IP address)

The ACMS Remote Management page is displayed, similar to the figure below.

This page consists of the following frames:

The web agent uses color and font highlighting to indicate the different states and types of data displayed in the output frame. The default conventions are described in the table below. Note, however, that you can change these conventions as described in the following section.

The Remote Management web page relies on a cascading style sheet (CSS) to manage its formatting. Based on the CSS level 2 specification (CSS2) from the World Wide Web Consortium (W3C), the ACMS.CSS file functions as a template for information displayed in the output frame.

If you are familiar with CSS files, you can customize the formatting of information in the output frame by editing the file ACMS.CSS located in SYS$SYSROOT:[WBEM.WEB.IM.ACMSHMMO.ENG].

For example, to remove the background image in the output frame, open the CSS file and search for the following statement:

BODY {background-color: white; background-image:
url(/acmshmmo/images/webbum.gif); color: black;}

Replace this statement with the following:

BODY {background-color: white; color: black;}

To learn more about CSS files or the CSS2 specification, visit the W3C web site for the latest information and resource listings:

http://www.w3.org/Style/CSS

When you first access the ACMS Remote Management web page, the name of the web server is displayed as the Remote Manager host.

To choose a different Remote Manager host, click the Change button in the command selection frame. The Select Host popup window is displayed, similar to the figure below.

Enter the name of the Remote Manager host, and click OK. Note that if you enter a URL or IP address, only the short form of the name is displayed in the command selection frame.

To display information about an ACMS entity or object:

To change information related to an ACMS entity or Remote Manager object:

Note that you can update the values displayed in the output frame at any time by clicking the Refresh button.

To start or stop an ACMS object, such as an application (EXC):

To add or delete a Remote Manager object, such as an error filter:

If the ACMS$MGMT_HMMO process crashes, the following files will contain any error information that was available: SYS$SPECIFIC:[WBEM]ACMS$MGMT_ HMMO.LOG;* SYS$SPECIFIC:[WBEM]ACMS$MGMT_HMMO.ERR;*.

If there are any new dump files, you may want to examine the file to locate the problem source: SYS$SPECIFIC:[WBEM]*.DMP;*.

If the problem is with WBEM$SERVER process, send the dump file to your VSI support representative. If the problem is with the ACMS HMMO process, please have the following files ready for analysis in addition to a procedure that reproduces the situation:

SYS$SPECIFIC:[WBEM]ACMS$MGMT_HMMO.LOG;*

SYS$SPECIFIC:[WBEM]ACMS$MGMT_HMMO.ERR;*

SYS$SPECIFIC:[WBEM]*.html;*

SYS$SPECIFIC:[WBEM]*.txt;*

SYS$SPECIFIC:[WBEM]SYS$OUTPUT.*;

SYS$SPECIFIC:[WBEM]*.DMP;*

ACMSCFG verb object qualifier

$ ACMSCFG SHOW COLLECTION

$ ACMSCFG HELP

$ MYCOMMAND :== $SYS$SYSTEM:ACMS$MGMT_CONFIG_CMD

If you do this, you would substitute MYCOMMAND for ACMSCFG in the preceding examples.

When the ACMSCFG utility is started, it attempts to locate the ACMS$MGMT_CONFIG.ACM file by translating the logical name ACMS$MGMT_CONFIG. If that attempt fails, it looks in the default location, SYS$SYSTEM:ACMS$MGMT_CONFIG. If that lookup fails, ACMSCFG asks the user whether to create a new file. New files are created with default values in the directory that the logical name ACMS$MGMT_CONFIG translates to. If the logical name is not defined or does not include a directory specification, the default directory location is the current directory.

ACMSCFG SHOW object

The values for each object type correspond directly to fields in management configuration tables. These tables are discussed in Chapter 9, "Remote Manager Reference Tables".

SPARKS> ACMSCFG SHOW COLLECTION

Entity                Collect Collect                      Storage  Storage
Type    Entity Name   Class   State     Storage Location   State    Interval
------- ------------- ------- --------- ------------------ -------- ---------
 *      *             id       enabled  acms$mgmt_snapshot enabled  3600
 *      *             config   enabled  acms$mgmt_snapshot disabled 3600
 *      *             error    enabled  acms$mgmt_snapshot disabled 300

Each object has unique qualifiers that determine which values are to change. Qualifiers are either mandatory or optional. Mandatory qualifiers have no default and must be specified by the user. Optional qualifiers have default values and do not have to be specified. See Chapter 10, "ACMSCFG Commands" for a complete description of the syntax for each command and the qualifiers they support.

$ @SYS$STARTUP:ACMS$MGMT_STARTUP

You should run this file from the SYSTEM account during system startup. You can run the file either before or after the ACMS run-time system has been started. Alternatively, you can run it at any time from a privileged account.

During process startup, the Remote Manager reads the ACMSCFG file (located in SYS$SYSTEM:ACMS$MGMT_CONFIG.ACM or wherever the ACMS$MGMT_CONFIG logical points). If the file cannot be found and opened, the Remote Manager will not start.

$ ACMSMGR SHOW LOG

$ ACMSMGR SHOW LOG/LOCAL

This command instructs the ACMSMGR utility to read the log file directly, bypassing the Remote Manager. See Chapter 11, "ACMSMGR Commands" for a complete description of the ACMSMGR utility, commands, and command syntax.

$ @SYS$STARTUP:ACMS$MGMT_STARTUP LOG_TO_SYSOUT

The ACMS$MGMT_STARTUP procedure redirects SYS$OUTPUT for the Remote Manager to a file called ACMS$MGMT_SERVER.OUT in the SYS$ERRORLOG directory.

The Remote Manager is stopped using the ACMSMGR STOP MANAGER command, which has the following syntax:

ACMSMGR STOP MANAGER /NODE=node-name

The /NODE qualifier can be omitted if the ACMS$MGMT_SERVER_NODE logical is defined. If the /NODE qualifier is provided, it overrides the ACMS$MGMT_SERVER_NODE logical.

The Remote Manager can be stopped independently of the ACMS run-time system. Stopping the Remote Manager has no effect on the running ACMS system. Note, however, that simply stopping the Remote Manager does not stop any active data collections. Data collections can be stopped only by using ACMSMGR commands, or from an SNMP management console that has access to the Remote Manager.

Note also that prior to issuing this command, the user must either have logged in to the Remote Manager, or the user must have a valid proxy (and proxy access must have been enabled). Regardless of how access is gained, the user must hold the ACMS$MGMT_OPER rights identifier on the node the Remote Manager is running in order to stop it. See Section 4.4, ''Logging In to the Remote Manager'' for a description of how to log in to the Remote Manager.

The ACMSMGR STOP MANAGER command executes asynchronously of the actual shutdown. That is, the command will complete (control will return to the user) before the shutdown has completed.

STOP/ID=pid

Determine the PID of the Remote Manager using the DCL command SHOW SYSTEM, and then look for the process named ACMS$MGMT_SVR.

Authentication can be performed in one of two ways: either through an explicit login (using a valid OpenVMS user name and password) or through a valid ACMS proxy account.

The exception to this rule is SNMP access, which is controlled by the presence of the ACMS$SNMP account in the local rights database. Authentication for external entities that communicate with the Remote Manager through the SNMP protocol is allowed only when a valid OpenVMS account exists for the user ACMS$SNMP. If this account exists and is not disusered, the user is considered to be an authentic user. Authorization for SNMP users is treated the same as for any other user – by OpenVMS rights identifier. See Section 4.4.2, ''Authorization'' for more information about authorization.

All access for an interface can be disabled by disabling the interface itself, either through the ACMSCFG utility prior to management startup, or through the ACMSMGR utility after Remote Manager startup.

The total number of users that can be simultaneously logged in to the Remote Manager (regardless of authentication mechanism) is controlled by the Remote Manager parameter MAX_LOGINS, which can be modified by the Remote Manager. This parameter is not the same as the MAX_LOGINS ACMS system parameter in ACMSGEN. When the number of users currently logged in is equal to the value of this parameter, new logins are rejected until some users have logged out, or until their credentials have expired. You can set the initial value of MAX_LOGINS with the ACMSCFG utility. You can change the value of MAX_LOGINS dynamically (but nondurably) with the ACMSMGR utility.

Attempts to log in to the Remote Manager are recorded in the Remote Manager log file if the security_audit_level parameter is set for informational level logging (any odd value, up to and including F). By default, informational messages are not logged. See Section 4.7.1, ''Setting Audit Levels'' for more information.

$ ACMSMGR SHOW USER

ACMSMGR LOGIN /USER=user-name /PASSWORD=password /NODE=node-name

Use the ACMSCFG utility to configure which interfaces should be enabled or disabled when the Remote Manager starts up. Either the SNMP or RPC interface should always be enabled. If both are disabled, there is no way to communicate with the Remote Manager.

ACMSCFG SET INTERFACE /INTERFACE=interface-name /STATE=state

$ ACMSCFG SHOW INTERFACE

Use the ACMSMGR utility to dynamically enable or disable an interface after the Remote Manager has already been started. As noted previously, at least one of either the SNMP or RPC interfaces should always be enabled. If both are disabled, there is no way to communicate with the Remote Manager (for example, to shut it down or to enable an interface). Changes made with the ACMSMGR interface are not stored in the ACMSCFG file and are lost when the Remote Manager is stopped. Use the ACMSCFG utility to save changes to the ACMSCFG file.

An interface cannot disable itself. Since the ACMSMGR utility uses the RPC interface, it cannot be used to disable the RPC interface. To disable the RPC interface, either use the ACMSCFG utility and restart the Remote Manager, or use the SNMP interface.

ACMSMGR SET INTERFACE /INTERFACE=interface-name /STATE=state

$ ACMSMGR SHOW INTERFACE

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

ACMSCFG SET PARAMETER /parameter-name=value

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

ACMSMGR SET PARAMETER /parameter-name=value

$ ACMSMGR SHOW PARAMETER

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

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

$ ACMSMGR SHOW LOG/LOCAL

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

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.

$ ACMSMGR RESET LOG/NODE=SPARKS

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

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

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 wildcard value `*' is also supported, and for CPs is process name. The asterisk (*) wildcard value is also supported and matches all names.

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 5.1, ''Example 1: Collection with Wildcards'', 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.

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.

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

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.

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

ACMSCFG SHOW COLLECTION

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

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

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

ACMSMGR SHOW COLLECTION

Use the ACMSMGR SHOW command to display collected data. See Chapter 11, "ACMSMGR Commands" for a description of each command.

$ ACMSMGR SHOW ACC /NODE=SPARKS /ID

ACMS Remote Management Option -- Command line utility
ACMS V4.4-0   ACC Table Display                     Time:  19-APR-2001 11:59:09.56


                ID
    Node       Class     PID      Process Name         Start Time        User Name     Version
 ------------ -------- -------- --------------- ----------------------- ------------ ------------
 sparks       enabled  2020C8BB ACMS01ACC001000  18-APR-2001 14:44:47.29 SYSTEM       V4.4-0

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

$ ACMSMGR SET ACC/MSS_NET_RETRY_TIMER=50/STORED

$ ACMSMGR SET ACC/MSS_NET_RETRY_TIMER=50/ACTIVE

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 4.4.2, ''Authorization'' for a list of functions and the rights identifier required for each.

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.

ACMSMGR SET entity [/parameter=value,...]

$ ACMSMGR SET ACC /AUDIT_STATE=DISABLED

$ ACMSMGR SET ACC/NODE_NAME=SPARKS/ACTIVE/STORED

If a specified qualifier does not apply (for example, /ACTIVE is specified for a nondynamic variable), the qualifier is ignored.

For a complete list of Configuration class variables, see Chapter 9, "Remote Manager Reference Tables".

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, "ACMSMGR Commands".

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

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.

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, "Management APIs" provides details about all of the RPC commands.

Data from list calls is returned in a linked list. The example in this section uses the acmsmgmt_list_log_1 procedure to illustrate how linked list processing works.

struct  log_sel_struct {
    int          client_id;
    string       before_time<TIME_SIZE_A>;
    string       since_time<TIME_SIZE_A>;
    string       file_name<STORAGE_LOC_SIZE>;
    int          dup_count;
    int          facility;
    int          severity;
    };

The following example code shows the initialization of the client and the call to the acmsmgmt_list_log_1 procedure:

#include <rpc/rpc.h>
#include <stdio.h>
#include string
#include "acmsmgmt_rpc.h"
CLIENT *cl;
int main ()
{
int skip_rec = 0;
char null_time_str[24] = "";
char first_of_jan[24] = "01-JAN-1998 00:00:00.00";
char file_spec[] = ""; /* use default, i.e. active log file */
char time_cache[MGMT_S_TIME_A+1];
static struct log_sel_struct log_rec;
log_data_list *log;
log_link *nl;
/* Initialize client connection; if that fails, exit*/
cl = clnt_create(sname, ACMSMGMT_RPC, ACMSMGMT_VERSION, "tcp");
if (!cl)
return(MGMT_FAIL);
/* Create a default security context */
cl->cl_auth = authunix_create_default();
/* So far so good. Initialize log selection data */
log_rec.client_id = 0;
log_rec.before_time = null_time_str;
log_rec.since_time = first_of_jan;
log_rec.file_name = file_spec;
log_rec.dup_count = -1;
log_rec.facility = -1; /* don’t match on facility */
log_rec.severity = -1; /* don’t match on severity */
top:
/* Now make RPC */
log = acmsmgmt_list_log_1(&log_rec,cl);

struct log_data_list {
int status;
union {
log_list list;
int rc;
} log_data_list_u;
};

The status field determines which structure is being returned. If the status is equal to MGMT_FAIL, the rc field is returned. The rc field contains a status code indicating the reason for failure.

If the status field is not equal to MGMT_FAIL, a pointer to a linked list has been returned.

typedef struct log_link *log_list;

struct log_link {
        logging_rec log_data;
        log_list pNext;
};

In this structure, log_data is of type logging_rec, which is a record structure containing the log data. The pNext field is a pointer to the next node in the linked list (which is of type log_link).

Figure 6.3, ''Linked List: Return Structure and Construction'' illustrates the return structure and how the linked list is constructed.

/* if a NULL pointer was returned, the RPC failed */
if (!log)
       return(MGMT_FAIL);

/* if bad status was returned, something failed in our call.
        log->log_data_list_u.rc contains the status */
if (log->status == MGMT_FAIL)
        return(log->log_data_list_u.rc);

/* while more data in the list, display the data */
for (nl = log->log_data_list_u.list; nl != NULL; nl = nl->pNext) {
        if (skip_rec)
                skip_rec = 0;
        else
                printf("\n %-12s\t%-s",sname,nl->log_data.log_msg);

        /* save last time received to use as next time to read forward from */
        memcpy(&time_cache[0],nl->log_data.log_msg,23);
        log_rec.dup_count  = nl->log_data.dup_count;
        log_rec.since_time = time_cache;

}
if (log->status == MGMT_NOMORE_DATA)
        printf("\n *** End of data **");
else {
        skip_rec = 1;
        goto top;
}

return(1);
}

In this example, the returned pointer is checked for whether data has been returned (log is not NULL). Then the status code is checked for whether the call completed successfully.

If the call completed successfully, the code drops into a FOR loop and starts printing the data. For this particular call, the client prints all the records the very first time the RPC is called; on subsequent calls, the first record is a duplicate of the last one from the previous call and is not printed.

After printing a record, the key data is saved to be used again on a subsequent call. Remember that only max_rpc_return_recs is returned in each call to the acmsmgmt_list_log_data_1 procedure. There may be more log records than can be sent at once. It is the responsibility of the client to initialize the call properly to get the next set of records.

Once all the returned records have been returned, the code will call the acmsmgmt_list_log_data_1 procedure again if the status code from the call was not MGMT_NOMORE_DATA. In this way, all the records are retrieved.

The following example code shows how a client program calls the acmsmgmt_set_param_1 procedure to change the values of the proc_mon_interval and mss_coll_interval parameters.

int set_param_data(int client_id,CLIENT *cl)
 {
   int x = 0;
   int y = 0;

   static param_config_rec2 set_struct;
   param_status_rec2 *ret_struct;
   static int *status;

   /* initialize input argument; values < 0 are not processed
      by the server */
   memset(&set_struct,-1,sizeof(set_struct));

   /* establish the client id */
   set_struct.client_id = client_id;
   set_struct.params.proc_mon_interval = 60;
   set_struct.params.mss_coll_interval = 60;

   ret_struct = acmsmgmt_set_param_2(&set_struct,cl);

   if (!ret_struct) {
         printf("\nCall to modify parameters failed");
         return(MGMT_FAIL);
   }

   if (ret_struct->status != MGMT_SUCCESS) {

      if (ret_struct->status != MGMT_WARN) {
         printf("\nCall to modify parameters failed, returning %d",
                ret_struct->status);
         status=ret_struct->status;
           xdr_free(xdr_param_status_rec2, ret_struct);
           free(ret_struct);
         return(MGMT_FAIL);
      }

      if (ret_struct->param_status_rec_u.data.proc_mon_interval != MGMT_SUCCESS)
         printf("\n Call to modify proc_mon_interval failed");
      if (ret_struct->param_status_rec_u.data.mss_coll_interval != MGMT_SUCCESS)
         printf("\n Call to modify mss_coll_interval failed");
           xdr_free(xdr_param_status_rec2, ret_struct);
           free(ret_struct);
      return(MGMT_FAIL);
   }
   else
      printf("\n Call to update parameters successful");
        xdr_free(xdr_param_status_rec2, ret_struct);
        free(ret_struct);
      return(0);
}

In this example, note that the input argument (set_struct) is initialized to negative values prior to the call. The Remote Manager will attempt to apply updates for any positive values found; negative values are ignored.

Following the call to the update routine, the return record pointer is tested to ensure that it is not NULL (that is, that the call completed). Then individual return codes are tested to determine the status of the updates. The first status check (ret_rec->status) determines the overall call status. For instance, security violations will be recorded in this field. If that status field contains a failure code, no updates were attempted. If that status field contains MGMT_SUCCESS, updates were attempted for the two fields. The subsequent status checks in the return record determine the outcome of those updates.

The following example code shows how a client program calls the acmsmgmt_delete_collection_1 procedure to remove a collection row.

int del_coll_data(int client_id,CLIENT *cl)
 {

  static int *status;
  static coll_del_rec set_struct;
  static char ent_name[MGMT_S_ENTITY_NAME];

  set_struct.client_id = client_id;
  set_struct.entity_type            = MGMT_ACC;
  strcpy(ent_name,"*");
  set_struct.entity_name            = ent_name;
  set_struct.collection_class       = MGMT_CLASS_ALL;

  status = acmsmgmt_delete_collection_1(&set_struct,cl);

  if (!status) {
     printf("\n Call to delete collection failed");
     return(MGMT_FAIL);
  }

  if (*status != MGMT_SUCCESS) {
        printf("\nCall to delete collection failed with status %d",*status);
        return(MGMT_FAIL);
  }
  else
        printf("\nCall to delete collection was executed");
          free(status)
        return(0);
}

In this example, the input record is prepared with key information, and then the call to delete the row is performed. Following the call to the delete routine, the value pointed by status is checked for success or failure. In either event, a message is printed out indicating the completion status of the call.

The following example code shows how a client program calls the acmsmgmt_add_collection_1 procedure to add a collection row.

int add_collection_data(int client_id,CLIENT *cl)
 {
  static char c_name_all[2]       = "*";
  static coll_config_rec_2 set_struct;
  struct coll_status_rec_2 *status_rec;

  set_struct.client_id              = client_id;
  set_struct.coll.entity_type       = MGMT_ACC;
  set_struct.coll.entity_name       = c_name_all;
  set_struct.coll.collection_class  = MGMT_CLASS_ALL;
  set_struct.coll.collection_state  = MGMT_STATE_ENABLED;

  status_rec = acmsmgmt_add_collection_2(&set_struct,cl);

   if (!status_rec) {
      printf("\n Call to add collection record failed");
      return(MGMT_FAIL);
   }

   if (status_rec->status == MGMT_WARN) {
        printf("\nThe following fields are invalid: ");
        if (status_rec->coll_status_rec_2_u.data_warn.entity_type == MGMT_FAIL)
           printf("\n     entity_type");
        if (status_rec->coll_status_rec_2_u.data_warn.collection_class
            == MGMT_FAIL)
           printf("\n     collection_class");
        if (status_rec->coll_status_rec_2_u.data_warn.collection_state
            == MGMT_FAIL)
           printf("\n     coll_state");
        return(0);
   }
   else if (status_rec->status != MGMT_SUCCESS) {
        printf("\nCall to add collection failed with status",
               status_rec->coll_status_rec_2_u.rc);
          xdr_free(xdr_coll_status_rec_2,status_rec);
          free(status_rec);
        return(0);
   }
   else
        printf("\nCall to add collection was executed");
          xdr_free(xdr_coll_status_rec_2,status_rec);
          free(status_rec);
        return(1);
}

In this example, the input record is prepared with key and data values, and then the call to add the row is performed.

Following the call to the add routine, the return record pointer is tested to ensure that it is not NULL (that is, that the call completed). Then the overall status code (status_rec->status) is checked to determine whether the add was performed.

A status value of MGMT_WARN indicates that some fields were in error, so individual return codes are tested to determine which fields were invalid.

A status value other than MGMT_WARN or MGMT_SUCCESS means a general error occurred. A value of MGMT_SUCCESS means the record was added.

The following example code shows how a client program calls the acmsmgmt_start_acc_1 procedure to start ACMS on a remote node. In this example, the QTI and TSC are started along with the system, and system auditing is enabled.

int start_acc(int client_id,CLIENT *cl)
 {
   dcl_link    *nl;
   static acc_startup_rec start_struct;
   static cmd_output_rec *ret_struct;

   start_struct.client_id = client_id;
   start_struct.audit_sw = 1;
   start_struct.qti_sw  = 1;
   start_struct.terminals_sw  = 1;

   ret_struct = acmsmgmt_start_acc_1(&start_struct,cl);

   if (!ret_struct) {
        printf ("\n Call to start ACMS system failed");
        return(MGMT_FAIL);
   }

   if (ret_struct->status != MGMT_SUCCESS) {

        if (ret_struct->status != MGMT_WARN) {
            printf("\nCall to start ACMS system failed with status %d",
                   ret_struct->status);
              xdr_free(xdr_cmd_output_rec, ret_struct);
              free(ret_struct);
            return(0);
        }

        printf("\n Call to start ACMS system completed with warnings or
               errors");

        for (nl = ret_struct->cmd_output_rec_u.data.cmd_output; nl != NULL;
             nl = nl->pNext)
            printf("\n %s",nl->dcl_msg);
              xdr_free(xdr_cmd_output_rec, ret_struct);
              free(ret_struct);
        return(MGMT_FAIL);
   }
   else {
        printf("\nCall to start ACMS system was executed");
        for (nl = ret_struct->cmd_output_rec_u.data.cmd_output; nl != NULL;
             nl = nl->pNext)
            printf("\n %s",nl->dcl_msg);
   }
        xdr_free(xdr_cmd_output_rec, ret_struct);
        free(ret_struct);
  return(0);
}

In this example, the input record is prepared with qualifier data, and then the call to start the system is performed. Auditing is enabled, and QTI and TSC will be started with the system.

union cmd_output_rec switch (int status) {
    case MGMT_WARN:
        cmd_rec data_warn;
    case MGMT_SUCCESS:
        cmd_rec data;
    case MGMT_FAIL:
        int rc;
    default:
        void;
        };

The status field determines which structure is being returned. If the status is equal to MGMT_FAIL, the rc field is returned. The rc field contains a status code indicating the reason for failure.

If the status field is not equal to MGMT_WARN or MGMT_SUCCESS, a pointer to a linked list has been returned. The linked list contains a text field and a forward pointer. By following the forward pointers, all the records in the list can be retrieved. Section 6.6.1, ''Linked List Example'' illustrates how to follow the linked list.

In either case, the example code prints out the contents of all the strings in the linked list. These strings are status messages returned by ACMSOPER.

The integer and string data types map directly to the SNMP INTEGER and DisplayString data types.

The gauge data type defined for the Remote Manager is not the same as the SNMP Gauge type. In order to avoid confusion, the Remote Manager SNMP interface maps the Remote Manager gauge fields to SNMP INTEGER and DisplayString data types. So for each Remote Manager gauge data type, three fields are defined in the MIB: the current field value, the maximum (or minimum) field value, and the maximum (or minimum) field value time.

acc-current-appls-num            INTEGER, 
acc-current-appls-max            INTEGER, 
acc-current-appls-time           DisplayString

This is the case for all Remote Manager gauge data types. For Remote Manager min gauge data types, there is a -min field instead of a -max field. For both gauge data types, time is expressed in the form DD-MMM-YYYY HH:MM:SS.hh.

Bounds checking need not be performed. However, for Entity tables (ACC, QTI, TSC), both identity and state validation must be performed.

Static tables are sized when the parent process starts and do not change as long as the parent process is running. For each static table, there is a field in the table of the parent process that indicates the upper bound of the static table.

In static tables, table data is not always contiguous and table rows can be reused. The PID field should be used to establish process identity.

Table Row   CP process name   CP PID 
1           ACMS01CP001000    2040013D 
2           ACMS01CP002000    2040013E 
3           ACMS01CP003000    2040013F

Table Row   CP process name   CP PID 
1           ACMS01CP001000    2040013D 
2 
3           ACMS01CP003000    2040013F

An SNMP console searching this table sequentially and stopping when the first error is returned would find only the first CP. Access to the second row would return an error. Therefore, when scanning static tables, it is important to examine all rows of the table before terminating the scan; that is, perform a loop based on the tsc-cp-slots-active field in the TSC table.

Table Row   CP process name   CP PID 
1           ACMS01CP001000    2040013D 
2           ACMS01CP002000    20400140 
3           ACMS01CP003000    2040013F

Table row 2 is now valid again, but a different process occupies it. Therefore, any cached information for table row 2 is invalid and must be refreshed with the data from the new process.

Dynamic tables do not have a fixed upper bound; they grow and shrink as entries are added and removed. However, data in dynamic tables is always contiguous, so there are never invalid rows stored between valid rows. When a row becomes invalid because it is empty or unoccupied, it is removed from the table and the remaining rows are renumbered.

Table row   User Name   Client Id 
1           User1       1 
2           User2       2 
3           User3       3 
4           User4       4

Table row   User Name   Client Id 
1           User1       1 
2           User3       3 
3           User4       4

As with static tables, you must ensure that the table row being accessed has not been reused or renumbered. Among dynamic tables, only the Trap table allows updates. Note that entries are never deleted or modified in the Log table; new entries are always appended to the end.

The Servers and Task Group tables are indexed by a compound index. For both tables, the first key value is the table row of the owning EXC; the second key value is the Server or Task Group row. When fetching or setting Server or Task Group rows, you must first determine the EXC (application) they belong to, and then determine the particular server or task group.

In order to access the ser-server-name field for ServerA in application Appl1, the OID would be 1.3.6.1.4.1.36.2.18.48.14.1.3.1.1 To access the same field for ServerD in Appl2, the OID would be 1.3.6.1.4.1.36.2.18.48.14.1.3.3.2.

There is no way to determine to which task group a server belongs. In contrast, you can always determine from the OID which application a server belongs to because ACMS requires that each server be given a unique name within the application.

The trap parameter EXISTS allows traps to be generated based on whether an ACMS process starts or stops.

Specifying a minimum trap value of 1 for a process specifies, in effect, that a trap should be generated whenever the process stops – that is, when the process existence is less than 1.

Specifying a maximum value of 0 specifies that a trap should be generated whenever the process starts – that is, when the processes existence is greater than 0.

A minimum value of 0 or a maximum value of 1, while valid, is basically useless, since the EXISTS parameter is never greater than 1 or less than 0.

The trap parameter EVENT_SEVERITY allows traps to be generated based on the facility and severity of events being logged to the Remote Manager log. For example, an EVENT_SEVERITY trap can be configured for Remote Manager SNMP events with severity higher than WARNING (such as ERROR or FATAL). Any time a Remote Manager SNMP operation fails with a severity higher than WARNING, an SNMP trap is generated.

Use care when you configure traps so that you do not create unnecessary traps. In general, traps are intended to be used to signal significant events. For instance, specifying a minimum severity of FATAL or ERROR causes all informational and warning messages to generate traps. This is probably not a good use of network or console resources.

$  @SYS$STARTUP:ACMS$MGMT_STARTUP LOG_TO_SYSOUT

$  ACMSMGR SET PARAM/SNMP_AUDIT_LEVEL=F

The SNMP debug output is written to SYS$ERRORLOG:ACMS$MGMT_SERVER.OUT, which is an ASCII file that can be typed or edited.

Table 8.7, ''Severity Codes'' shows the symbolic names for Remote Manager severities.

The table below shows the symbolic names for Remote Manager trap parameters.