Re: sending snmp traps from z/OS
- From: patrick.okeefe@xxxxxxxx (Patrick O'Keefe)
- Date: 25 Nov 2008 13:13:27 -0800
On Tue, 25 Nov 2008 09:04:10 -0600, Chris Mason
<chrismason@xxxxxxxxxxxx> 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 listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.
- Prev by Date: Re: Add Storage To Lpar - z/800
- Next by Date: Re: sending snmp traps from z/OS
- Previous by thread: Re: sending snmp traps from z/OS
- Next by thread: Re: sending snmp traps from z/OS
- Index(es):
Relevant Pages
|
