While conceptually XML sounds nice, the problem would seem to be the
extreme volume of data involved, millions of messages daily for large
installations. Uncompressed XML is incredibly inefficient in storage
requirements, and compressing/uncompressing XML has processing costs.
>From my viewpoint I would be much more concerned about the ongoing and
continual additional overhead costs an XML Syslog would add to the daily
operation of a z/OS shop, including archival and search costs, not just
the implementation costs.
System automation tools that are common to many z/OS shops already can
already incur significant overhead in processing system log records, so
one would not want to add to that by significantly increasing the size
or processing cost of reading log records.
While it would be nice to have an easy way of associating things like
Sysplex, System, and LPAR names, etc. with messages, you really need to
do this in a way that doesn't replicate what for a given system is
essentially constant information on millions of log entry records.
At times when I have had to search through system logs, I have given
thought about how much easier it might be if they were structured into a
relational database, but obviously that would not a practical design for
direct recording of SYSLOG as one of the roles of SYSLOG is to track
z/OS startup and failures affecting the z/OS relational database servers.
There is a basic design conflict inherent with the existing SYSLOG
between making a record terse enough for efficient archival and message
automation versus creating a human-readable message for consoles and
batch job logs.
As long as the SYSLOG is also allowed to contain messages generated by
local installation code and local application code, all rules on
structure of messages become unenforceable by z/OS. Not sure how to get
around that.
Joel C. Ewing
On 12/04/2014 08:06 AM, 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.
>
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
