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
