LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (September 2009, week 4)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:         Fri, 25 Sep 2009 22:39:41 -0700
Reply-To:     RolandRB <rolandberry@HOTMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         RolandRB <rolandberry@HOTMAIL.COM>
Organization: http://groups.google.com
Subject:      Re: Who has got a clinical reporting system that runs from a
Comments: To: sas-l@uga.edu
Content-Type: text/plain; charset=ISO-8859-1

On Sep 26, 3:50 am, "Lou" <lpog...@hotmail.com> wrote: > ""Data _null_;"" <iebup...@GMAIL.COM> wrote in message > > news:ce1fb7450909251350j15e6bc52g15836c37f4fa2783@mail.gmail.com... > > > On 9/25/09, RolandRB <rolandbe...@hotmail.com> wrote: > > > But if you > > > have, say, a "core" macro to do descriptive stats and category counts > > > with percentages and it is flexible enough to supply its output in a > > > dataset then that gives you the chance to "validate" that macro and > > > then the other reporting macros can call on its services.and avoid the > > > complexity. It then allows you to have different sets of sas code/ > > > reporting macros for different clients that call these "core" macros > > > to do the work for them. > > > Your "core" macros are called PROCS. PROC SUMMARY, FREQ and REPORT > > come to mind. You will also need FORMAT and probably TRANSPOSE. > > > No macros required. > > It will probably come as no surprise that I agree with Data _null_ on this - > I've said repeatedly here and elsewhere that 90% or more of the macros I've > run up against in pushing 30 years using SAS are rubbish. They're > overcomplicated, slow to execute, impossible to debug, etc.

That matches with my own experience.

> As far as validating a core set of macros is concerned, in theory I suppose > that's possible. In practice, what I've seen is a set of validated macros > in a global library. For a particular project, the global library is copied > into the project macro library. And then happily amended to the point where > there are dozens of versions of each macro, all with the same name, all > doing something slightly different, and of course none of these variants > were ever "validated". In some cases, the validated version is never used.

I've seen that done.

> And when the organization updates the SAS version, or adopts a new release > of MS Office, or upgrades the OS, or worse yet makes a platform change (e.g. > from Windows to Unix) the macros have to be validated all over again because > all of these changes in the background can and do cause macros that worked > fine to fail, or worse yet to appear to function but give results different > from those before the change.

They really need a test platform such that if any changes to SAS or the platform software occur then the test suite is run again and compared directly against the results of the previous run.


Back to: Top of message | Previous page | Main SAS-L page