<vendor pitch> You might want to take a look at IronStream from Syncsort: (http://www.syncsort.com/en/Solutions/Mainframe-Solutions/Ironstream It captures SYSLOG/OPERLOG messages in real time and sends them to a Splunk server (http://www.splunk.com/) where you can search and report based on keyword, message number, etc. IronStream also supports the capture of SMF records in real time, and interprets (converts to JSON and translates to ASCII) those records before sending them to Splunk. Data can be observed in Splunk within a few seconds of its creation on the mainframe.
</vendor pitch> Art Celestini Technology Architect SyncSort Inc. At 09:06 AM 12/4/2014, John McKown 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 [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
