Subject: RE: script mib issue # 18

From: "Thomas, Steven C (Steve)" <[email-masked]>
Date: Fri, 26 Jan 2001 15:36:11 -0500

Hey!

I agree that the 2nd paragraph in the smRunError is over specification and
deleting it will allow scripts to report "informational" or "warning"
messages that don't rise to the point of "errors".

However, I think the paragraph can be deleted without necessarily adding the
extra feature of reporting errors, warnings, informational messages
asynchronously.  Your additional proposals (#18, #19, #20) show some (maybe
all) of the added capabilities needed to support asynchronous reporting.
Not clear to me yet how needed the asynchronous reporting is.

Cheers,
Steve Thomas
Software Technology Center
Bell Labs, Lucent Technologies

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: Friday, January 26, 2001 11:55 AM
To: DISMAN WG
Subject: script mib issue # 18

ISSUE 18:

The description of smRunError says:

      "This object contains a descriptive error message if the
       script terminates abnormally. An implementation must
       store a descriptive error message in this object if the
       script exits with the smRunExitCode `genericError'.

       The value of this object is the zero-length string as long
       as the smRunExitCode has the value `noError'"

The first paragraph is OK. The second one however looks like an
overspecification to me. Some runtime engines can have non-fatal
runtime errors. An example is a script which sometimes looses SNMP
responses, e.g. due to network overload problems. Many Tcl monitoring
scripts which are purely event-driven will handle this as a non-fatal
error situation and it would be nice to report the problem via the
smRunError object. However, the last paragraph in the description does
not allow me to do that.

PROPOSAL:

Remove the last paragraph altogether. (Note that this implies a change
in the SMX protocol as well in order to allow SMX runtime engines to
report runtime errors asynchronously. But this is just an addition and
not an incompatible change.)

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  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/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Jan 2001 21:49:10 +0100

>>>>> Thomas, Steven C (Steve) writes:

Thomas> I agree that the 2nd paragraph in the smRunError is over
Thomas> specification and deleting it will allow scripts to report
Thomas> "informational" or "warning" messages that don't rise to the
Thomas> point of "errors".

Thomas> However, I think the paragraph can be deleted without
Thomas> necessarily adding the extra feature of reporting errors,
Thomas> warnings, informational messages asynchronously.  Your
Thomas> additional proposals (#18, #19, #20) show some (maybe all) of
Thomas> the added capabilities needed to support asynchronous
Thomas> reporting.  Not clear to me yet how needed the asynchronous
Thomas> reporting is.

Just to be clear: The remark on the "extra feature" was purely on the
SMX specification. SMX currently does not allow to send an error
string from the runtime to the agent while the script is running. You
can only send result strings. So what would be needed is the following
addition to RFC 2593:

Reply =/ "536" WSP Zero WSP RunId WSP RunState WSP ErrorMsg CRLF

If you do not use SMX, then just forget about my comment.

Note that SMX an individual contribution (experimental) and not a WG
deliverable on the standards track - at least not now.

/js