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 <[EMAIL PROTECTED]> wrote: >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
