Date:         Fri, 25 Sep 2009 22:35:57 -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 25, 10:50 pm, iebup...@GMAIL.COM ("Data _null_;") wrote:
> 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.

Those procedures are in the "core" macros, for sure. Proc univariate
as well. But why have multiple programs calling proc univariate and
proc freq to combine descriptive statistics with p-values, for
example? Each of these programs would have to be "validated". It would
surely make more sense to limit such calculations to one program/macro
that could serve all the other reporting code and then this single
program/macro could be validated such that you could rely on its
results being correct and so cut down the time of validating the
reporting code that calls it.