4.3.1 Accessing the Operations Interpreter
The command line can be accessed inside AutoNOC by clicking on the OI Command Prompt icon, or, alternatively it can be accessed remotely using a Telnet program that supports half-duplex, and consequently, it can also be accessed by direct socket connection for live querying and analysis. To access the command line remotely via sockets, the user must turn on the Allow OSP Access switch for one of your user accounts to have socket access to the command line as the following screenshot shows:

Once this capability is enabled, the user can access the AutoNOC Open Service Provider command prompt by telnetting to the AutoNOC server on port 34 as the following command shows:

telnet 192.168.1.3 34

Once connected, the user can logon to the command line using the following comand:

logon(username,password)

The following screenshot shows an example logon session:

The command line presents the complete AutoNOC tree of the local portal and all commands are possible, using a standard TCP/IP socket connection.

4.3.2 Scope
The following screenshot shows a simple call to AutoNOC's Ping(...) function; it shows the scope that the expression was fired at; and it shows the response of 0 indicating it is 0 milliseconds to the DRAGON device that the ping was called for.

We have mentioned the term Scope several times and you can see an example of the use of scope in the above screenshot. The scope for the resolution of this expression is /Devices/Dragon. Scope is the path that is currently active for an instance of the interpreter and it effects several things, most notably how variables like %IP are resolved. For a complete discussion of variables, please see 4.2 - Variables.

Every expression when evaluated has a scope. Probe expressions, when evaluated, have the scope of the probe.

To open up an interpreter window, click on a device, probe, or template in the Design tab and click on the menu item AutoNOC Interpreter. The software will create a window for the interpreter and set the scope to the object you clicked on. The interpreter is useful for many purposes.

Authoring or debugging probe expressions is one of the big reasons for it and because of this, if there is a relevant expression available, AutoNOC will automatically load the probe expression for the user to work with.

4.3.3 Operators and Precedence
The interpreter is a fully capable symbolic expression evaluator with built-in support for a variety of operators and mathematics functions. The following is the operator precedence order for the software:

If you are familiar with C++, then you will note that a lot of the operators are similar. We did this to make the AutoNOC interpreter faster and easier to learn, not to mention, given that AutoNOC is written in C++ we are certainly fans of the language! Because it is a scripted interpreter, there are some key differences however.

4.3.4 Strings and Numbers in the Interpreter
As C++ as AutoNOC's syntax is, because the AutoNOC interpreter is not compiled there are key differences in the way it works. This is most prevalent in the interpreter's handling of data. All data in the interpreter is stored as text and has a special internal type qualifier which specifies whether the source of the data was returning either a String or a Number. So, as far as you need to be concerned, there really are only two data types in the interpreter, Strings and Numbers.

Both of these data types are infinite precision, so a string can hold an entire SNMP MIB walk, and a number can hold a quad double (in C++ speak) in it's most accurate form. The only time that the data types even matter within AutoNOC is when using data, for arguments to functions results in an ambiguous situation.

For instance, consider this expression:

And also consider this expression:

Both expressions use the same operator, but have a different result because of the data types. Now let us introduce the String(...) and Number(...) casting functions. These work just like a normal C++ type cast and they change the way AutoNOC looks at each operator.

Let us add the String casting function to the first data type example:

Here you see that AutoNOC took a number "10" and converted it to a string and the + operator handled it as such. This works the same as with the Number casting function:

Does this make sense? Why even worry about such a thing? In network operations you have to manage, tweak, manipulate, calculate, compare all kinds of different data to determine service levels and states related to the network. Occasionally you need to use a returned number as a string for comparisons. AutoNOC handles much of this internally, behind the scenes (for instance, if it gets a counter back via SNMP, it knows that is an integer and sets the type accordingly), but what happens if you need to use an index for table lookup to match a component? In most cases AutoNOC gets it right, but occasionally a little data casting is needed to convert from one type to another.

AutoNOC's interpreter data type model is designed to be ideal for building expressions that act as the patches and the glue between the AutoNOC software and the multi-protocol network.

4.3.5 Comparisons and Logic
The interpreter features a full array of logic and comparison capabilities. Let us take a look at a few examples.

In the AutoNOC OSP Command Prompt, just like in C++, the value of 0 is FALSE and non-zero is TRUE. In the example below we use the Not boolean operator to reverse a true value to a false value. Note that the user could also use the ! operator as well.

Logical ANDs can be performed using either the double ampersand && or the AND keyword as the following example shows:

AutoNOC provides for robust comparisons of both strings and numbers. Consider this example in which 2 is compared to 3 and seen to be less than, thereby returning 1 which stands for TRUE.

AutoNOC is also able to compare strings alphabetically:

AutoNOC's interpreter can also compute using sophisticated conditional logic with the if keyword. The if keyword is a function that takes three arguments. The first argument is the conditional value. If it evaluates to TRUE then the statement returns the second argument. If the conditional is FALSE it returns the second argument.

The interpreter supports many different operators including bit shifting and bit logic operators as the following bitwise OR demonstrates:

4.3.6 Parsing, Extraction, and Cleaning
AutoNOC provides a variety of functions for parsing, cleaning, extracting, and manipulating data that it acquires so that state and other information might be removed from it.

In the following example, the interpreter calls the data function Length to ascertain the length of the string argument. In this case, the length of the word "Michele" is 7.

