Good luck with a DTD that covers the panoply of SMF record types and subtypes. :-)
Might well prefer JSON myself (hip that I ain't) :-) - but similar issues arise with that. Martin (not speaking for SMF or any other Development) Packer Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: "McKown, John" <john.mck...@healthmarkets.com> To: IBM-MAIN@listserv.ua.edu, Date: 07/24/2012 04:30 PM Subject: useful? XML "encoded" SMF. Sent by: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> 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 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
