Reference Guide

implementation of new system administration policies easier across many existing systems that require re-
configuration.
A similar scenario is used to populate a large number of newly acquired systems with detailed asset information. Much
of the information are the same, such as the manufacturer or lessor of the system, whether support for the system is
outsourced, name of the company providing insurance for the system, method of depreciation, and so on. Any variable
that is common to all systems is scripted, sent to all managed systems, and executed. Asset information that is unique to
a system is scripted as a group and sent to that managed node for execution. For example, a script could specify values
for all unique variables such as the owner, primary user phone number, asset tag, and so on. Scripts to populate unique
values would set all unique variables at once rather than one by one through the system's command line.
In many cases, the CLI allows a user with a very well-defined task in mind to retrieve information about the system
rapidly. If a user wants to review a comprehensive summary of all system components and save that summary
information to a file for comparison with later system states, the CLI is ideal.
Using CLI commands, administrators can write batch programs or scripts to execute at specific times. When these
programs are executed, they can capture reports on components of interest, such as fan RPMs during periods of
highest system usage compared with the same measurements at times of lowest system usage. Command results are
routed to a file for later analysis. Reports can help administrators gain information that are used to adjust usage
patterns, to justify purchasing new system resources, or to focus on the health of a problem component.
Command Syntax Overview
Commands vary in complexity. The simplest command has only command level 1. The omhelp command is a simple
command. When you type omhelp, a list of the main CLI commands is displayed.
The next level of complexity includes commands that contain command levels 1 and 2. All of the about commands are
examples of command level 2 complexity. The omconfig about and omreport about commands display a very brief
summary. The summary shows version information for the systems management software installed on the system; for
example, Server Administrator 1. x .
Some commands have command level 1 and command level 2 and one name=value pair. Consider the following example
command that instructs Server Administrator for more details about the environment for Server Administrator:
omreport about details=true
In this example, command level 1 is omreport, command level 2 is about, and the name= value pair is details=true.
Many commands use command level 1, command level 2, and command level 3, but do not require any parameters
(name=value pairs). Most omreport commands are of this type. For example, the following command displays a list of
alert actions that are configured for components on a system.
omreport system alertaction
The most complex commands have all three command levels and can have multiple name=value pairs. The following is
an example of two name=value pairs:
omconfig system assetinfo info=depreciation duration=3
The following is an example of nine name=value pairs:
omconfig system assetinfo info=acquisition purchasecost=<n> waybill=<n>
installdate=<mmddyy> purchasedate=<mmddyy> ponum=<n> signauth=<text>
expensed=<yes>|no> costcenter=<text>
In each chapter of this document, command syntax and other information about the commands are formatted using any
of the following fields as appropriate:
command level 1
command level 2 command level 3 name=value pair 1 name=value pair 2
15