Re: if a multi-variable SET fails halfway thru, does it have to undo the sets it has finished???

Daniel Mehkeri <danielm@halcyon.ca> wrote: Daniel> Ed wrote: Daniel> > Lets say that in spite of all your testing, a commit value fails. Daniel> > have you still kept your rollback? Daniel> > Daniel> > The issue can also be one of time, as when the user swaps out a card Daniel> > right between the times where the test takes place and the set takes Daniel> > place. Daniel> Daniel> You might keep a rollback, you might not. You are supposed to "try" -- Daniel> as pointed out somewhere along the thread, what useful behaviour will Daniel> all this bring? Is it worth the effort? Daniel> Daniel> Is it important that the manager get an error response to the SET Daniel> in this case? Daniel> Daniel> If not, just ignore the error and let the other SETs commit -- Don't Daniel> kill yourself trying to handle a "user removed floppy" error on a Daniel> "eject floppy" SET :) That is excellent advice (as is the rest of the stuff in Daniel's article <37AAF75E.491A@halcyon.ca>). I have only a few minor embellishments to add. In the SNMP agent framework that I use the instructions to developers of set methods state that "the return value shall be SNMP_ERR_NO_ERROR" if the action is COMMIT_VALUE_AND_ACTION or ROLLBACK_PROPOSED_VALUE. The SNMP engine ignores the return code if it is different. In other words, a COMMIT_VALUE_AND_ACTION step is not allowed to fail if a preceding CHECK_VALUE_CONSISTENCY action succeeds, and a ROLLBACK_PROPOSED_VALUE step is not allowed to fail if a preceding CHECK_VARBIND_SYNTAX step succeeds. You might say that these conditions are part of a contract between the SNMP engine developers and the SNMP object developers. Now, it is true that this scheme will proceed with all of the variable assignments if a user swaps out a card right between the CHECK_VALUE_CONSISTENCY step and the COMMIT_VALUE_AND_ACTION step. But what harm arises from that? Suppose that the user pulls the card immediately after the COMMIT_VALUE_AND_ACTION step. You get the same result, from the manager's point of view. Ed> >If at all possible, you should attempt to design MIB objects and Ed> >underlying instrumentation so that these unpleasant situations do Ed> >not occur. Granted, that's sometimes not possible. Ed> Ed> How is it ever possible? I have no idea what might be coming in a Ed> packet so I have to be able to undo every set that I am able to do. Ed> How can mib design help? (Because I am also designing an enterprise Ed> mib now). Read the sections of RFC 2579 on the RowStatus TEXTUAL-CONVENTION which is used to manage the creation of conceptual rows in tables. It is excellent example of how to design groups of MIB objects in a way that prevents these problems. And yes, you can implement this in your SNMPv1 agent even though it is an SMIv2 feature, by mapping the error codes (see RFC 2089 and/or draft-ietf-snmpv3-coex-04.txt for details). Ed> My agent is calling functions on other sw that does not always do what Ed> it is supposed to. If the external functions that you call do not live up to their interface contracts you are indeed between a rock and a hard place. Mike -- C. M. Heard/VVNET, Inc. heard@vvnet.com