Re: sending snmp traps from z/OS

Pat - although I'm mostly talking, as you were, to the audience of those
interested in this topic

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 referring to. This
was, in fact, just for issuing SNMP queries and receiving traps.

Those "execs and panels" (maybe programs too of some sort - I don't recall
the details) are suites of functions built up if not actually all during ITSO
redbook residencies then very much in the style of redbook residencies in the
early days of TCP/IP for MVS - the early '90s - in order to show what an
NetView-based SNMP manager could do. In other words they were to be
regarded as *samples* to guide the NetView customisation addicts to higher
things. As - I will call them - "ITSO-like" offerings, like anything from an ITSO
residency, I believe the expression popular across the water is "your mileage
may vary".[1]

If I were a betting man, I'd bet that, if you tried to create an APAR against
any of that code, you would be assured that the functions were offered "as
is", that is, "working as coded" was necessarily the same as "working as
designed"!

Just to emphasise those points, here is what I found in my presentation notes
on the topic:

<quote>

TCP/IP for MVS supplies some samples for such applications. While they
demonstrate very well the sort of applications that can be constructed, they
are somewhat poor as examples of Clist programming and are certainly not
offered as part of the supported product.

Customers are expected to write their own support packages to fit their own
needs. The author has, in fact, constructed a Clist-based application to
present traps as alerts that does not suffer from the lack of generality found
in the supplied sample.

</quote>

Naturally, since I had time on my hands and I was supposed to teach the
fundamentals of this stuff, I created my own version of a lot of what was
suggested. This was good preparation for building another suite of functions
for a customer some years later which exploited the so-called "MVS MIB" as
well as all the basic MIBs supporting the protocols supported by the
Communications Server IP component at the time possibly of interest to the
customer. Had I stayed in the consultancy, I would have added the OSPF MIB
as the next - quite big - step.

However, the SNMP support which I had in mind when writing my previous
post was simply the SNMP command upon which those "ITSO-like" suites - and
my efforts - were based. This SNMP command was the "manager" function in
the relatively simple SNMP of the day, I expect in the future to be called V1
since I didn't need to have to bother with version numbers. In fact, checking
my presentation notes I see that I claimed the TCP/IP for MVS, as it was
called while I was teaching the topic, implemented RFC 1157, "simply" SNMP
with no reference to a version.

So the support within the old original SNMP command was for GET, GETNEXT
functions but also the SET function which, thinking about it, I'm sure was also
present in those old "ITSO-like" offerings as both a "wrap-around" for the raw
command and for functions like starting and stopping interfaces - assuming my
memory is not too decrepit.

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.

Since I was writing for customer use, the set of functions I created
was "ruggedised" in the area where the SNMP command was issued. Thus I
handled all the cases I could devise for "going wrong" by picking up the
diagnostic message and dealing with the problem - all "under the covers".

What a shame that I was not available perusing FORA, as I was in the
late '90s, to handle the post you very probably made about your "horrible"
experience - assuming it happened in 2001 or later.

It's interesting that a major deficiency of that suite written for the customer
was that it was rather slow since I used a single SNMP call to retrieve each
object. If I had managed to devise another layer of code that collected
multiple calls to retrieve an object and then retrieved objects as a multiple as
is supported by the SNMP command.

I checked the CS IP System Administrator's Commands manual for this topic -
looking for how many object could be retrieved in one SNMP command call -
and I discovered that the official way to describe these SNMP commands is
the "z/OS UNIX snmp command" and the "NetView SNMP command".

A final word about these NetView Clist-Panel suites is that, the traditional z
operating systems are not the correct platforms for SNMP managers. The
SNMP managers which "kick posterior" are to be found on UNIX and Windows
and, I expect although I haven't seen evidence, Linux. On these platforms
with massive support for fancy presentation, you can, based on "simple" SNMP
flows, show the image of the business panel of the managed device, say a
hub of some sort, and the operator can pretend to be a pilot in a cockpit!

Oh yes, and we did not exactly see eye-to-eye, as I recall. :-)

Contrarily, I cannot recall any exchanges where we did not see eye-to-eye!

Regarding "improved": it seems I made the usual mistake of assuming that
whatever was newer was also better!

Regarding "quick-and-dirty" in reference to CNMSMSGT: the compounded
adjective referred to the design not the implementation. What you said about
it does tend to confirm what I suspected was the origin of the function.

Chris Mason

[1] The most recent BBC "Top Gear"[2] program involved a car "race" from
Basle to Blackpool - in order to officiate at the switching on of the famous
lights - obviously![3] The special requirement was that only one tank of fuel
was allowed in whatever make of car the three program presenters selected.
Despite all expectations all three arrived - "running on empty" as far as the
onboard monitoring was concerned. Supposedly the car with the largest
engine still had enough fuel for 120 more miles.

[2] I expect BBC1 and BBC2 are on sufficient satellite services now for me not
to have to apologise for mentioning BBC programs. In fact, I receive them on a
cable service in Belgium. If you have the chance to view this program, do so;
it is only incidentally for "petrolheads"!

[3] For those who know only "shore to sandy shore", Blackpool may be
compared to Atlantic City, NJ, I believe.

On Tue, 25 Nov 2008 15:12:23 -0600, Patrick O'Keefe
<patrick.okeefe@xxxxxxxx> wrote:

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
.