The software also includes a sorting function for sorting strings in order. The Sort function takes three arguments. The first being boolean with True being ascending order and False being descending order. The second argument is the data itself and the third argument is the delimiter which designates the characters in the data that seperate the data into separate items. The function returns a reconstituted list with the values in sorted order as shown below:

There is also a Strip function which removes characters from the string as shown:

A variety of functions are built in for extracting data as well including the Get function which extracts one record (zero-indexed) out of a delimited string. An example of grabbing the first alphabetical record out of a set of strings is shown below. Notice how the returned value from the Sort function is also a String data type that feeds right into the Get function call.

There are a great many extraction and data cleaning functions available for use. For a complete reference with examples see A.1 - Interpreter Functions.

4.3.7 Acquisition Functions
You have probably been reading up to this point and asking yourself, okay, what does this all have to do with network operations? Well we finally get to the good stuff. Everything we have discussed so far is related to manipulating information but where does this information to be manipulated come from?

To learn how AutoNOC breaks acquisition functions and expressions down into different protocol stacks, see 1.4 - Acquisition Stacks.

The answer varies, but for probes that do network monitoring, the information comes from the results returned by calls to data acquisition functions. An example of one such call would be utilizing the Ping acquisition function to do an ICMP ping check on a switch on the network as follows:

The response from the function is either a number, indicating the number of milliseconds it took for the response or the string X indicating the ping attempt failed. In the case of a probe expression, this value is stored in the database and the value is analyzed by the service levels for the probe to determine the objects state. For a complete discussion of service levels see 3.12 - Service Levels.

AutoNOC supports checking if certain ports are live for writing via the SOCK_IsListening call. An example of using this function to see if a web server is available on a server is shown below:

The SOCK_IsListening call returns the time in miliseconds that it takes for the port scan function to complete and like the Ping function it return an X if the function fails. This information is again used for defining the service levels which specify the overall state of the object.

AutoNOC leverages SNMP significantly in terms of monitoring devices. The following example expression queries the SNMP description of a device.

When SNMP functions fail they return a ?. By default AutoNOC is setup to not add records to the database when expressions have unresolved expressions containing ?. This helps to prevent good data from being cluttered with bad data. The actual state of the SNMP service is monitored separately.

4.3.8 Remote Queries via OSP
All of the data in AutoNOC, including the complete tree and AutoNOC's high performance recoiling database architecture is available via the command line and may be remotely queried. The following command sequence shows logging in to an AutoNOC portal, setting the scope to a probe with the cd command (you could also use the setscope command), and then performing a getdata query for a specific time range in AutoNOC.

telnet 192.168.1.3 34
logon(username,password)
cd("/Devices/DRAGON/Networking/IP/IP Out Requests")
getdata("11/21/2003 0:0:0","11/23/2003 23:59:59")

The following screenshot shows an example of this command being executed and AutoNOC processing the query.

It is also possible to have AutoNOC generate the data for PNG graphs in a safe data format for integration into third party portals as the following set shows:

telnet 192.168.1.3 34
logon(username,password)
cd("/Devices/DRAGON/Networking/IP/IP Out Requests")
rendergraph("11/21/2003 0:0:0","11/23/2003 23:59:59")

The following screenshot shows the command line execution of rendering a graph. For easy portability, AutoNOC renders this type of binary data as a standard 64-bit encoded data set. This is the same data format used by MIME e-mail attachments.

4.3.9 Local Variables
AutoNOC OSP features a very easy to use dynamic variable definition system that can dynamically store and process variable size strings and infinite precision numbers. Local variables in AutoNOC are idenfitied using the "$" operator, such as $i.

The following are some examples of using local variables within AutoNOC OSP:

$y=sin(4)
-0.7568024953079282
$y=$y*100
-75.680249530792821
$y=$y*100
-7568.0249530792826
$z=3*$y+10000
-12704.074859237848

Local variables do not work just with numbers. AutoNOC manages their data type internally so you do not have to worry about it (although you can cast it to different types with the String and Number functions). The following are some examples of using local variables on strings from the AutoNOC command line:

$Names="John,Jerry,Larry,Steve,Michele,Aspen"
John,Jerry,Larry,Steve,Michele,Aspen

Sort(TRUE,$Names,",")
Aspen,Jerry,John,Larry,Michele,Steve

Sort(FALSE,$Names,",")
Steve,Michele,Larry,John,Jerry,Aspen

Note that AutoNOC defined a string and then sorted it, first ascending, and then descending using the Sort function.

4.3.10 Chaining Commands
AutoNOC's Open Service Provider API supports the chaining and sequential execution of commands using the ; operator. The following is an example of using chained commands:

cd("/Devices/DRAGON"); $myip=%IP; Ping($myip);
28

In this case, AutoNOC changes the scope to the device DRAGON, computes the local scope variable %IP, assigns it to $myip and then calls the Ping acquisition function. The result is a return of 28. Ping returns values in the form of milliseconds.

The following is another example, used to see what objects are included in a given set, and using the Query function:

cd("/Sets/General/All Devices"); Query();
/Devices/NOMAD
/Devices/IP 192.168.1.6 Unknown
/Devices/IP 192.168.1.251 Unknown
/Devices/IP 192.168.1.250 Unknown
/Devices/IP 192.168.1.1 Unknown
/Devices/HERA
/Devices/DRAGON
/Devices/Device 8

Many more sophisticated OSP functions are available. For a complete reference see A.1 - Interpreter Functions.