[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf A non-trivial policyAction example

>>>>> Steve Waldbusser writes:

Steve> I just though that if I omit the middle of 3 arguments (leaving
Steve> two), it is difficult to tell which of the last 2 arguments was
Steve> left off. For example, if I send {, integer
Steve> }, do I interpret that as sending an unspecified integer value,
Steve> or as sending a string whose value is "integer".

The Tmn API is clear about this.

three list elements:

      1 oid (or something that resolves to an oid)
      2 type name
      3 value

two list elements:

      1 oid (or something that resolves to an oid)
      2 value

one list element:

      1 oid (or something that resolves to an oid)

Steve> Most varargs schemes allow you to optionally remove items from
Steve> the end of the sequence only.

See, these are lists and not varargs. ;-)

Steve> Regarding your second question, it doesn't mean "same context"
Steve> (context is really more of a modelling concept than a physical
Steve> concept anyway).

He? SNMPv3 has scoped PDUs - is that not physical enough?

Steve> And I don't think that there is any terminology in our
Steve> architecture that helps. It's simply pointing out that if the
Steve> PM agent and the target agent are on the same system, you can
Steve> getint() without issuing a PDU. And if they are in different
Steve> subagents on the same system, you can (probably) getint()
Steve> without issuing a PDU. And if they are on different systems you
Steve> probably have to send an SNMP PDU on the wire between the two
Steve> systems.

For me, it would be easier to understand the complete picture if
things were described based on the SNMP architecture and its
terminology. But given the fact that you stated (as I understood it)
that an execution engine can act as a mid-level manager, then the
distinction between a "local getint()" and a "remote getint()" does
not really matter and you may as well remove that text.


Steve> You think I'm saying that error handling is not important in
Steve> the general case. I'm not. Please re-read my comments and
Steve> you'll see.

When I started to write the scotty package, I introduced a job command
which allows to schedule the execution of Tcl procedures regularily
with the capability to suspend and resume jobs. However, I did not
give jobs full control how they should behave on error situations.  In
fact, the scheduler was just scheduling them again.  Experience with
real world code later told me that this was a design mistake and there
are now job properties which give complete control over what happens
if things go crazy. This was needed to write robust code.


Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>