Date:         Fri, 19 Oct 2007 15:48:32 -0400
Reply-To:     "Fehd, Ronald J. (CDC/CCHIS/NCPHI)" <rjf2@CDC.GOV>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "Fehd, Ronald J. (CDC/CCHIS/NCPHI)" <rjf2@CDC.GOV>
Subject:      Re: Overriding LIBNAME and FILENAME statements
In-Reply-To:  <39-dnemgBK-TaYranZ2dnUVZ_gednZ2d@comcast.com>
Content-Type: text/plain; charset=us-ascii

> From: Lou
> ""Fehd, Ronald J. (CDC/CCHIS/NCPHI)"" <rjf2@CDC.GOV> wrote in
> message
> news:2C6B65AAC3623140922DE580669C456A03B7A21D@LTA3VS001.ees.hhs.gov...
> > This is a problem I see with many users:
> >
> > 1. hard-coding lib- and file-name statements
> > 2. ... in every program!
> > 'correct' placement of most global statements:
> >
> > * title1
> > * filename
> > * libname
> >
> > is in the project autoexec.sas
>
> I would tend to agree with the first point, and somewhat
> strongly disagree with the second.  I'm not a fan of project
> autoexec.sas files which file gets auto-executed depends on
> where the SAS session was invoked.

factoids:

** check usage of SASinitialFolder, set in either of:

* icon
* project SASv9.cfg

> Many (most? all?) projects have programs which fall into more
> or less distinct functional classes - some read data,
> manipulate it in some way, and output datasets, others read
> data and produce some sort of report, etc.

agreed:
* input  : aka: read, import, etc
* process: aka: prepare
* output : aka: reporting

> I think that good
> form, perhaps especially during development when human error
> may be most likely to occur, would tailor the libname
> statements to the purpose of the program.  For example, a
> program that reads data from one library and writes data to
> another library would define access something along the lines of:

while I have only sas.bat
I could conceive of a few:
* SASin.bat
* SASproc.bat
* SASout.bat

and in each you name your autoexec.sas with the autoexec parameter

rem SASin.bat
"...\SAS.exe" %* -autoexec autoexec-input.sas

rem SASproc.bat
"...\SAS.exe" %* -autoexec autoexec-process.sas

rem SASout.bat
"...\SAS.exe" %* -autoexec autoexec-output.sas

> Putting libname statements in a project autoexec usually
> means giving all programs write access to all libraries
> whether they need it or not.

well, I have been educated by your comments.
my project development, as an Army of One,
has always been in one folder.

I understand from reading, both here and at SUGs,
that some other people are a bit more organized than me.
especially if they have many people in their Army of SAS programmers.

That is a Good Thing.

> Additionally, projects may sometimes write literally hundreds
> of output reports - putting all of the filename statements in
> the autoexec could be very unweildy. And sometimes programs
> may be run several times a day and the file name holding the
> output report has to dynamically change, perhaps by having
> the date and time be part of the file name.  I suppose you
> could do that with an autoexec definition, but it seems
> unnecessarily cumbersome to me.

as mentioned here yesterday
long root folder names can be consolidated by using either of:

* macro variables, everybody's favorite
* environment variables

> None of this solves the original problem - these definitions
> are embedded in the production code.  Short of changing the
> way Paul's shop writes programs, the only solution that
> occurs to me is to insert the test definitions into the code
> after the production definitions.  When testing is over,
> those lines can be deleted or commented out.

That is the problem that my answer was attempting to address.

You have only to ask a crowd of three programmers
who has ever left testing code enabled
when they returned code to production
and you will get a majority response of "... Yeah <sigh>"

I do not think
that thinking thru how to write programs
that can be switched easily from testing to production
is a non-trivial task.

The really hard task comes as a result
of not having taken the time to do that thinking.

... which was the way I read the original Q.

Ron Fehd  the macro maven  CDC Atlanta GA USA RJF2 at cdc dot gov