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
Content-Type: text/plain; charset=us-ascii
> From: Lou
> ""Fehd, Ronald J. (CDC/CCHIS/NCPHI)"" <rjf2@CDC.GOV> wrote in
> > 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.
** check usage of SASinitialFolder, set in either of:
* 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.
* 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:
and in each you name your autoexec.sas with the autoexec parameter
"...\SAS.exe" %* -autoexec autoexec-input.sas
"...\SAS.exe" %* -autoexec autoexec-process.sas
"...\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