Re: useful? XML encoded SMF.
I imagine a tool to extract particular types of SMF data, maybe summarize and export as Xml for further processing could be pretty useful. That would not necessarily be an excessive load on Xml tools, although maybe one underestimates the processing power of a modern PC. Certainly processing raw SMF data is a somewhat specialized operation. -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von Andrew Rowley Gesendet: Mittwoch, 25. Juli 2012 10:46 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: Re: useful? XML encoded SMF. You would have more chance convincing vendors to write something if you at least pretended you might pay money for it ;-) I don't think it would be particularly difficult to incorporate output to XML into EasySMF, but I'm not convinced that SMF data in XML format would be generally useful. The volume of SMF data is difficult enough to deal with in binary form. XML would be worse. Are the XML reporting programs really able to cope with the quantity of data that comes from SMF? Regards Andrew Rowley -- Andrew Rowley Black Hill Software Pty. Ltd. Phone: +61 413 302 386 EasySMF for z/OS: Interactive SMF Reports on Your PC http://www.smfreports.com On 25/07/2012 2:46 AM, McKown, John wrote: In my case, it is strictly due to the lack of tools on z/OS. We used to have SAS and MXG. That was perfect. We then lost SAS due to cost. So we ran MXG on a PC running SAS. But that was then considered to be too expensive too. So we lost SAS and MXG. We now have _nothing_ and no money to buy anything. But management would still like to see graphs and charts. So we have a few HLASM in-house written programs. Which extract some information which is downloaded to a PC running Excel. Which is used to make the pretty pictures so beloved by management. In addition to this, our management is still pushing us to try to reduce our Group Capacity cap so that we will save even more money due to reduced license costs. So, if I could have XML formatted SMF data, I could easily download and process that on my Linux desktop. Because Linux, and the software I run on it, does not cost the company anything other than electricity to run the PC. And I have many tools on my Linux system which can process XML and then create graphs from the processd data. IOW, it is not enthusiasm ... against all rational argument, it is for my convience due to lack of money. If management didn't want the graphs, I wouldn't care one bit about SMF - XML. And yes, I could write it myself. But my manager is against that due to the necessity of our doing maintenance to any in house written code if IBM makes changes to an SMF record that we use. So, in reality, there is no real reason to think that IBM, and other vendors, would be interested in this. But dreaming is still free. -- 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
Re: useful? XML encoded SMF.
On Tue, 24 Jul 2012 18:00:47 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: ... ??? Lol - well, what followed didn't transcribe too well. Interesting product - some time ago I looked at knocking up some C code to ship RMF data from the Distributor down to a Linux client so I could do a poor mans RMFIII. Ugly, seriously ugly to get big-endian binary data full of binary zeroes down a little-endian client. Had a play with Python for the GUI, but it was hard work. Then IBM announced the were planning on shipping the CIM server (I *did* say some time ago). Whoot !!!. Time passed, the world changed ... But there is a lot to be said for a properly constructed XML solution to this data -all of it, not just (some of) the RMF records. As an aside, I was also going to plug Barrys solution (lots of customers like that), but he got in first. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: useful? XML encoded SMF.
BMC do the SMF to XML in their performance product, that I played with a few years ago. Personally I prefer Barry's solution, as it just does it as is without XML, but I am biased having used it for more years than I care to remember. Paul G... -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shane Ginnane Sent: Wednesday, 25 July 2012 9:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: useful? XML encoded SMF. On Tue, 24 Jul 2012 18:00:47 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: ... ??? Lol - well, what followed didn't transcribe too well. Interesting product - some time ago I looked at knocking up some C code to ship RMF data from the Distributor down to a Linux client so I could do a poor mans RMFIII. Ugly, seriously ugly to get big-endian binary data full of binary zeroes down a little-endian client. Had a play with Python for the GUI, but it was hard work. Then IBM announced the were planning on shipping the CIM server (I *did* say some time ago). Whoot !!!. Time passed, the world changed ... But there is a lot to be said for a properly constructed XML solution to this data -all of it, not just (some of) the RMF records. As an aside, I was also going to plug Barrys solution (lots of customers like that), but he got in first. Shane ... -- 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
Re: useful? XML encoded SMF.
Paul: WHOH there... SMF is an issue but the MVS control blocks (especially the TSOe ones) are frozen in stone. While I would not want to talk on IBM's behalf the proverbial hell would have to freeze over before any TSO/e control block would/could be changed. Ed On Jul 24, 2012, at 10:45 AM, Paul Gilmartin wrote: On Tue, 24 Jul 2012 10:30:37 -0500, McKown, John wrote: 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. And if the SMF data themselves were kept in XML, obstacles to technological advances such as 64-bit addresses and usr iDs 7 characters would largely be removed. -- gil -- 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
Re: useful? XML encoded SMF.
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
Re: useful? XML encoded SMF.
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Tuesday, July 24, 2012 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: useful? XML encoded SMF. Don't hipster programmers prefer JSON these days? XML too verbose. OK, I'd accept JSON. I went with XML because IBM has System XML, which can use a zIIP (or is it a zAAP?). Also, nothing on z/OS uses JSON at present. And there are not as many tools, such a XSLT, to process JSON (yet). Also, those same hipster programmers are switching to NoSQL due to SQL being too slow (and likely too difficult). Curiously, VSAM could validly be called a NoSQL database. -- 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
Re: useful? XML encoded SMF.
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
Re: useful? XML encoded SMF.
You should look at SMF4U product. They do exactly what you want plus many, many other things. See: http://www.smf4u.eu/ -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: useful? XML encoded SMF.
MXG has MANY customers that have been DIRECTLY READING z/OS SMF DATA FILES from AIX and Unix and Linux and Windows platforms for years, without any changes required by IBM or any of the other 350 vendors whose SMF data we read. No download involved, read via ftp access, write only the output data of interest. With scores of GigaBytes of data, too. My experiments with XML suggest the data volume would be massively increased with no improvement in the end results. Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas TX 75229 214 351 1966 tel 214 350 3695 fax www.mxg.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: useful? XML encoded SMF.
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Tuesday, July 24, 2012 10:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: useful? XML encoded SMF. The case for offloading z/OS SMF processing from z/OS to Linux is not obvious to me. I could, indeed, martial any number of arguments for keeping performance analysis for a platform on that platform; but what we have here, I suspect, is a kind of enthusiasm that would be proof against all rational argument. John Gilmore, Ashland MA 01721 - USA In my case, it is strictly due to the lack of tools on z/OS. We used to have SAS and MXG. That was perfect. We then lost SAS due to cost. So we ran MXG on a PC running SAS. But that was then considered to be too expensive too. So we lost SAS and MXG. We now have _nothing_ and no money to buy anything. But management would still like to see graphs and charts. So we have a few HLASM in-house written programs. Which extract some information which is downloaded to a PC running Excel. Which is used to make the pretty pictures so beloved by management. In addition to this, our management is still pushing us to try to reduce our Group Capacity cap so that we will save even more money due to reduced license costs. So, if I could have XML formatted SMF data, I could easily download and process that on my Linux desktop. Because Linux, and the software I run on it, does not cost the company anything other than electricity to run the PC. And I have many tools on my Linux system which can process XML and then create graphs from the processd data. IOW, it is not enthusiasm ... against all rational argument, it is for my convience due to lack of money. If management didn't want the graphs, I wouldn't care one bit about SMF - XML. And yes, I could write it myself. But my manager is against that due to the necessity of our doing maintenance to any in house written code if IBM makes changes to an SMF record that we use. So, in reality, there is no real reason to think that IBM, and other vendors, would be interested in this. But dreaming is still free. -- 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
Re: useful? XML encoded SMF.
Isn't System XML limited to parsing of XML, not generation of XML. I could very well be wrong, but I seem to recall hearing/reading that somewhere. From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 24, 2012 9:59 AM Subject: Re: useful? XML encoded SMF. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Tuesday, July 24, 2012 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: useful? XML encoded SMF. Don't hipster programmers prefer JSON these days? XML too verbose. OK, I'd accept JSON. I went with XML because IBM has System XML, which can use a zIIP (or is it a zAAP?). Also, nothing on z/OS uses JSON at present. And there are not as many tools, such a XSLT, to process JSON (yet). Also, those same hipster programmers are switching to NoSQL due to SQL being too slow (and likely too difficult). Curiously, VSAM could validly be called a NoSQL database. -- 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
Re: useful? XML encoded SMF.
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Frank Swarbrick Sent: Tuesday, July 24, 2012 12:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: useful? XML encoded SMF. Isn't System XML limited to parsing of XML, not generation of XML. I could very well be wrong, but I seem to recall hearing/reading that somewhere. You are most likely correct. I haven't read up on it because we can't really use it. We only use XML in CICS/TS 4.1 running code which is compiled with Enterprise COBOL 3.4, using native COBOL verbs. From what I've read, this COBOL version does not use System XML. And, in any case, we don't have (and won't get) a zIIP or zAAP. I probably shouldn't have mentioned it. -- 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
Re: useful? XML encoded SMF.
I'd say generation of XML was pretty cheap. It's the parsing that's expensive. Cheers, Martin 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: Frank Swarbrick frank.swarbr...@yahoo.com To: IBM-MAIN@listserv.ua.edu, Date: 07/24/2012 06:14 PM Subject: Re: useful? XML encoded SMF. Sent by: IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Isn't System XML limited to parsing of XML, not generation of XML. I could very well be wrong, but I seem to recall hearing/reading that somewhere. From: McKown, John john.mck...@healthmarkets.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, July 24, 2012 9:59 AM Subject: Re: useful? XML encoded SMF. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Tuesday, July 24, 2012 10:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: useful? XML encoded SMF. Don't hipster programmers prefer JSON these days? XML too verbose. OK, I'd accept JSON. I went with XML because IBM has System XML, which can use a zIIP (or is it a zAAP?). Also, nothing on z/OS uses JSON at present. And there are not as many tools, such a XSLT, to process JSON (yet). Also, those same hipster programmers are switching to NoSQL due to SQL being too slow (and likely too difficult). Curiously, VSAM could validly be called a NoSQL database. -- 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 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
