Price is Only the First Part of Cost Justification - Make Sure Your Vendor Offers Guaranteed Results

By Bob Berry
Chief Executive Officer
DPS Telecom
In my experience, clients who think hard about cost justification have a more important concern than just price. They want to make sure that they're not spending their company's money on a system that doesn't work as advertised.

T/Mon Can Monitor All Your Equipment Needs.

Most alarm systems support only the vendor's own devices or just one protocol. But T/Mon NOC monitors all your equipment - no matter who made it, or what protocol it uses - and display all your alarms on one screen.

T/Mon NOC can monitor nearly all your network equipment - DPS remotes, other manufacturers' remotes, switches, routers, PBXs, SONET equipment, multiplexers, battery plants, microwave radios, and more.

Why is this so important? Integrating all your alarms on one system gives you capabilities you can't get from separate, isolated systems:

• Know absolutely, 100% for certain if you have an alarm.

• Monitor every essential piece of equipment in your network.

• Correlate alarms across your entire network.

• Integrate older, incompatible monitoring equipment.

• Simplify training, maintenance and databasing.

Object-Types: Data you can read and sometimes write

Fortunately, you can ignore a lot of this gobbledygook. Here are the elements that you're interested in:

TRAP-TYPE: This tells you it's a Trap.

DESCRIPTION: This is a human-readable description of the Trap. It should give you a good basic indication of what the Trap signifies.

VARIABLES: This tells you actual information will be included in the Trap. When an actual Trap is sent, each of these variables will be paired with a numerical value that indicates its current state. A variable-and-value pair is called a variable binding.

The variables look pretty cryptic, but it's easy to find out what they mean. Each variable is a text label for an OID defined elsewhere in the MIB. You can do a Ctrl-F search for any variable term and find its definition. For example, "dpsRTUAPort" is defined in the DPS MIB like this:

ACCESS read-only
STATUS mandatory
DESCRIPTION "RTU port number."
::= {dpsRTUAlarmEntry 1}

Trap variables are your best guide to what alarms you'll get from an SNMP device. Depending on the device, the variables can be highly detailed or they can be vague summary alarms.

When reading the MIB, you'll also want to know what information you can directly request from the device, and what information you can send to the device. These functions are controlled by the SNMP commands GetRequest and SetRequest.

If you want to translate these commands into classic telemetry terms, you can roughly think of a GetRequest as an alarm poll and a SetRequest as a control command.

GetRequests and SetRequests operate on a type of element called an object-type. Object-types are called out in the MIB like this:

SYNTAX DisplayString (SIZE (8))
ACCESS read-only
STATUS mandatory
DESCRIPTION "The current alarm state."
::= {tmonAlarmEntry 4}

There are many different kinds of object-types. The specific object-types you might find in a MIB depend on the type of device, what kind of components it has, what the functions of those components, are, etc.

You're probably not going to be interested in every object-type listed in the MIB, because you're not going to be interested in everything about the device's functions.