Henrique Pat's response reminds me that I wanted to say something about this when I first spotted it - but forgot!
I'm glad he has been able to provide you with an easier solution than I would have offered since he is much more current with NetView than I am. Your surprise can be taken to indicate you are treating SNMP as some sort of peer-to-peer protocol. In fact SNMP follows the client-server model - but with some changes to the usual terminology: "client" becomes "manager" and "server" becomes "agent". SNMP GET, GETNEXT and SET functions are associated with the manager role within SNMP, as *solicited* exchanges of data, while the *receiving* of traps is also associated with the manager role within SNMP as *unsolicited* exchanges of data. SNMP commands on various platforms are low-level implementations of snmp APIs (if they exist otherwise the socket interface is used) and cover the functions I have just described. The agent role covers receiving SNMP GET, GETNEXT and SET protocol data units (PDUs) and responding with SNMP GET RESPONSE - in all three cases note. It also covers sending SNMP TRAPs unbidden. It is the SNMP agent which undertakes to acquire the data which the OID carried in the received SNMP PDU indicates should be obtained or to format the event information, all for presentation according to the SNMP protocol. Thus, in order to discover how to send SNMP traps, you need to look into SNMP agent support documentation rather than SNMP manager support documentation. The "command line tool (/bin/snmp)" is an example of what you will find in SNMP manager support documentation. It's interesting you describe the "command line tool (/bin/snmp)" by adding "that interfaces with the snmp agent task". An SNMP manager "interfaces" with an SNMP agent by *communicating* - with PDUs - over a network. This is not the normal use of the word *interface* in this context. There is a way to create traps which is older than the technique described by Pat. This is the answer I would have given if I had not forgotten! There is an API which is truly an "interface" to the SNMP agent which is described in the z/OS Communications Server IP Programmer's Guide and Reference, SC31- 8787: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D380/ (for V1R10) The first topic to be covered is the API to which I have just referred. Naturally one of the functions covered by this API is *sending* SNMP TRAPs. It also covers the matter of instantiating MIB entries, fake or otherwise. In fact it may be argued that all MIB entries are "fake" since it is the nature of the architecture that a MIB entry is a logical representation of something which is *real*. 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. There is a TRAPSON subcommand and a TRAPSOFF subcommand. These are used to control whether, TRAPSON, or not, TRAPSOFF, a TRAP PDU arriving at the NetView SNMP manager daemon, SNMPQE will be converted into unsolicited messages. It was then possible to use NetView automation based on the arriving message to use, for example, NetView Hardware Monitor, NPDA, to present the TRAP data in a digestible form. 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. Regarding CNMSMSGT: I would say that this was a bit of a "quick-and-dirty" way of implementing the SNMP agent TRAP function. Strictly SNMP architecture postulates only one SNMP agent function on an IP node. I think - without checking - this is more implied that stated. As Pat describes using CNMSMSGT, you, in effect, set up another SNMP agent independent of the "standard" SNMP agent. Were CNMSMSGT to use the API to the SNMP agent, then it would be in line with SNMP architecture. However CNMSMSGT may precisely perform the job you want done. Chris Mason On Thu, 20 Nov 2008 14:09:47 -0600, Henrique Seganfredo <[EMAIL PROTECTED]> wrote: >Hello folks, > >I have been trying to send a simple snmp trap from z/OS to another host for >some basic monitoring purposes. I found the /bin/snmp executable and its >documentation in the link below: > >http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/F1A1C260/7.1? SHELF=EZ2ZO10K&DT=20070604123226 > >Also I´ve read parts of the "Managing OS/390 TCP/IP with SNMP" Redbook and >got some notion about SNMP agents and the needed configuration. In this book >I have read the capacity of trap forwarding for the z/OS snmp agent and >other stuff. > >Surprisingly, the command line tool (/bin/snmp) that interfaces with the >snmp agent task only gives me the opportunity to RECEIVE TRAPS and not to >SEND THEM. > >Reading over and over the snmp command syntax it is clear that I am not able >to send a trap, only work with the SET/GET functions, creating a fake MIB >entry on both endpoints to set some value. > >Am I wrong? What can be done? > >Why the send trap function is not available? ---------------------------------------------------------------------- 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
