Date:         Thu, 11 Sep 2008 22:34:05 +1000
Reply-To:     Scott Bass <sas_l_739.at.yahoo.dot.com.dot.au@PESTO.CC.UGA.EDU>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         Scott Bass <sas_l_739.at.yahoo.dot.com.dot.au@PESTO.CC.UGA.EDU>
Subject:      Re: autoexec.sas and directory structure
Comments: To: sas-l@uga.edu

"Andy Andrews" <sas_andy@BOOSECAT.COM> wrote in message
news:200809102327.m8AKbqED019887@malibu.cc.uga.edu...
> Hi all,
>
> I'm working on getting our SAS environment set up (Windows environment).
> Our directory structure is essentially this:
>
> root\data                  * global datasets used for multiple studies
> root\mac                   * global macro library
> root\<study>               * study root
> root\<study>\data          * study data root
> root\<study>\data\raw
> root\<study>\data\derived
> root\<study>\docs          * docs root
> root\<study>\pgm           * pgm root
> root\<study>\pgm\adhoc
> root\<study>\pgm\metrics
> root\<study>\pgm\etc
>
> This is obviously VERY dummied-down.
>
> What we're looking to have is an autoexec.sas for each study.  It will be
> virtually the same for all studies, only modifying study name, code, etc.
> This autoexec.sas is to be located under the root\<study> directory.  This
> works perfectly for programs run from the root\<study> directory, however
> we want to use the same autoexec.sas for programs located in the
> root\<study>\pgm\adhoc, metrics, and etc directories (and really any
> directory within the study root).  I realize we can include it at the top
> of our programs, however we're looking to do it in a different manner in
> case of structure changes, environment changes, etc.  Is there a trick to
> do this?  In a previous life, this was handled with an outside process.

Hi Andrew,

I'm keying in on your statement "...virtually the same for all studies, only
modifying study name, code, etc."

Ideally, you would have one autoexec that could work for all studies.
Assuming that doesn't make it too complex and hard to maintain, that would
work well, right?

A couple things:

First, remember than your autoexec can in fact be a macro.  I've sometimes
had an autoexec like:

autoexec.sas...

%macro autoexec:
    whatever...;
%mend;
%autoexec

Sometimes it would be %autoexec(&sysparm), and I would have separate SAS
icons with different sysparms or %initstmts.

Remember that you can specify the autoexec when you invoke SAS.  It can be
in any location.

Another approach which I think works well is to have a control table
containing all desired parameters for your studies.  As a new study comes on
board, just edit your control table.  This table can also serve as useful
metadata for your study.

If your parametes lend themselves to name/value pairs, this works really
nicely.

Here is an example approach:

* create your control table ;
* note that the variable names are generic, i.e. name & value ;
* name is the macro variable name, and value is the macro variable value ;
* you can have any number of macro variables per study, and they can vary
between studies ;

* libndx is a special variable, and allows a "recursive" (well not really)
use of this table ;
* if you need more parameters for your libraries, make a 2nd table just for
your libraries ;
* the way I've coded it allows all your metadata in the one table, but this
might not be flexible enough ;

* notice you can embed macro variables in your table definition that get
resolved at runtime ;
* via the use of the resolve function ;

data control_table;
   length filter $20 name $32 value comments $200;
   infile datalines missover dlm="|";
   input filter name value;
   if filter ne '';
   datalines;
Study1         | name        | Study1
Study1         | location    | US
Study1         | foo         | bar
Study1         | libndx      | Study1_libs
Study1_libs    | librefA     | C:\Temp\Temp1
Study1_libs    | librefB     | C:\Temp\Temp2

Study2         | name        | &studyname
Study2         | location    | New Zealand         | Data with embedded
spaces
Study2         | libndx      | Study2_libs
Study2_libs    | librefC     | C:\Temp\Temp3
Study2_libs    | librefD     | C:\Temp\Temp4
;
run;



%macro get_parameters(data=control_table,filter=);
   proc sql noprint;
      select name into :list separated by " " from &data where
filter="&filter";
   quit;

   %symdel list / nowarn ;
   %global &list;
   data _null_;
      set &data;
      where filter="&filter";
      call symput(name,strip(resolve(value)));
   run;
%mend;

%macro get_libraries(data=control_table,filter=);
   data _null_;
      set &data;
      where filter="&filter";
      call execute("libname " || put(name,$8.) || ' "' ||
strip(resolve(value)) || '";');
   run;
%mend;

%get_parameters(filter=Study1)
%get_libraries(filter=&libndx)

%put &name &location;

* dynamic runtime value ;
%let studyname = Study2;

%get_parameters(filter=Study2)
%get_libraries(filter=&libndx)

%put &name &location;

Again, if you need more flexibility in your library allocations (different
engines, readonly, other options), create a separate control table for your
libraries vs. your macro variables.

Perhaps it will be possible to have one autoexec, with your dynamic data
maintained in a separate metadata table.

Hope this helps,
Scott