Fw: Decimal Floating Point, was: replacing SAS for SMF reports?
Rick, yes and no ... With the current PL/I compiler and with the DECIMAL(DFP) compiler option in effect, then "FLOAT DECIMAL" does mean DFP. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ibm3pg60/1.1.1.28 With earlier versions of the Pl/I compiler (or lower ARCH levels) this is NOT true. "Rick Fochtman" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > --- > I see what I did, whenever people talk about 'new floating point' I > always assume it is Decimal Floating Point (the one that is not > available in Java yet, or COBOL for that matter. z9 and PL/I and have > it) To make it more confusing both the Java binary float and the newer > DFP are both IEEE floating point! > --- > Don't confuse PL/1's FLOAT DECIMAL specification with the hardware > floating point decimal feature. They are NOT the same! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Decimal Floating Point, was: replacing SAS for SMF reports?
--- I see what I did, whenever people talk about 'new floating point' I always assume it is Decimal Floating Point (the one that is not available in Java yet, or COBOL for that matter. z9 and PL/I and have it) To make it more confusing both the Java binary float and the newer DFP are both IEEE floating point! --- Don't confuse PL/1's FLOAT DECIMAL specification with the hardware floating point decimal feature. They are NOT the same! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Decimal Floating Point, was: replacing SAS for SMF reports?
On 17 Jun 2008 11:29:21 -0700, in bit.listserv.ibm-main you wrote: >>>With reference modification available, the only things that are >>>awkward in COBOL are bit switches and the 1 byte binary fields. I >>>have written usage programs that parse the SMF 14/15, 30 and 64 >>>records. If IBM would just implement the data types in the 2002 >>>standard including the new floating point usages as IEEE, COBOL the >>>above caveats would go away and COBOL would play nicer with JAVA. >>>COMP-1 and COMP-2 could be retained for hex floating point so a single >>>COBOL program could have both types of floating point. YES there is a >>>SHARE requirement for this. >> >>Java does not have Decimal Floating Point yet, and COBOL already plays >>very nicely with automatic conversion from Java float to COBOL float >>and back again with direct calls. In any case, it is off topic, there >>is no Decimal Floating Point data in SMF records that I know of. > >Tom, I was referring to the IEEE floating point which IBM should have >supported using the new usages as soon as the 2002 standard became >final. The automatic conversion has a cost which should be not have >been incurred in the first place. For SMF, I was referring to the >USAGE BIT and USAGE BINARY-CHARACTER (if I recall it correctly). By >the way, when is COBOL going to support the decimal floating point? I see what I did, whenever people talk about 'new floating point' I always assume it is Decimal Floating Point (the one that is not available in Java yet, or COBOL for that matter. z9 and PL/I and have it) To make it more confusing both the Java binary float and the newer DFP are both IEEE floating point! http://www2.hursley.ibm.com/decimal/decimal.html One float is the one that Java has been using for years, and the newer one is Mike Cowlishaw's baby. That being said, we might not ever add the old IEEE floating point to COBOL, but we are looking at the possibility of adding the new DFP support to COBOL. Mike Cowlishaw feels that the COBOL 2002 Standard describes Desimal Floating Point, not the binary floating point that Java uses. Now I am so far off the original topic I changed the subject line! Now back to SMF records, we are also looking at adding USAGE BIT to COBOL as well, but people have been coding around that missing function in COBOL for years. Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
It would depend on your favorite tool of choice (Perl, etc), but it is very feasible to use Java to process SMF records, either on z/OS or on another platform, with the following combination of tools: - You can use the JZOS alphaWorks package to convert SMF record DSECTS into Java beans that map the fields and datatypes for the SMF records. (See the SMF 83 example included with JZOS) - You can use free Java reporting tools like JasperReports to do reporting - You can use Co:Z to offload processing of the data (binary, with RDWs) to another platform (See http://dovetail.com/docs/coz/cookbook.html#4_5 ) I agree that this would be a really nice open source project. We are willing to help by providing Java, JZOS, and Co:Z technical support if someone wants to tackle pieces of it. Feel free to use our forums: http://www.dovetail.com/forum/ Kirk Wolf Dovetailed Technologies On Fri, Jun 20, 2008 at 8:53 AM, McKown, John <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:[EMAIL PROTECTED] On Behalf Of Martin Packer > > Sent: Friday, June 20, 2008 8:30 AM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: replacing SAS for SMF reports? > > > > Perl got mentioned. I suspect the problem - if there IS a > > problem - is > > going to be VBS records. But then I don't know Perl. > > Can Perl read z/OS datasets? Or only UNIX files? If the latter, then > you'd need to either copy the SMF data to a UNIX file, or maybe use > Dovetail's "fromdsn" to pipe the dataset contents to the Perl script. In > either case, Perl is only going to see a stream of bytes. Which could be > a problem unless that stream includes the RDW (which fromdsn can do) so > that Perl will know how long each record is. I don't know if it is > possible to "reconstruct" SMF records into individual records if the RDW > is missing. I would also be a bit concerned with easy use of SMF/RMF > timestamps. That is the main reason that I love SAS for SMF/RMF > processing. > > > > > I have a side interest in "seeing modern stuff demonstrated > > on z/OS" and a > > German colleague whose whole "day job" appears to be the > > same. Maybe I > > should work with HIM to demo Perl going against SMF. Note: > > Perl would have > > to cope well with things like triplets. > > I think Perl could do this using the "substr" function, along with the > "unpack" function. That's what I do in REXX. > > > > > Any other languages need to be demo'ed against SMF? Or > > similar truculent > > data? :-) > > I did some work using Java, but a combination of lack of time and a > decrease in interest (it is difficult!) put the kabosh on that project. > > > > > Martin > > > > Martin Packer > > > -- > John McKown > Senior Systems Programmer > HealthMarkets > Keeping the Promise of Affordable Coverage > Administrative Services Group > Information Technology > > The information contained in this e-mail message may be privileged > and/or confidential. It is for intended addressee(s) only. If you are > not the intended recipient, you are hereby notified that any disclosure, > reproduction, distribution or other use of this communication is > strictly prohibited and could, in certain circumstances, be a criminal > offense. If you have received this e-mail in error, please notify the > sender by reply and delete this message without copying or disclosing > it. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Martin Packer > Sent: Friday, June 20, 2008 8:30 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: replacing SAS for SMF reports? > > Perl got mentioned. I suspect the problem - if there IS a > problem - is > going to be VBS records. But then I don't know Perl. Can Perl read z/OS datasets? Or only UNIX files? If the latter, then you'd need to either copy the SMF data to a UNIX file, or maybe use Dovetail's "fromdsn" to pipe the dataset contents to the Perl script. In either case, Perl is only going to see a stream of bytes. Which could be a problem unless that stream includes the RDW (which fromdsn can do) so that Perl will know how long each record is. I don't know if it is possible to "reconstruct" SMF records into individual records if the RDW is missing. I would also be a bit concerned with easy use of SMF/RMF timestamps. That is the main reason that I love SAS for SMF/RMF processing. > > I have a side interest in "seeing modern stuff demonstrated > on z/OS" and a > German colleague whose whole "day job" appears to be the > same. Maybe I > should work with HIM to demo Perl going against SMF. Note: > Perl would have > to cope well with things like triplets. I think Perl could do this using the "substr" function, along with the "unpack" function. That's what I do in REXX. > > Any other languages need to be demo'ed against SMF? Or > similar truculent > data? :-) I did some work using Java, but a combination of lack of time and a decrease in interest (it is difficult!) put the kabosh on that project. > > Martin > > Martin Packer -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Perl got mentioned. I suspect the problem - if there IS a problem - is going to be VBS records. But then I don't know Perl. I have a side interest in "seeing modern stuff demonstrated on z/OS" and a German colleague whose whole "day job" appears to be the same. Maybe I should work with HIM to demo Perl going against SMF. Note: Perl would have to cope well with things like triplets. Any other languages need to be demo'ed against SMF? Or similar truculent data? :-) Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] Twitter: MartinPacker 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
One might look at the product from NICUS at www.nicus.com It accepts many types of inputs to produce the results on a PC. I have not given the product a close look for I only bumped into it at an IT Financial conference a few weeks ago. It even has a toolkit for migrating NeuMics to MXG. jim -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Agree entirely. The biggest stumbling block is having up to date templates for all the SMF records. I have often thought that that would make a great open source project, Walter Medenbach. On Fri, Jun 20, 2008 at 10:19 AM, Ted MacNEIL <[EMAIL PROTECTED]> wrote: > >Perl provides both data manipulation and statistical functions and, off > the mainframe, is used to manipulate data before processing with R. > > Not to belittle your response, but is there a body of code to read SMF > data? > The issue is not the statistical/reporting capability, rather the ability > to read the raw data. > There are many packages better than SAS (as a SAS bigot) to report and > analyse, but how many can read? > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
>a perl module which provides some interesting z/OS I/O routines, one of which >is to generate SMF records. Nice, but I'm more concerned about reading SMF records. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Ted MacNEIL writes: >Not to belittle your response, but is there a body of >[perl] code to read SMF data?, It doesn't look like it. But (off on a bit of a tangent), Peter Prymmer wrote OS390::Stdio, a perl module which provides some interesting z/OS I/O routines, one of which is to generate SMF records. You can find it here: http://search.cpan.org/dist/OS390-Stdio/Stdio.pm There's a perl z/OS mailing list here: http://lists.cpan.org/showlist.cgi?name=perl-mvs - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
For what it's worth, I stumbled into this free download ("SMF Type 42
Parser for z/OS"):
http://www.ibm.com/developerworks/exchange/dw_entryView.jspa?externalID=531&categoryID=33
I can safely say it's not SAS, but it could be fun.
- - - - -
Timothy Sipples
IBM Consulting Enterprise Software Architect
Specializing in Software Architectures Related to System z
Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific
E-Mail: [EMAIL PROTECTED]
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
>Perl provides both data manipulation and statistical functions and, off the >mainframe, is used to manipulate data before processing with R. Not to belittle your response, but is there a body of code to read SMF data? The issue is not the statistical/reporting capability, rather the ability to read the raw data. There are many packages better than SAS (as a SAS bigot) to report and analyse, but how many can read? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Perl provides both data manipulation and statistical functions and, off the mainframe, is used to manipulate data before processing with R. It's part of the ported tools for USS www-03.ibm.com/servers/eserver/zseries/zos/unix/perl/index.html . It is nowhere near as fast as SAS but it is free and has a wide user base. Walter Medenbach On Tue, Jun 17, 2008 at 12:51 AM, McKown, John < [EMAIL PROTECTED]> wrote: > Well, it looks like SAS is pricing itself out of our range. Or > management is just doesn't think that we are getting our moneys worth or > ... > > Anyway, other than using HLASM or maybe COBOL, anybody have > any suggestions how to easily do some "ad hoc" type SMF reporting? What > would be really nice would be some sort of SMF to XML output program. I > really like the IRRADU00 output (RACF SMF data translated to XML). I > download that to my PC and run Java against it. If necessary, I could > even develop and test the Java code on my PC and run the application on > the mainframe once it is working. (or use Co:Z to ship the XML to my > Linux system and run the code there with the response going back to the > mainframe). > > -- > John McKown > Senior Systems Programmer > HealthMarkets > Keeping the Promise of Affordable Coverage > Administrative Services Group > Information Technology > > The information contained in this e-mail message may be privileged > and/or confidential. It is for intended addressee(s) only. If you are > not the intended recipient, you are hereby notified that any disclosure, > reproduction, distribution or other use of this communication is > strictly prohibited and could, in certain circumstances, be a criminal > offense. If you have received this e-mail in error, please notify the > sender by reply and delete this message without copying or disclosing > it. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Clark Morris writes: >I was referring to the IEEE floating point which IBM should have >supported using the new usages as soon as the 2002 standard became >final. Are you referring to the IEEE decimal floating point standard colloquially known as IEEE 754r? http://en.wikipedia.org/wiki/IEEE_754r IEEE 754r was finally approved last week (on June 12, 2008). - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
On 17 Jun 2008 11:29:21 -0700, in bit.listserv.ibm-main you wrote: >>With reference modification available, the only things that are >>awkward in COBOL are bit switches and the 1 byte binary fields. I >>have written usage programs that parse the SMF 14/15, 30 and 64 >>records. If IBM would just implement the data types in the 2002 >>standard including the new floating point usages as IEEE, COBOL the >>above caveats would go away and COBOL would play nicer with JAVA. >>COMP-1 and COMP-2 could be retained for hex floating point so a single >>COBOL program could have both types of floating point. YES there is a >>SHARE requirement for this. > >Java does not have Decimal Floating Point yet, and COBOL already plays >very nicely with automatic conversion from Java float to COBOL float >and back again with direct calls. In any case, it is off topic, there >is no Decimal Floating Point data in SMF records that I know of. Tom, I was referring to the IEEE floating point which IBM should have supported using the new usages as soon as the 2002 standard became final. The automatic conversion has a cost which should be not have been incurred in the first place. For SMF, I was referring to the USAGE BIT and USAGE BINARY-CHARACTER (if I recall it correctly). By the way, when is COBOL going to support the decimal floating point? > >Cheers, >TomR >> COBOL is the Language of the Future! << > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
o Java's float and double primitives are (ISO) binary floating point, but has the java.math.BigDecimal class, which is a decimal floating point representation ( n * 10**m, where n is arbitrary length integer, m is a 32 bit integer). The BigDecimal class can be used to represent any zoned or packed data without loss of precision. o Recent versions of the JZOS toolkit (on alphaWorks, SDK 6.0, or soon on SDK 5) include type converter classes (com.ibm.jzos.fields package) that convert Cobol datatypes to Java values. BTW: These classes are pure Java code and don't rely on z/OS apis. o The RecordClassGenerator class (available in the alphaWorks version of JZOS) can be used to read the ADATA output from the High Level Assembler or Enterprise Cobol Compiler and generate Java classes which use the above converters to map DSECTS or Cobol copy books into Java classes. Samples are included which show how SMF 83 DSECTS are automatically mapped into Java classes. For example, the following JCL generates a Java class which maps the base part of the SMF 83 record: //ASSEMBLE EXEC ASMAC,PARM='ADATA,LIST,NOTERM,NODECK,NOOBJECT' //C.SYSIN DD * IFASMFR 83 END //C.SYSADATA DD DSN=&&ADATA,DISP=(NEW,PASS), // SPACE=(CYL,(3,1)) //* //JAVA EXEC PROC=EXJZOSVM,VERSION='50' //MAINARGS DD * com.ibm.jzos.recordgen.asm.RecordClassGenerator section=SMFRCD83 bufoffset=false package=com.ibm.jzos.sample.fields class=Smf83BaseRecord //SYSADATA DD DSN=&&ADATA,DISP=(OLD,DELETE) //STDOUT DD PATH='/home/user/Smf83BaseRecord.java', // PATHOPTS=(OWRONLY,OCREAT), // PATHMODE=SIRWXU //STDENV DD * ... // For the JZOS alphaWorks downloads, see: http://www.alphaworks.ibm.com/tech/zosjavabatchtk Kirk Wolf Dovetailed Technologies On Tue, Jun 17, 2008 at 1:07 PM, Tom Ross <[EMAIL PROTECTED]> wrote: > >With reference modification available, the only things that are > >awkward in COBOL are bit switches and the 1 byte binary fields. I > >have written usage programs that parse the SMF 14/15, 30 and 64 > >records. If IBM would just implement the data types in the 2002 > >standard including the new floating point usages as IEEE, COBOL the > >above caveats would go away and COBOL would play nicer with JAVA. > >COMP-1 and COMP-2 could be retained for hex floating point so a single > >COBOL program could have both types of floating point. YES there is a > >SHARE requirement for this. > > Java does not have Decimal Floating Point yet, and COBOL already plays > very nicely with automatic conversion from Java float to COBOL float > and back again with direct calls. In any case, it is off topic, there > is no Decimal Floating Point data in SMF records that I know of. > > Cheers, > TomR >> COBOL is the Language of the Future! << > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
>With reference modification available, the only things that are >awkward in COBOL are bit switches and the 1 byte binary fields. I >have written usage programs that parse the SMF 14/15, 30 and 64 >records. If IBM would just implement the data types in the 2002 >standard including the new floating point usages as IEEE, COBOL the >above caveats would go away and COBOL would play nicer with JAVA. >COMP-1 and COMP-2 could be retained for hex floating point so a single >COBOL program could have both types of floating point. YES there is a >SHARE requirement for this. Java does not have Decimal Floating Point yet, and COBOL already plays very nicely with automatic conversion from Java float to COBOL float and back again with direct calls. In any case, it is off topic, there is no Decimal Floating Point data in SMF records that I know of. Cheers, TomR >> COBOL is the Language of the Future! << -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
>and/or CA MICS Not a good choice. MICS uses SAS. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
"Timothy Sipples" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED] om>... > "Ad hoc SMF reporting" might be a good fit for Tivoli Decision Support for > z/OS, with or without its various options (such as Usage and Accounting > Manager) depending on your requirements. > > I believe CA also has something in this category. My guess would be some > combination of CA SMF Director, CA JARS Resource Management, and/or CA MICS > Resource Management. Macro4's ExpeTune does at least some SMF reporting. I > suspect I'm forgetting other possibilities., > CA MICS requires that you have SAS. It is fully written in SAS. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
"So let it be written! So let it be done!" It was Pharaoh in 'The Ten Commandments' Crispin Hugo Systems Programmer Macro 4 Thanks for the thoughts. However what I (and my manager) think is totally irrelevant. Upper managements wants to cut costs. They have targetted SAS as something that is not mission critical (and I guess it isn't) and so it can be eliminated. "So let it be written! So let it be done!" (some movie that I cannot remember - what the king said when he made a decree.) -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 plc internal virus protection system. This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 plc internal virus protection system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Sipples > Sent: Tuesday, June 17, 2008 8:49 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: replacing SAS for SMF reports? > > "Ad hoc SMF reporting" might be a good fit for Tivoli > Decision Support for > z/OS, with or without its various options (such as Usage and > Accounting > Manager) depending on your requirements. > > I believe CA also has something in this category. My guess > would be some > combination of CA SMF Director, CA JARS Resource Management, > and/or CA MICS > Resource Management. Macro4's ExpeTune does at least some SMF > reporting. I > suspect I'm forgetting other possibilities., > > SAS, of course, is quite powerful and offers a lot of general purpose > flexibility. I'm quite fond of SAS having done some > substantial econometric > analysis with it. Arguably I received a better diploma thanks > to SAS, so I > guess I'm biased. > > I should ask if you've investigated a "penalty box" solution. > A typical > penalty box pattern is to have a disaster recovery system such as a > 2096-A01 (z9 BC) or 2086-110 (z890) with Capacity Backup > (CBU) protecting a > larger (and often growing) primary system. You might have > disk replication > between the two sites/systems so that it's easy to shuttle > SMF (and other) > data over to the other site. (Bonus points for Parallel > Sysplex or even > some form of GDPS.) Quite often you'd keep "N" level hardware > for primary > production (e.g. z9 BC) and "N-1" for disaster > recovery/penalty box (e.g. > z890). There are other patterns, and I'm also assuming here > that SMF report > processing is containable within a much smaller system capacity. > > Also, do you think the value of the SMF reports SAS delivers > matches up > with the cost? (How "real" is the problem, basically?) > > - - - - - > Timothy Sipples Thanks for the thoughts. However what I (and my manager) think is totally irrelevant. Upper managements wants to cut costs. They have targetted SAS as something that is not mission critical (and I guess it isn't) and so it can be eliminated. "So let it be written! So let it be done!" (some movie that I cannot remember - what the king said when he made a decree.) -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
"Ad hoc SMF reporting" might be a good fit for Tivoli Decision Support for z/OS, with or without its various options (such as Usage and Accounting Manager) depending on your requirements. I believe CA also has something in this category. My guess would be some combination of CA SMF Director, CA JARS Resource Management, and/or CA MICS Resource Management. Macro4's ExpeTune does at least some SMF reporting. I suspect I'm forgetting other possibilities., SAS, of course, is quite powerful and offers a lot of general purpose flexibility. I'm quite fond of SAS having done some substantial econometric analysis with it. Arguably I received a better diploma thanks to SAS, so I guess I'm biased. I should ask if you've investigated a "penalty box" solution. A typical penalty box pattern is to have a disaster recovery system such as a 2096-A01 (z9 BC) or 2086-110 (z890) with Capacity Backup (CBU) protecting a larger (and often growing) primary system. You might have disk replication between the two sites/systems so that it's easy to shuttle SMF (and other) data over to the other site. (Bonus points for Parallel Sysplex or even some form of GDPS.) Quite often you'd keep "N" level hardware for primary production (e.g. z9 BC) and "N-1" for disaster recovery/penalty box (e.g. z890). There are other patterns, and I'm also assuming here that SMF report processing is containable within a much smaller system capacity. Also, do you think the value of the SMF reports SAS delivers matches up with the cost? (How "real" is the problem, basically?) - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
John, We migrated from SAS (z/OS) to WPS last month at our (newly IBM) site. We only use SAS in batch, and we don't heavily use MXG's PDB processing, having TDS for that stuff. But we use MXG with WPS for some daily and 'Ad Hoc' reporting. For basic SAS processing, WPS is a fine replacement. Very little SAS code had to be adpated in our case. If you're using many graphic functions and/or ODS code, you might experience some gaps. Altough WPS is a young product, they're enhancing it intensively. Performance was dramatically enhanced in V2.3.1. On CPU consumption, WPS is twice as hungry as SAS. WPC's (http://www.teamwpc.co.uk/home) support is fine. If you need any other information, feel free to contact me off the list. >Date:Mon, 16 Jun 2008 09:51:12 -0500 >From:"McKown, John" <[EMAIL PROTECTED]> >Subject: replacing SAS for SMF reports? > >Well, it looks like SAS is pricing itself out of our range. Or >management is just doesn't think that we are getting our moneys worth or >... > >Anyway, other than using HLASM or maybe COBOL, anybody have >any suggestions how to easily do some "ad hoc" type SMF reporting? What >would be really nice would be some sort of SMF to XML output program. I >really like the IRRADU00 output (RACF SMF data translated to XML). I >download that to my PC and run Java against it. If necessary, I could >even develop and test the Java code on my PC and run the application on >the mainframe once it is working. (or use Co:Z to ship the XML to my >Linux system and run the code there with the response going back to the >mainframe). > >-- >John McKown >Senior Systems Programmer >HealthMarkets >Keeping the Promise of Affordable Coverage >Administrative Services Group >Information Technology > Regards, Coen Wessels _ IBM Suisse Centre de Compétence Bancaire Av. de la Vallombreuse 100 CH - 1008 Prilly Téléphone : +41 (0)27 327 4271 Mobile : +41 (0)78 803 2621 IBM : +41 58 333 46 07 Fax : +41 (0)27 327 4255 Mon adresse IBM est [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
On Mon, 16 Jun 2008 10:25:07 -0500, McKown, John <[EMAIL PROTECTED]> wrote: >That is a possibility as well and is being discussed. But then we'd need >a license for every desktop user (well, that's only 5 of us). But if >person#1 does the work most of the time, then it would be difficult for >person#2 to come in and take over while they are on vacation (or, in my >group, at the doctor's). > >-- We have a little batch process that fires up on our (single) MXG SAS PC every 10 mins during business hours and runs any 'ad hoc' work submitted by the users. Basically the user FTPs his request/program from the mainframe to the SAS PC. The SAS PC runs it and Emails the results back to the user. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Ted, For Windows it is nothing to do with the Hardware Platform - server or desktop, but rather the version of the OS you are using. Windows XP and VISTA are regarded as desktop products and pricing is based on that. Win 2003 is a server product and you will be charged a server price. This is the case even if the two OS run on the sane desktop or server. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Ted MacNEIL > Sent: Monday, June 16, 2008 5:34 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: [IBM-MAIN] replacing SAS for SMF reports? > > >One license and Remote Desktop? Surely you have a under utilized > Intell server some where in the machine room :) > > And, then you get into a server vs a desktop licence! > > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
>One license and Remote Desktop? Surely you have a under utilized Intell server >some where in the machine room :) And, then you get into a server vs a desktop licence! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
One license and Remote Desktop? Surely you have a under utilized Intell server some where in the machine room :) > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of McKown, John > Sent: Monday, June 16, 2008 8:25 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: replacing SAS for SMF reports? > > > -Original Message- > > From: IBM Mainframe Discussion List > > [mailto:[EMAIL PROTECTED] On Behalf Of Shane Ginnane > > Sent: Monday, June 16, 2008 10:20 AM > > To: IBM-MAIN@BAMA.UA.EDU > > Subject: Re: replacing SAS for SMF reports? > > > > I see customers stampeding to SAS/PC (or whatever it's called). > > Barry has some notes on how to get the SMF data up to the mickey-mouse > > servers - even the PDBs I hear. If you "pull" from the PC end, all the > > EBCDIC/ASCII, [big|small]- endian issues are resolved. > > Must be cheap too ... > > > > Have a look. > > > > Shane ... > > That is a possibility as well and is being discussed. But then we'd need > a license for every desktop user (well, that's only 5 of us). But if > person#1 does the work most of the time, then it would be difficult for > person#2 to come in and take over while they are on vacation (or, in my > group, at the doctor's). > > -- > John McKown > Senior Systems Programmer > HealthMarkets > Keeping the Promise of Affordable Coverage > Administrative Services Group > Information Technology > > The information contained in this e-mail message may be privileged > and/or confidential. It is for intended addressee(s) only. If you are > not the intended recipient, you are hereby notified that any disclosure, > reproduction, distribution or other use of this communication is > strictly prohibited and could, in certain circumstances, be a criminal > offense. If you have received this e-mail in error, please notify the > sender by reply and delete this message without copying or disclosing > it. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
On 16 Jun 2008 13:16:44 -0700, in bit.listserv.ibm-main you wrote: >> -Original Message- >> From: IBM Mainframe Discussion List >> [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman >> Sent: Monday, June 16, 2008 3:04 PM >> To: IBM-MAIN@BAMA.UA.EDU >> Subject: Re: replacing SAS for SMF reports? >[snip] >> Let me point out that PL/1 lends itself very nicely to >> processing of SMF >> data, with offset variables, etc. It's a little more work >> than just SAS >> processing, but the various data types in PL/1 can map SMF data >> variables very nicely. SAS was very effectively priced out of >> our shop >> long ago, and they were not willing to negotiate at all on >> the pricing >> issue. >> > >I would love to try C or PL/I. But all we have are HLASM and COBOL. Oh, >and the current "freebies" such as Java (which nobody but me has much >familiarity with), REXX, Perl, and maybe some others. With reference modification available, the only things that are awkward in COBOL are bit switches and the 1 byte binary fields. I have written usage programs that parse the SMF 14/15, 30 and 64 records. If IBM would just implement the data types in the 2002 standard including the new floating point usages as IEEE, COBOL the above caveats would go away and COBOL would play nicer with JAVA. COMP-1 and COMP-2 could be retained for hex floating point so a single COBOL program could have both types of floating point. YES there is a SHARE requirement for this. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Barry A Schwarz wrote on 06/16/2008 02:15:19 PM: > If you post a message with DFSORT and SMF in the title, I'll Frank will > respond with some suggestions if not a complete example. > > -Original Message- > From: McKown, John [mailto:snip] > Sent: Monday, June 16, 2008 2:03 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: replacing SAS for SMF reports? > > I don't know how to process repeating groups in ICETOOL. Or other > advanced SMF records which do not have fixed offsets. DFSORT/ICETOOL has some formats for handling "special" SMF fields, but it doesn't have any built-in features for handling "triplets" or the complex record types SMF builds. It only handles "linear" records. You would have to be able to address the fields you want by their linear starting positions in order to use DFSORT/ICETOOL for that kind of processing. That said, FWIW, here's a couple of simple ICETOOL examples for SMF records from "z/OS DFSORT Application Programming Guide": http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CA20/6.7.5.12?SHELF=&DT=20060615185603&CASE= http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ICE1CA20/6.7.5.13?SHELF=&DT=20060615185603&CASE= I think Martin Packer might have done some "tinkering" with using DFSORT/ICETOOL for SMF reports, so maybe he has something to add on the subject. Frank Yaeger - DFSORT Development Team (IBM) - [EMAIL PROTECTED] Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration => DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
If you post a message with DFSORT and SMF in the title, I'll Frank will respond with some suggestions if not a complete example. -Original Message- From: McKown, John [mailto:snip] Sent: Monday, June 16, 2008 2:03 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: replacing SAS for SMF reports? I don't know how to process repeating groups in ICETOOL. Or other advanced SMF records which do not have fixed offsets. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
And, also, consider the analytic data processing requirement for summary- level reports, both on-the-fly from your detail and and also with using a permanent trending data base of some type. An underlying database engine / technology would need to be factored into any replacement initiative, such as SQL Server. Additional considerations such as data-volume and "subject matter expertise for SMF data record structures" should present some interesting discussion with management when considering replacement solution auditability, if such a policy/process exists. Of course, business decisions for capacity planning and service quality warrant credible, validated information resources, correct? Whatever happens, be sure to get any management acceptance / concurrence, in writing for the history books. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
>So I, personally, wouldn't recommend moving away from products that manipulate >the data. The OP doesn't want to move. He has been 'told' to move. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Schwarz, Barry A > Sent: Monday, June 16, 2008 4:01 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: replacing SAS for SMF reports? > > Have you considered DFSORT and ICETOOL? I don't know how to process repeating groups in ICETOOL. Or other advanced SMF records which do not have fixed offsets. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Have you considered DFSORT and ICETOOL? -Original Message- From: McKown, John [mailto:snip] Sent: Monday, June 16, 2008 1:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: replacing SAS for SMF reports? I would love to try C or PL/I. But all we have are HLASM and COBOL. Oh, and the current "freebies" such as Java (which nobody but me has much familiarity with), REXX, Perl, and maybe some others. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Usually we don't choose to move away from good products like SAS or from 3rd party performance monitors. It is usually a Management decision to lower costs at any cost that forces us to go back to basic analysis/reporting, often done in freebie languages (FORTRAN-G, PL/I-F, Rexx, etc) And training for knowing what to do with the data? That training budget was eliminated 15 years ago. /Tom Kern On Mon, 16 Jun 2008 21:40:43 +0100, Martin Packer <[EMAIL PROTECTED]> wrote: >It's not the ability to map SMF data that counts here - for anyone >considering doing this in a programming language other than SAS (or indeed >replacing ANY commercial SMF analysis product). It's the "intellectual >capital" involved in knowing what to do with the data. > >So I, personally, wouldn't recommend moving away from products that >manipulate the data. Unless you have an issue with their ability to "do >the right thing" with the specific SMF data in question. It would seem to >me to be moving away from the "folklore" pack and into shark-infested >waters on your own. :-) > >Martin > >Martin Packer >Performance Consultant >IBM United Kingdom Ltd >+44-20-8832-5167 >+44-7802-245-584 >[EMAIL PROTECTED] > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
It's not the ability to map SMF data that counts here - for anyone considering doing this in a programming language other than SAS (or indeed replacing ANY commercial SMF analysis product). It's the "intellectual capital" involved in knowing what to do with the data. So I, personally, wouldn't recommend moving away from products that manipulate the data. Unless you have an issue with their ability to "do the right thing" with the specific SMF data in question. It would seem to me to be moving away from the "folklore" pack and into shark-infested waters on your own. :-) Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman > Sent: Monday, June 16, 2008 3:04 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: replacing SAS for SMF reports? [snip] > Let me point out that PL/1 lends itself very nicely to > processing of SMF > data, with offset variables, etc. It's a little more work > than just SAS > processing, but the various data types in PL/1 can map SMF data > variables very nicely. SAS was very effectively priced out of > our shop > long ago, and they were not willing to negotiate at all on > the pricing > issue. > I would love to try C or PL/I. But all we have are HLASM and COBOL. Oh, and the current "freebies" such as Java (which nobody but me has much familiarity with), REXX, Perl, and maybe some others. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Well, it looks like SAS is pricing itself out of our range. Or management is just doesn't think that we are getting our moneys worth or ... Anyway, other than using HLASM or maybe COBOL, anybody have any suggestions how to easily do some "ad hoc" type SMF reporting? What would be really nice would be some sort of SMF to XML output program. I really like the IRRADU00 output (RACF SMF data translated to XML). I download that to my PC and run Java against it. If necessary, I could even develop and test the Java code on my PC and run the application on the mainframe once it is working. (or use Co:Z to ship the XML to my Linux system and run the code there with the response going back to the mainframe). --- Let me point out that PL/1 lends itself very nicely to processing of SMF data, with offset variables, etc. It's a little more work than just SAS processing, but the various data types in PL/1 can map SMF data variables very nicely. SAS was very effectively priced out of our shop long ago, and they were not willing to negotiate at all on the pricing issue. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
> From Longnecker, Dennis > Sent: Monday, June 16, 2008 10:33 AM > > > I keep telling myself I need to look closer at this . . . . > > http://en.wikipedia.org/wiki/World_Programming_System > > > This product is now marketed by IBM. In 2005 Barry Merrill started testing his MXG code against the WPS system. At that time he felt the system was still "vapor ware". It appears to be improving over the years. Barry continues to test MXG against it, and the progress is recorded in the NEWSLTRS member of MXG.SOURCLIB (Search for WPS). From the way I read the NEWSLTRS member Barry will support running MXG on WPS under certain conditions. For example, if your MXG run abends you need to call WPS first. If WPS then says the problem is in the MXG code, you need to send everything to Barry. He'll run it using SAS instead of WPS, and if the abend still occurs he'll check it out. If anyone is thinking of getting WPS to replace SAS I would get an agreement that you can do through acceptance testing before signing a contract. Especially if you are using more advanced functions of SAS like creating graphs, html, and PDF files and putting them on the HFS system using SAS ODS, or if you're doing any heavy macro processing. * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
On Mon, 16 Jun 2008 18:41:40 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >Yes, but. >Neither MXG, nor (neu)MICS, support WPS. Not yet.both Merrill and CA have announced they have current WPS initiatives. And Dr. Merrill's R&D team has taken it a step further integrating some initial WPS-related support parameters into the current/recent maintenance versions, along with published DOC on WPS support experiences. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
>I keep telling myself I need to look closer at this . . . . >http://en.wikipedia.org/wiki/World_Programming_System Yes, but. Neither MXG, nor (neu)MICS, support WPS. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
John, Buying single user licenses is probably the most expensive way to get SAS for Windows. If you have 5 people that will use SAS then get a five user license. If a single user license is all the budget can take, then a method I use with my team is to load SAS for Windows onto a fairly heavy duty PC and Remote Desktop to it. One immediate advantage is that compute intensive SAS procs run in the background without slowing up your desktop/laptop. We have plenty of licenses, but it means we don't have to run the big stuff on our laptops. It also means that person #2 can very easily take over from person #1. Person #2 just uses Remote Desktop to get to the Workstation when person #1 is away. You can also share time on the same workstation as SAS can run multiple sessions. If Person # 1 is halfway through something, person # 2 can take the workstation and start a different SAS session without killing off person #1's work in progress. If you company has blade servers than it may be easy to get blade for yourself and load up XP, SAS and MXG. I've been using iSCSI to HDS 9500 rack & stack storage, and the FTP access method to read SMF directly from the z/OS LPARs. No Fibre Channel and no File transfers required - just a PDB served on a platter. If you get pricing make sure you get the SAS for Windows pricing and not the Server version. The price difference is substantial. Oh, and once you have used the GUI on SAS for Windows you will never want to go back to the MF version. Ron > > That is a possibility as well and is being discussed. But then we'd > need > a license for every desktop user (well, that's only 5 of us). But if > person#1 does the work most of the time, then it would be difficult for > person#2 to come in and take over while they are on vacation (or, in my > group, at the doctor's). > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
On Mon, 16 Jun 2008 09:51:12 -0500, McKown, John <[EMAIL PROTECTED]> wrote: >Well, it looks like SAS is pricing itself out of our range. Or >management is just doesn't think that we are getting our moneys worth or >... > >Anyway, other than using HLASM or maybe COBOL, anybody have >any suggestions how to easily do some "ad hoc" type SMF reporting? What >would be really nice would be some sort of SMF to XML output program. I >really like the IRRADU00 output (RACF SMF data translated to XML). I >download that to my PC and run Java against it. If necessary, I could >even develop and test the Java code on my PC and run the application on >the mainframe once it is working. (or use Co:Z to ship the XML to my >Linux system and run the code there with the response going back to the >mainframe). > >-- >John McKown >Senior Systems Programmer >HealthMarkets >Keeping the Promise of Affordable Coverage >Administrative Services Group >Information Technology > >The information contained in this e-mail message may be privileged >and/or confidential. It is for intended addressee(s) only. If you are >not the intended recipient, you are hereby notified that any disclosure, >reproduction, distribution or other use of this communication is >strictly prohibited and could, in certain circumstances, be a criminal >offense. If you have received this e-mail in error, please notify the >sender by reply and delete this message without copying or disclosing >it. > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO >Search the archives at http://bama.ua.edu/archives/ibm-main.html I sometimes encounter these "emotional" management attempts to excercise cost-containment before really understanding the time and effort that would be needed to replace (and maintain / update as technology changes) SAS and all surrounding application code. My recommendation is to survey your SAS users and generate a concise list of the SAS Base and other optional components being used today at your site which may help educate and enlighten management about what SAS really provides the enterprise. SAS can generate a SMF record to identify specific component-level usage (PROCs) and some more basic SMF 14/15 information and/or PGM=SAS software program usage in batch can also help pinpoint the SAS application users for management to ask pertinent questions, like "do you have time and budget to replace your existing SAS application functionality today or at a minimum do without whatever it is that SAS provides your group so you can do your job?" SAS has some very powerful facilities, imbedded in the SAS Base product, for generating visually-stimulating web, PDF, and other report/chart outputs. Also, there are some SAS DATA step functions you just can't do with ANSI SQL, frankly. And the point raised about WPS' solution as a SAS replacement, really should be given serious consideration as that product evolves and improves, rather than basing any opinions on past experiences. Lastly, since January 2007, SAS Institute will in fact negotiate with its clients, so you are encouraged to gather your stats (using SAS, likely) on how SAS is being used, where it's being used, and state what your enterprise is willing to do to consolidate that usage, ideally to a sub-capacity LPAR. It's up to the client to formulate this type of pitch, to the point that you will need to tell SAS what you're willing to pay for some "reasonable amount" of their software capacity. Toss in some licenses for a few Windows / AIX/ *nix servers and some desktops, and make it worth the discussion with your account rep. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
I have a hard time reading the documentation too. I think it was written by statisticians for statisticians. Maybe if some really high-powered people who know how to do this kind of data manipulation/statistics were to start working in R or W and made some sample code public, then the rest of us can start with the samples to explore the capabilities. I would never have tried SAS for SMF processing if I had not seen Barry Merrill's code. Thank you Barry, you saved lots of weeks/months of effort and ulcers. /Tom Kern On Mon, 16 Jun 2008 10:56:22 -0500, McKown, John <[EMAIL PROTECTED]> wrote: > >I do have R loaded on my Linux PC. But I haven't had time to really look >at it. Also, I cannot seem to find any easy to read documentation. > >-- >John McKown >Senior Systems Programmer >HealthMarkets >Keeping the Promise of Affordable Coverage >Administrative Services Group >Information Technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
On Mon, 16 Jun 2008 10:52:03 -0500, Thomas Kern wrote: >If you can get the SMF data into a usable format and get it down to PCs, you >might try this R statistical/graphing package: > >http://www.r-project.org/ > And: > From: "Longnecker, Dennis" > > >http://en.wikipedia.org/wiki/World_Programming_System >On Mon, 16 Jun 2008 09:51:12 -0500, McKown, John wrote: > >>Well, it looks like SAS is pricing itself out of our range. Or >>management is just doesn't think that we are getting our moneys worth or >>... >> So, is it plausible that with competition from R and W looming on the horizon, SAS is planning to maintain its level of revenue by increasing its rates? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern > Sent: Monday, June 16, 2008 10:52 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: replacing SAS for SMF reports? > > If you can get the SMF data into a usable format and get it > down to PCs, you > might try this R statistical/graphing package: > > http://www.r-project.org/ > > /Tom Kern I do have R loaded on my Linux PC. But I haven't had time to really look at it. Also, I cannot seem to find any easy to read documentation. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
If you can get the SMF data into a usable format and get it down to PCs, you might try this R statistical/graphing package: http://www.r-project.org/ /Tom Kern On Mon, 16 Jun 2008 09:51:12 -0500, McKown, John <[EMAIL PROTECTED]> wrote: >Well, it looks like SAS is pricing itself out of our range. Or >management is just doesn't think that we are getting our moneys worth or >... > >Anyway, other than using HLASM or maybe COBOL, anybody have >any suggestions how to easily do some "ad hoc" type SMF reporting? What >would be really nice would be some sort of SMF to XML output program. I >really like the IRRADU00 output (RACF SMF data translated to XML). I >download that to my PC and run Java against it. If necessary, I could >even develop and test the Java code on my PC and run the application on >the mainframe once it is working. (or use Co:Z to ship the XML to my >Linux system and run the code there with the response going back to the >mainframe). > >-- >John McKown >Senior Systems Programmer >HealthMarkets >Keeping the Promise of Affordable Coverage >Administrative Services Group >Information Technology -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
Quoting "McKown, John": > (or, in my group, at the doctor's). Huh ???. You work for a place called HealthMarkets ... Shouldn't the quack come to *YOU* (in your cubicle) as a perk of the job ???... Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
I keep telling myself I need to look closer at this . . . . http://en.wikipedia.org/wiki/World_Programming_System -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, June 16, 2008 7:51 AM To: IBM-MAIN@BAMA.UA.EDU Subject: replacing SAS for SMF reports? Well, it looks like SAS is pricing itself out of our range. Or management is just doesn't think that we are getting our moneys worth or ... Anyway, other than using HLASM or maybe COBOL, anybody have any suggestions how to easily do some "ad hoc" type SMF reporting? What would be really nice would be some sort of SMF to XML output program. I really like the IRRADU00 output (RACF SMF data translated to XML). I download that to my PC and run Java against it. If necessary, I could even develop and test the Java code on my PC and run the application on the mainframe once it is working. (or use Co:Z to ship the XML to my Linux system and run the code there with the response going back to the mainframe). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
> -Original Message- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of Shane Ginnane > Sent: Monday, June 16, 2008 10:20 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: replacing SAS for SMF reports? > > I see customers stampeding to SAS/PC (or whatever it's called). > Barry has some notes on how to get the SMF data up to the mickey-mouse > servers - even the PDBs I hear. If you "pull" from the PC end, all the > EBCDIC/ASCII, [big|small]- endian issues are resolved. > Must be cheap too ... > > Have a look. > > Shane ... That is a possibility as well and is being discussed. But then we'd need a license for every desktop user (well, that's only 5 of us). But if person#1 does the work most of the time, then it would be difficult for person#2 to come in and take over while they are on vacation (or, in my group, at the doctor's). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
In a message dated 6/16/2008 9:51:37 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: download that to my PC and run Java against it. If necessary, I could even develop and test the Java code on my PC and run the application on the mainframe once it is working. (or use Co:Z to ship the XML to my Linux system and run the code there with the response going back to the mainframe). >> Didn't have much luck with JAVA RMF under Windoze, maybe it works better on Linux? _http://www-03.ibm.com/servers/eserver/zseries/zos/rmf/rmfhtmls/pmweb/pmweb.ht ml_ (http://www-03.ibm.com/servers/eserver/zseries/zos/rmf/rmfhtmls/pmweb/pmweb.html) Anyway, won't SAS run on Linux? Seems that would be cheapest. Do what you've been doing just do it on the PC. Dr. Merrill has examples at _www.mxg.com_ (http://www.mxg.com) on how to process SMF data on the PC. **Vote for your city's best dining and nightlife. City's Best 2008. (http://citysbest.aol.com?ncid=aolacg0005000102) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
I see customers stampeding to SAS/PC (or whatever it's called). Barry has some notes on how to get the SMF data up to the mickey-mouse servers - even the PDBs I hear. If you "pull" from the PC end, all the EBCDIC/ASCII, [big|small]- endian issues are resolved. Must be cheap too ... Have a look. Shane ... Quoting "McKown, John" : > Well, it looks like SAS is pricing itself out of our range. Or > management is just doesn't think that we are getting our moneys worth > or > ... > > Anyway, other than using HLASM or maybe COBOL, anybody > have any suggestions how to easily do some "ad hoc" type SMF reporting? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: replacing SAS for SMF reports?
John, You might also consider using the Assembler DSECT mapping support that is available in the alphaWorks version of JZOS. With it, you can generate Java record mapping classes from Assembler DSECT and then process the records using a Java program. See: http://www.alphaworks.ibm.com/tech/zosjavabatchtk The Java program could either run on z/OS, or you could still use Co:Z to ship the raw SMF records to Linux and run the Java processing program there. Other than Java, you could use "C" and use the z/OS C++ "CDSECT" compiler utility that converts a DSECT into C header files. FWIW: here's example JCL that dumps SMF and offloads processing of it using Co:Z. Our download site has a sample C program, but you could also use Java. http://dovetail.com/docs/coz/cookbook.html#4_5 Kirk Wolf Dovetailed Technologies On Mon, Jun 16, 2008 at 9:51 AM, McKown, John <[EMAIL PROTECTED]> wrote: > Well, it looks like SAS is pricing itself out of our range. Or > management is just doesn't think that we are getting our moneys worth or > ... > > Anyway, other than using HLASM or maybe COBOL, anybody have > any suggestions how to easily do some "ad hoc" type SMF reporting? What > would be really nice would be some sort of SMF to XML output program. I > really like the IRRADU00 output (RACF SMF data translated to XML). I > download that to my PC and run Java against it. If necessary, I could > even develop and test the Java code on my PC and run the application on > the mainframe once it is working. (or use Co:Z to ship the XML to my > Linux system and run the code there with the response going back to the > mainframe). > > -- > John McKown > Senior Systems Programmer > HealthMarkets > Keeping the Promise of Affordable Coverage > Administrative Services Group > Information Technology > > The information contained in this e-mail message may be privileged > and/or confidential. It is for intended addressee(s) only. If you are > not the intended recipient, you are hereby notified that any disclosure, > reproduction, distribution or other use of this communication is > strictly prohibited and could, in certain circumstances, be a criminal > offense. If you have received this e-mail in error, please notify the > sender by reply and delete this message without copying or disclosing > it. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
replacing SAS for SMF reports?
Well, it looks like SAS is pricing itself out of our range. Or management is just doesn't think that we are getting our moneys worth or ... Anyway, other than using HLASM or maybe COBOL, anybody have any suggestions how to easily do some "ad hoc" type SMF reporting? What would be really nice would be some sort of SMF to XML output program. I really like the IRRADU00 output (RACF SMF data translated to XML). I download that to my PC and run Java against it. If necessary, I could even develop and test the Java code on my PC and run the application on the mainframe once it is working. (or use Co:Z to ship the XML to my Linux system and run the code there with the response going back to the mainframe). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
