Don't hipster programmers prefer JSON these days? XML too verbose.
On 24/07/2012, at 11:30 PM, "McKown, John" <john.mck...@healthmarkets.com> wrote: > OK, remember that I'm a bit of a UNIX bigot for some things. But I was > wondering if anybody else thinks it would be helpful to have a program into > which we could feed SMF records (standard IBM ones, at least) and get out > "properly encoded" XML? To me, this means that _somebody_ (hopefully IBM) > would create a XML DTD for their SMF records along with a way to create XML > output from SMF input records. > > Why? Because it is easier to process XML using standard tools, of which many > exist in UNIX and Linux, if the XML does _not_ include "binary blog" data. > And it is easier to ftp non-binary XML to an ASCII based system accurately in > order to process it there. Yes, I still want to offload processing from z/OS > to Linux. For those luckly enough to have z/Linux, this could be done very > efficiently over a hipersocket, assuming that the systems are on the same CEC. > > I greatly appreciate the RACF people for doing this already. Their IFASMFDP > exits, IRRADU00 and IRRADU86, already do this for the RACF type 80 audit > records. And also for some of the data in the SMF type 30, subtypes 1 and 5, > records. > > I don't know how the RACF people justified doing this. But it would be very > helpful to me if some of the other "popular" SMF records would get this > treatment as well. In particular, type 6 (printing), type 7 (data lost), > types 14 & 15 (open), 11 (scratch dsn), 12 (rename nonVSAM), type 26 (job > purge), 62-66 (VSAM related), 109 / 118 / 119 (TCPIP information), 110 (CICS > information), 115 / 116 (MQ series). Of course, some of the > XML transformation software would be written by the group responsible for the > software, eg: 110 by the CICS team; 115/116 by the MQ team, and so on. > > I also realize that IBM might actually oppose this for a number of valid > reasons, such as: cost to design, implement, and maintain; possible loss of > revenue (MSU based pricing) by making it easier to process SMF information on > another platform instead of z/OS. > > Just another crazy thought. > > -- > John McKown > Systems Engineer IV > IT > > Administrative Services Group > > HealthMarkets(r) > > 9151 Boulevard 26 * N. Richland Hills * TX 76010 > (817) 255-3225 phone * > john.mck...@healthmarkets.com * www.HealthMarkets.com > > Confidentiality Notice: This e-mail message may contain confidential or > proprietary information. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. HealthMarkets(r) is the brand name for products underwritten and > issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake > Life Insurance Company(r), Mid-West National Life Insurance Company of > TennesseeSM and The MEGA Life and Health Insurance Company.SM > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
