SET-REQUEST, rowStatus, row_activated and agent++v3.4o

[Story, Robert]

I'm trying to figure out it the behavior I'm seeing with agent++v3.4o is a
bug or a limitation, or if I misunderstand the SNMP spec. I was under the
impression that the order of varbinds in a SET-REQUEST did not matter. This
isn't what I see with agent++.

Say I have a table X, with an integer index (column 1), one integer value
(column 2), and a rowStatus object (column 3). I expect that these set
requests would produce the same results:

A) set X.1.99.3 = createAndGo, X.1.99.2 = 11
B) set X.1.99.2 = 11, X.1.99.3 = createAndGo

With agent++, the first set succeeds, the second fails with a noSuchName
error on the first varbind. However,

C) set X.1.99.3 = createAndWait, X.1.99.2 = 11, X.1.99.3 = createAndGo

does work.

The reason I care is that I want to do some work in the row_activated()
method. In example (A), the row_activated() method is called before the
set_value() for column two occurs, so I can't get the new value [via
row->get_nth(2)->get_value(i) ]. Since the example (B) doesn't work, I have
to use example (C), which results in a row_deactivated() call immediately
followed by a row_activated() call. I'd like to avoid the row_deactivated()
method, if possible.


Also, I think there is a bug in MibTable::commit_set_request() [mib.cpp,
around line 1963].  I think this code:


		// collect all set requests for the row to be created
		Oidx row_index(index(req->get_oid(ind)));

		for (int i=0; i<req->subrequests(); i++) {

			if ((base(req->get_oid(i)) == oid) &&
			    (index(req->get_oid(i)) == row_index)) 
			
---->			  if ((status = set_value(req, ind)) !=
			      SNMP_ERROR_SUCCESS) {
					// don't answer request, wait for
undo
					Mib::requestList->
					  error(req->get_transaction_id(), 
						ind, 
						SNMP_ERROR_COMITFAIL);
					return SNMP_ERROR_COMITFAIL;
				}
		}

is intended to loop through a request, setting all items in a given row. But
the marked line is using a parameter (ind) that doesn't change, instead of
the loop index (i).  Thus the result is, for the example set request (A)
above, the set_value is called twice for the row status and a later
set_value does the actual set of column 2. This also results in the
row_activated() method being called twice (more, the if table has more
colums that are set in the set_request).


     - - - - - - -  Appended by Scientific-Atlanta, Inc.  - - - - - - -  
This e-mail and any attachments may contain information which is
confidential, proprietary, privileged or otherwise protected by law. The
information is solely intended for the named addressee (or a person
responsible for delivering it to the addressee). If you are not the intended
recipient of this message, you are not authorized to read, print, retain,
copy or disseminate this message or any part of it. If you have received
this e-mail in error, please notify the sender immediately by return e-mail
and delete it from your computer. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.agentpp.org/pipermail/agentpp/attachments/20001011/1834ffa6/attachment.htm