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>
Subject: Re: Who has got a clinical reporting system that runs from a
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
> > 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.