On Tue, 25 Nov 2008 09:04:10 -0600, Chris Mason <[EMAIL PROTECTED]> wrote:
>... >Pat is stating that the SNMP command may also be used for >sending TRAPs. My experience with the SNMP command - from >about 15 years ago - regarding TRAPs is distilled into my >presentation material under the title "TRAP Handling" >implying it is used only for *receiving* TRAPs. Chris and I are actually talking about 2 very different things. For eons there have been a set of NetView execs, panels, and programs provided with TCP/IP. This is the SNMP support for NetView that Chris is refering to. This was, in fact, just for issuing SNMP queries and receiving traps. My experience with this SNMP support was absolutely horrible and left a terrible taste in my mind. When it worked, it was many times faster than NetView's newer "native" SNMP support, but when it stumbled during a large query (which for me was more often than not) there was a flood of hundreds (thousands?) of error messages. There are still those that prefer the old technique, but I much prefer the newer support. And it supports trap generation. Prior to NetView 5.3 it could create only v1 and v2c traps. In 5.3 it can alos create v3 traps. (It is, however, very slow and cycle-hungry.) NetView 5.3 also has a built-in trap receiver which allows trap automation, but no built-in trap-to-Alert conversion. (You can do it yourself, but it is a pain.) >... >I'm sure I have seen and probably participated in list discussions - >almost certainly also involving Pat - here or elsewhere, in which >an improved implementation of the SNMP manager function in >NetView has been mentioned. ... Oh yes, and we did not exactly see eye-to-eye, as I recall. :-) I would call it "different" rather than "improved", though. I think the NetView developers have taken several steps in the right direction, but but several other very big steps backward. The performance is, umm, perhaps not the best. >... >Regarding CNMSMSGT: I would say that this was a bit of a "quick-and- >dirty" way of implementing the SNMP agent TRAP function. >... As I recall, CNMSMSGT (under some other name, I'm sure) was a tool written by the NetView testers to generate many traps as fast as they could. I think it was provided as a sample after customers complained about the slowness and excessive cycle use of NetView's SNMP TRAP function. By the time they got done documenting the sample, "quick" no longer applied. And I think it's pretty clean, too. >... >Strictly >SNMP architecture postulates only one SNMP agent >function on an IP node. I think - without checking - this is more >implied thatn stated. As Pat describes using CNMSMSGT, you, >in effect, set up another SNMP agent independent of the >"standard" SNMP agent. ... That may be true. If so, that argument also applies to NetView's "native" SNMP TRAP function. >Were CNMSMSGT to use the API to the SNMP >agent, then it would be in line with SNMP architecture. That would have been a interesting project. I think I actually thought about it years ago. I wish I'd followed through with it. :-( >... >However CNMSMSGT may precisely perform the job you want done. >... Actually, if the original poster is not particularly worried about performance, NetView's native SNMP TRAP support is probably the way to go. It's got hundreds of lines of inscrutable online help because it has so many options, but if you concentrate on just one version it's fairly straightforward. Pat O'Keefe ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
