Re: agent and scotty 2.0.2 experiences and sample code

Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Tue, 21 Nov 1995 18:36:51 +0100

Hi!

Peter J M Polkinghorne <Peter.Polkinghorne@gec-hrc.co.uk> said:

Peter> These comments are the result of using the features new to
Peter> scotty 2.0.2 for implementing agent - in particular tables
Peter> with the RowStatus convention.

Thanks for your feedback. Lets see what we can improve: :-)

Peter> a) the CHECK bindings should take place before the result
Peter> values are put the response PDU - this allows for the
Peter> notInService vs notReady distinction.

You are right. I added this to my TODO list.

Peter> b) automation for create/rollback would be nice - that is on
Peter> rollback unbind the instance so created - this would eliminate
Peter> some of the code in the example.

I fixed my sources to remove instances automatically.

Peter> c) for a lot of table processing you need to know what the old
Peter> value was, this is particularly true for RowStatus. While
Peter> scotty automaticly saves this value for you, it is not
Peter> accessible.

I added another escape substitution: %p will be replaced by the
previous value where applicable or an empty string.

Peter> d) alternatively may be table processing is just too tough to
Peter> automate?

No, I think most of your sample code can be generalized so that you
can bind some default Tcl procs to handle basic RowStatus conventions.
Doing in Tcl instead of hard coding RowStatus in C allows to rewrite
the procs as you need them. I think a revised version of your
RowStatus code should be in a Tcl agent library file.

Peter> e) because when evaluating bindings the error value from the
Peter> script is used, debugging the bind script is hard - may be I
Peter> am missing a TCL trick to debug these scripts?

You can catch the error, print out the error message and invoe a
similar error to make the binding happy. Not a very elegant solution I
must admit.

Peter> f) I came across a bug in getnext processing: when a table
Peter> entry is created with createAndWait, it may well have "holes"
Peter> in it. So when I had a table

This might be a problem with not-accessible variables which are not
skipped when searching for the next instance. I added a note about
this to my TODO list.

Peter> I include some sample code so:
Peter> a) others may avoid some pain and grief
Peter> b) others can point out the bugs :-)

Peter> Here is the skeleton code for a table (called table!):

I made a diff containing the changes mentioned above. Your sample code
should get a lot smaller as you do not need to care about removing
newly created instances and you can access the previous value using
%p. It would be nice if you can test the diff and post an updated
sample script to this list. I moved the diff to our FTP archive since
it is too large to be appended to this message. Besides many cosmetic
changes I also added two new session options: -delay defines a minimum
delay between two SNMP packets in milliseconds and -window sets the
max. number of asynchronous requests on the wire. These options will
solve some flow-control problems if you create lots of asynchronous
requests.

Note, this is not yet an `official' scotty patch - it is just a
snapshot from some work in progress. You will find it on
ftp.ibr.cs.tu-bs.de in /pub/local/tkined/experimental/snmp.diff.gz.

Juergen