Hi John, While I am sure this not exactly what you are dreaming about we do run IBM's z/Aware with does consume operlogs and provides an api that uses xml.
http://www-01.ibm.com/support/docview.wss?uid=isg24f9114255d7d1f3285257a6a0077c2ca Doug On Thu, 4 Dec 2014 08:06:33 -0600, John McKown <john.archie.mck...@gmail.com> wrote: >This is just my mind wandering around loose again. You kind indulgence is >appreciated. > >But I've been thinking about the z/OS syslog for some reason lately. Given >what it was originally designed for, review by a human, it is a decent >design. But is it really as helpful as it could be in today's z/OS >environment? Should z/OS have a more generalized logging facility? I will >grant that subsystems have various "logs", but they each basically have >their own structure. Is there really a need for the z/OS system log >anymore? I really don't know. And I will admit that my mind has been >corrupted by using Linux too much lately. <grin/> > >So, if such a thing is even needed any more, what might it look like? >Should it go to SPOOL? Should it be more like the OPERLOG and go to a >LOGGER destination? Or should it go "somewhere else"? > >So what would I like? I know most will moan, but I _like_ structured, >textual, information. So I would prefer that the output be in something >like XML or JSON structure, not "column" based. And no encoded binary, OK? >Now I'm trying to come up with what sort of data should be in the "system >header" type data. These are just some fields that _I_ think would be >useful in a good, generic, logging facility. First would be the current >date in ISO8601 format, something like 2014-12-04T07:34:03-06:00 which is >the date/time as I am typing this near Dallas, TX. This tells us the local >time and gives us enough information to determine the UTC for comparison or >conversion. I would also like the z/OS sysplex name, the system name, the >CPU serial number, LPAR number, z/VM guest name (if applicable), job name >(address space name), RACF owner, step name, proc step name, program name >in the RB which issued the logging service call, program name in the first >RB chained to the JS TCB (which I think should be the EXEC PGM=... name in >most cases for batch jobs), ASID number, UNIX process id (==0 if not dubbed >because there is no PID of 0 in UNIX, or maybe -1), step number (as used in >SMF), substep number (again as defined in some SMF records). > >Product specific data would be formally encoded as designed by the product. >Preferably, if in XML, with a DTD to describe it. And done so that standard >XML facilities such as XSLT and XPath can process it. Which I one reason >that I like XML a bit better than JSON at this point in time. There are a >lot of XML utilities around. > >And, lastly, I do realize that the above would be very costly. Not >necessarily to just implement into z/OS, but to actually change z/OS code >to start using it. And that may be the real killer. IMO, one of the biggest >obstructions to designing new facility which "enhance" existing facilities >is the cost of implementing them. This combined with the current emphasis >on immediate return on investment. I.e. if I invest a million dollars in >something, I expect to get back 2 million in 6 months or less. > >Well, I guess that I've bored you enough with this bit of weirdness. Like >many of my ideas, they sound good to me until others point out that they >are just silly/stupid/unnecessary. > >-- >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
