Question & Answer
Question
Explanation of NetView Event/Automation Service (E/AS)
Answer
The Event Receiver (EVENTRCV) task in NetView's Event/Automation Service (E/AS) supports only EIF events over TCP. There are or have been commands, e.g. posteifmsg or postzmsg, included in different editions of an EIF toolkit that is not distributed as a part of NetView, that can be used to send EIF events, or users could create code based upon APIs available in the EIF toolkit to send EIF events.
Using the class definition statements (CDS, such as in sample IHSAECDS), EVENTRCV can convert an EIF event into a Network Management Vector Transport (NMVT) request unit containing either an alert major vector or resolve major vector, depending upon what was dictated by the CDS. The CDS lets the user choose what data from the EIF event may be included in the NMVT and where (of course, there are limitations in the architecture of the NMVT as to what data may go where).
Presuming the EIF event was not discarded and the NMVT was built, EVENTRCV tells the E/AS CONTROL task to send it to NetView - over the program-to-program interface (PPI) to a presumed NetView alert receiver task (usually the CNMCALRT task in NetView managing a PPI receiver named NETVALRT). Ultimately, that NMVT is passed to hardware monitor (also known as NPDA), where the NMVT can be automated to schedule one or more commands to process it. A NetView REXX command procedure can use the MSUSEG() function to navigate the vectors in the NMVT to get to whatever was extracted from the EIF event and placed in the NMVT.
The MSUSEG() function is described in IBM Tivoli NetView for z/OS Programming: REXX and the NetView Command List Language.
There are other tasks, if you will, in NetView that can consume other kinds of inbound data.
An SNMP trap automation task in NetView can receive SNMP traps, supporting SNMPv1, SNMPv2c, and SNMPv3 traps over UDP, TCP, UDP6, and TCP6 (UDP6 = UDP over IPv6, TCP6 = TCP over IPv6). It builds a Control Point Management Services Unit (CP-MSU) containing data from and about the received SNMP trap and passes it to NetView automation. A NetView REXX procedure scheduled by automation also uses the MSUSEG() function to navigate the vectors in it. The vector keys are different from those you might find in requests used for SNA formatted alerting, so the automation table statements used to trap these can co-exist with (and not hit for) those used in SNA formatted alerting.
This SNMP trap automation is discussed in the SNMP Trap Automation chapter of IBM Tivoli NetView for z/OS Automation Guide, and there is a sample, CNMSALRT, that illustrates the navigation of the CP-MSU vectors.
Another task in E/AS, the Trap to Alert Conversion task (TRAPALRT), takes an SNMP trap and uses its own CDS (sample IHSATCDS and members it includes) to build an NMVT and send it to the NetView alert receiver. In other words, it does what EVENTRCV does, only with SNMP traps. This was created before the SNMP trap automation task mentioned above and only supports SNMPv1 traps over UDP.
A task in NetView named DSIRTTR can receive a CP-MSU containing an alert major vector over TCP or TCP6 and pass that CP-MSU to hardware monitor, where it may be automated. Again, a NetView REXX EXEC could use the MSUSEG() function to navigate the vectors. It may be necessary to blow the dust off of a copy of SNA Management Services Formats to effectively construct CP-MSUs for this interface (or perhaps use CP-MSU building code in sample CNMSALRT as a pattern ... because that's the format of its output).
A function named NetView Web Services Gateway can accept NetView commands within SOAP requests; however, as the announcement letter for IBM Z NetView V6R3 indicates, the V6R3 release is the last NetView release in which the Web Services Gateway will be supported.
But, IBM Z NetView V6R3 does provide a NetView REST Server that can be set up to execute NetView commands received via a RESTful API, and which can work with a Service Management Unite-provided web interface, a Zowe-provided web interface, or standalone.
NetView also provides facilities that allow users to create their own servers to receive and process virtually any kind of data. One example of how that might be done exists in the form of an as-is sample NetView REXX EXEC (named SAMPEIF) that implements a TCP (or TCP6) server to receive EIF events. The sample simply writes out the contents of an EIF event after having translated it from ASCII to EBCDIC.
There are some additional ways to send data to NetView in an SNA network (e.g. SNA LU 6.2 transactions) - but this information was written on the assumption that the primary interest is TCP/IP-based.
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSGMPW","label":"Tivoli NetView"},"ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
01 June 2020
UID
ibm16216675