This directory contains the mibdump, evsink and evlog programs.
It also contains a test program that was written
to test the management agent - the mibdump and evsink programs
have been derived from that one.

The following text should serve as manual pages for the programs.




mibdump <service> <hostname> [ <objclass> <objinst> [ <scope> ] ]

The mibdump program allows to connect to a remote management agent
and retrieve and pretty-print managed objects from the remote MIB.
When all the requested managed objects have been received,
it releases the association and exits.

The "service" argument is the management service qualifier,
which in the case of the OSIMIS agent should be SMA, and the
"hostname" is the name of the remote host where the agent runs
(the service designator). These arguments together with the
application context ("management") identify uniquely the
application entity title of the remote agent and hence its
presentation address.

If no other arguments are given, all the managed objects of the
remote MIB are requested through a wholeSubtree scope.
Specific objects may be requested through the class, instance
and scope parameters.

The "objclass" should be the managed object class as registered
in the osimis/etc/isobjects database e.g. system, transportEntity.

The "objinst" should be the managed object's distinguished name
in string form e.g. systemId=foo, subsystemId=transport@entityId=isode.
Note that if you supply a full distinguished name starting with
systeId=..., it will be converted to a local distinguished name by ignoring
its first component. This means that the systemId value is not significant
and can be altogether omitted. In fact, the systemId=foo (or simply systemId)
relative distinguished name is only needed when the system object itself
is requested.

The "scope" parameter can take the values:
baseObject, firstLevel, wholeSubtree, NthLevel and baseToNthLevel.
In the case of the last two, N should be a number e.g. 2ndLevel,
baseTo3rdLevel, 5thLevel etc.

If the class and instance parameters are supplied but the scope is
ommitted, a baseObject scope is assumed. This is in contrast to the usage
with no class, instance and scope where a wholeSubtree scope is assumed.

Example instances of the usage of this program are:

mibdump SMA athena system systemId=foo firstLevel
(request all MOs immediately below the system object)

mibdump SMA athena transportEntity subsystemId=transport@entityId=isode
(request the transport entity object)

mibdump SMA athena subsystem subsystemId=transport 2ndLevel
(request all MOs at the second level below the trsnport subsystem object -
usually transport connetions for connection-oriented transport entities...)






evsink <service> <hostname> [ <eventreport> <eventreport> ... ]

The evsink program allows to connect to a remote management agent
and create an EventForwardingDiscriminator managed object
in order to receive event reports. The received event reports
are pretty-printed to the standard output.

The "service" argument is the management service qualifier,
which in the case of the OSIMIS agent should be SMA, and the
"hostname" is the name of the remote host where the agent runs
(the service designator). These arguments should be as registered
in the osimis/etc/isoentities database and together with the
application context ("management") identify uniquely the
application entity title of the remote agent and hence its
presentation address.

Discrimination on the type of event reports is allowed through
a simple OR filter i.e. the event reports whose names are supplied
in the command line are received. If no event report names are supplied,
all event reports are received.

The program terminates by receiving a SIGQUIT signal when in the forground
(Control-\ for most keyboards) or a SIGTERM signal when in the
background (produced by the Unix program kill(1)). Upon the reception
of the termination signal, it deletes the EFDiscriminator it created
and releases the management association before it exits.

An example instance of its usage is:

evsink SMA athena tConnectionCreation tConnectionShutdown

which requests all transport connection creation and shutdown event reports
from the TP0 MIB supported by the agent running at host athena.






evlog <service> <hostname> [args ...]

A description of args can be found in README.UsingLogs. Some examples of usage
folllow :

   evlog SMA lemma tConnectionCreation tConnectionShutdown

This is the similar to evsink, except an EventLog object is created instead of
an EFD, and emitted notifications will be logged at the agent.

   evlog SMA lemma D 1

This will delete the log instance {logId=1} on SMA-lemma.

   evlog SMA lemma D 1 3

This will delete the log record with {logId=1@recordId=3}.

   evlog SMA lemma S 1 maxLogSize 1200

This will set the maxLogSize attribute value to 1200 for the log instance
{logId=1}.




iproute
*******************************************************************************
        WARNING : THERE IS NO ACCESS CONTROL WHEN USING IPROUTE.

Access control has yet to be implemented and is not present in the iproute
program or the sma using the OIM MIB. Please use the software with care.
*******************************************************************************


iproute will allow management of the routing tables when used with an agent
that has the OIM objects as part of its MIB.

There are several ways of using the program :

   iproute <agent> <hostname> [n]
   Print routing table
   n option prints IP addresses as numbers, not names

   iproute <agent> <hostname> C
   Create ipRoutingTable

   iproute <agent> <hostname> D
   Delete ipRoutingTable

   iproute <agent> <hostname> C <destination> <gateway>
   Create ipRouteEntry for destination -> gateway

   iproute <agent> <hostname> D <destination>
   Delete ipRouteEntry for destination
   destination and gateway can be names or in "dot notation".

iproute does not allow changes to individual attributes in the ipRouteEntry
objects - you must delete and create whole ipRouteEntry objects.
