Hi John, I like the idea, but the overhead could get quite high. Products like Netview are already looking at every message that is issued and because of that has a fairly high overhead on the system. The reason we implemented SyzMPF/z the way we did was because we knew that we could provide the same functionality (plus some that they can't do) with about 1% (or less) of the system overhead that Netview uses. I really like the idea you have, but the thought of looking at each and every message and then checking to see who "might" be connected that "might" want to see it, or to write them all (or a subset) out to some other destination could be quite a load.
In 2008 I had a similar product idea that we were developing, (SyzWEB/z) which (among several other even more interesting features) allowed you to see, from the Internet, or your intranet, the console and interact with/on the messages (both manually and automatically), and also to send the messages (in several interesting formats) to some outlaying destinations. It allowed the console to have no screen limits (you could go as far back as you wanted). It gave the client side the power to manipulate the messages (i.e. build a package of "linked" messages for specific tasks) Providing the console messages to the internet was fairly simple to code, because we already had the basic interface thought out for SyzSPOOL/z, but when we began testing, we found that the overhead involved in sending the messages was not that bad, but because we had several places (and formats) we wanted to provide them (as well as other information) to, and the fact that we had to buffer them up until they were (successfully) delivered was a big deal. Actually, on our test processor it looked really neat, but when we loaded the system up and started generating even a small sustained load (less than 10 messages per second), we would eventually start backing up on the delivery. You can't just say that you can drop the ones you can't handle or that the client isn't ready to take off your hands yet, because they might be the very ones the user needs, so we shelved it for a while. In 2012 we re-opened the project and added some more features and changed the way that things were buffered, and "thought" I had it all figured out, until we generated a large amount of messages, and we ended up with (almost) the same problem. I came up with 2 possible solutions, both of which were given the green light to develop, but are a low priority right now because the demand for the capability just isn't there, and may never be. The reason we have not cancelled the projects is because they have each generated some interesting features that we were able to migrate to our already existing products, and we have several clients who are using the product and they are funding the development effort. I think it would be a cool thing for you to develop, but I wanted to warn you that the console message part is a bear to manage. Brian On Mon, 17 Nov 2014 12:18:40 -0600, John McKown <[email protected]> wrote: >I've been "inspired" by the recent thread about how to do a "tail -f" on >the z/OS SYSLOG data for alert processing. Most of us likely use automated >operator, such as CA-OPS/MVS, Tivoli (Netview?), SyzMPF/z (syzygyinc), or >other such tool for this. But they are basically designed to trap the >message and take an action locally. > >So, what occurs to me to do as a project (due to year end freeze during ACA >"Open Enrollment" period) is to write something, perhaps rather basic, >which uses the MCSOPMSG interface to "do something". The "do something" is >the rather nebulous part at present because I can think of a number of >"interesting" things to do. I looked at the CBTTape.org site to see if >there was anything which I could "borrow", but didn't see anything that >_appeared_ to use this interface. I was considering writing the main >function in such a way as to make it easy to "snap in" processing >submodules. I.e. the main routine just does the MSGOPMSG functions, but >then dispatches the individual MDB to any "registered" processor. So that >others can enhance / extend this simply by writing the MDB processor. > >Some of the processors that I was thinking about include: >1) Writing the console message to the z/OS UNIX syslog. It could the >forward to other UNIX syslog daemons, if desired. >2) Writing the data into a UNIX file. Unlikely because the UNIX syslog can >do this, so why should I? >3) Writing directly to a z/OS sequential data set. >4) Weird one: write to a UNIX message queue. >5) Listen on a TCP port and write the message to whomever connects to the >port. > >Of course, if I do attempt (and succeed) to do this, the code will be >distributed via the CBTtape. > >One other thought is what to implement this in. I will likely do it in >HLASM because basically everybody has it. But I was thinking that using >Metal C might be interesting too. > >-- >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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
