On Mon, Nov 17, 2014 at 7:46 AM, Kacynski, Walt <[email protected]> wrote:
> What I really implied was the ability to "tail -f" to continuously watch > the syslog for new events and send them to an external system. I'm finding > a lot of solutions to get at the system but we want to create a real-time > alerting mechanism using the distributed tools that we already have > available. There is commercial software out there, but this seems like a > basic function on any modern enterprise operating system. I'm guessing > that it is just a matter of piecing together the parts that everyone has > already built. > Perhaps we should start by asking you what software you currently have installed? Perhaps some sort of monitoring software could send the event notification to your alert system. E.g. if you have CA-OPS/MVS, then you could use it to install rules which trap the SYSLOG messages of interest and send them, via REXX sockets?, to your alert system. If you have other CA software, see if it has CA's Event Notification Facility in it. If so, you could possible use that to send SNMP alerts out (we use this + CA/OPS + the caopswto() function for this type of thing and it works well with SolarWinds Orion). Other thoughts: Perhaps the simplest / easiest option is to u se an EMCS console. Look in SYS1.SAMPLIB at members: (1) IEAEXMCS - assember code; (2) IEATOPS? - REXX / ISPF example ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/7.8.2.2 Use this is some sort of a started task to "trap and process" the messages. I would likely use this in combination with REXX sockets to reformat the information and send it out via TCPIP to the alert system. Perhaps encoded as a standard SNMP trap message, which most UNIX & Windows alert system can accept. Use the IEAVMXIT exit and do "whatever" you want with the trapped messages. ref: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2e4b0/2.12 This may be the closest you can get to a "real time" "tail -f" of the z/OS console traffic. Send data as with the first? Similar to the above, use the SSI exit 9 to trap the WTO / WTOR messages. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2f280/6.1.3 . Again, sending data as above. The major problem with the last two is that they are both "in line" with z/OS console processing. And that means that they can slow done normal processing or cause problems if they abend. Therefore, in the latter two cases, I think you should use them to update some in-memory (above the bar?) buffer which is "drained" by some other started task which can take the message from the "buffer" and send them on their way. Of course, this requires good memory management which is reentrant so that the "producer" and "consumer" don't step on each other. And it might (likely would) require XMPOST to "fire up" the "consumer" if it every runs out of data to process and needs to WAIT for more data. Unless you want to avoid that by "polling" the buffer for messages on a scheduled basis (STIMER?). The above (IEAVMXIT or SSI 9) sounds "interesting" to me. I might even look at it. I already have IEAVMXIT code that I could use as a start. So I might look at SSI 9 instead as a "learning experience". Not that today's companies actually seem to want this sort of in-house expertise. And I understand why. It is expensive. And the employee becomes a single point of failure (death or retirement or just leaving). > > Walter Kacynski > Web Infrastructure Administration > Auto-Owners Insurance > For support, please see Wiki > 517-703-2506 > -- > The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
