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 <shudder> 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=SASxxxx 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
