Date: Fri, 21 May 2004 08:40:18 -0400
Reply-To: Peter Crawford2 <peter.crawford@BLUEYONDER.CO.UK>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Peter Crawford2 <peter.crawford@BLUEYONDER.CO.UK>
Subject: Re: How to set up libnames and filenames with a twist
to add another twist seems "on- topic", so may I add the suggestion
that environment variables very conveniently support structuring
the association of paths with logical references (lib- and filenames)
In sas9 the winXX platforms support the very convenient hierarchy
of default configs in unix, namely
site in folder !sasroot
personal in user's home folder
application in the "current" folder
Discovering sasv9.cfg in any of these locations, all will be used.
Alternatively, the command line can define one or more config files,
but then the search for config files (in sasroot, home and current
folders) is not made.
In sas9, the default, site sasv9.cfg demonstrates use of nested config.
That method could be used in the current folder, to call a standard
structure, after pointing at the project root
like:
/* sasv9.cfg in project startup folder */
-set projRoot /apps/anal/sys/myWork
/* invoke standard environment vars */
-config /apps/common/structure.cfg
-sasautos (sasautos)
-fmtsearch ( )
-insert sasautos macros
-insert fmtsearch formats
/* structure.cfg in /apps/common */
/* regular layouts for standard projects */
-set DOC !projRoot/doc
-set MASTER !projRoot/master
-set RAW !projRoot/raw_files
-set formats !projRoot/formats
-set code !projRoot/code
-set MACROS !code/macros
-set incl !code/programs
-set templat !code/models
Of course, there needs to be trade-off between projects, as well as
common ground for site-based add-ons (like very-common macros)
Although each site has its preferred organisation, there will be
much consistency within. The hierarchy of configs and their calls
simplify this usage of environment variables greatly.
The above use of -insert seems not well known, but is very
convenient for sharing and mixing sas-supplied macros with
site- and project-specific macros. Similarly, it makes sharing
user-defined formats much simpler.
These features work also in SAS8.2 in unix
On windows the -insert and multiple configs work, but not the
search through current and home folders, IIRC.
Good luck
Peter Crawford
On Wed, 19 May 2004 13:33:00 -0400, Lex Jansen <spam@LEXJANSEN.COM> wrote:
>By setting up a standard folder structure, you will not have to hardcode
>libnames.
>You can set up a standard (central) autoexec.sas, that will take care of
>standard libnames.
>If you have a standard structure libnames can be relative, like (in
Windows)
>LIBNAME SAVE "..\SAVE";
>Again, this will only work if you work in standard structure. In the
>environment I work in (about 100 users) they only have to define libnames
>when they combine data of different trials.
>
>Part of our LOG file looks like:
>
>Study specific libnames:
>
>DOC = N:\PROJECTS\XXX\YYYY\DOC
>INPUT = N:\PROJECTS\XXX\YYYY\INPUT ACCESS=READONLY
>MASTER = N:\PROJECTS\XXX\YYYY\MASTER
>LIBRARY = N:\PROJECTS\XXX\YYYY\MASTER
>NOMASTER = N:\PROJECTS\XXX\YYYY\NOMASTER
>VALIDATE = N:\PROJECTS\XXX\YYYY\VALIDATE
>RELEASE = N:\PROJECTS\XXX\YYYY\_USER
>CURRENT = N:\PROJECTS\XXX\YYYY\_USER
>
>All these libnames are defined in the AUYOEXEC by a macro call like:
>
>%_SetLib(INPUT, ..\input, ACCESS=READONLY));
>
>Also be aware of the following when you use UNC names instead of drives:
>
><SASNOTE>
>http://support.sas.com/techsup/unotes/SN/005/005018.html
>
>Using Universal Naming Convention (UNC) versus mapped drive letters slows
>down performance
>
>When you use Universal Naming Convention (UNC) versus using mapped drive
>letters, your performance slows.
>UNC names renegotiate the network connection for every process, so UNC
>drives take longer than a mapped drive connection.
>This slowdown is not a SAS problem but a network card/driver issue,
>specifically the redirector.
>
>Contact the vendor of your network card to see if there is a way to
increase
>the performance.
>
>If you use Novell Client 32 v4.71 redirector, Novell has an article called
>"15 second delay when running a UNC to a server".
>Go to www.novell.com and search on "15 second delay unc".
>
></SASNOTE>
>
>Lex Jansen
>
>
>"Lou" <lpogodajr292185@comcast.net> wrote in message
>news:ouqdnWH1ePzf_DTdRVn-vg@comcast.com...
>> First suggestion - Using mapped drive letters for network addresses
means
>> the program will only perform as expected on machines with identical
>> mapping. Unless your place uses rigidly enforced mappings across all
>> machines, this can lead to unexpected results
>>
>> Second suggestion - For many (most?) file applications, there's no need
to
>> separately issue filename statements for each file. Directories (or
>> folders, if you prefer) are "aggregate storage locations" and individual
>> files can be accessed along the lines of the following:
>>
>> filename in '\\servername\level1a\level1b\level1c';
>> filename out '\\servername\level2a\level2b\level2c';
>> data fee;
>> infile in(your input file name here);
>> file out(your output file name here);
>>
>> Third suggestion - though libnames and filenames are usually given as
>> absolute addresses, you can use relative addresses for both. If a
project
>> is located in a folder on a network drive with different components
>> distributed in various subfolders, you can change the current folder to
>that
>> project folder and then use relative addresses to each component. For
>> instance, this example switches the current folder to the root on the C
>> drive, but it could just as easily switch to a network folder.
>>
>> x 'cd c:\';
>> filename in 'all data\test.txt';
>> libname out 'all data';
>> data out.test;
>> infile in pad;
>> input @1 string $50.;
>>
>> run;
>>
>> The above example reads a text file with the full address of "C:\all
>> data\test.txt" and writes an output data set with the name "test" to
>folder
>> "C:\all data". If you use dot (.) for the current directory and
>double-dot
>> (..) for the directory one level up from the current directory in the
>> filename or libname statements, you can step up and down the folder
>> hierarchy.
>>
>> Much neater, in my opinion, than macro variables.
>>
>> "Kevin F. Spratt" <kevin-spratt@UIOWA.EDU> wrote in message
>> news:6.0.1.1.2.20040517161149.01c9ec50@blue.weeg.uiowa.edu...
>> > I currenly ise libnames and filenames to indicate the locations for:
>> >
>> > 1) My SAS permanent data sets, (i.e, LIBNAME SAVE),
>> > 2) my format library for the project (i.e., LIBNAME LIBRARY),
>> > 3) Any input data sets (e.g., an excel file such as FILENAME EXCEL1),
>> > 4) My program log (i.e., FILENAME LOG),
>> > 5) My program output (i.e., FILENAME OUT),
>> > 6) My program program (i.e., FILENAME PGM)
>> >
>> > LIBNAME SAVE 'E:\ORTHO\PROJECTS\ZA\SPONDY\DAT';
>> >
>> > LIBNAME LIBRARY
>> > 'E:\ORTHO\PROJECTS\ZA\SPONDY\FOR';
>> >
>> > FILENAME
>> > EXCEL1 'E:\ORTHO\PROJECTS\ZA\SPONDY\DAT\XRAYTAB1.XLS';
>> >
>> > FILENAME
>> > LOG 'E:\ORTHO\PROJECTS\ZA\SPONDY\LOG\entry1.p01';
>> >
>> > FILENAME
>> > OUT 'E:\ORTHO\PROJECTS\ZA\SPONDY\OUT\entry1.P01';
>> >
>> > FILENAME PGM 'E:\ORTHO\PROJECTS\ZA\SPONDY\PGM\entry1.P01';
>> > I have done this for years using DM commands to save and clear SAS
>> windows.
>> >
>> > I currently have a project that I want to run from a shared drive that
>has
>> so
>> > many levels that it is cumbersome to include all of this information
in
>> the
>> > LIBNAME AND FILENAME statements. Therefore, I would like to "split
up"
>> this
>> > information. My initial thought is to create code that indicates the
>> drive and
>> > the project and then use this information to inform the usual LIBNAME
>AND
>> > FILENAME
>> > Statements. I'm not quite sure of the syntax or where to even look
for
>> this.
>> >
>> > I'm currently running SAS 9.0 under Windows.
>> >
>> > My "idea"
>> >
>> > FILENAME DRIVE 'W:\'; /* the drive letter
>> > where the project resides */
>> > FILENAME PROJECT 'ORTHO\PROJECTS\ZA\SPONDY'; /* the name of the
>> > project (consistent with the example above */
>> >
>> > LIBNAME SAVE 'DRIVE\PROJECT\DAT'; /* location of SAS
>> > permanent files, based on drive and project names */
>> > LIBNAME LIBRARY 'DRIVE\PROJECT\FOR'; /* location of SAS
>> > format library */
>> > FILENAME LOG 'DRIVE\PROJECT\LOG\ENTRY1.P01'; /* location and
name
>> for
>> > log file for program entry1.p01 */
>> > FILENAME OUT 'DRIVE\PROJECT\OUT\ENTRY1.P01'; /* location and
name
>> for
>> > output file from program entry1.p01 */
>> > FILENAME PGM 'DRIVE\PROJECT\PGM\ENTRY1.P01'; /* location and
name
>> for
>> > program file entry1.p01 */
>> >
>> > I have tried the above and, obviously since I'm writing this
>> > note, it didn't work. Hopefully some guru out there can
>> > enlighten me about how to accomplish this task.
>> >
>> > As always, thanks in advance for any help.
>> >
>> >
>> >
>> >
>> >
>> > ______________________________________________________________________
>> >
>> __________________
>> > Kevin F. Spratt,
>> > Ph.D. | |
>> > Iowa Testing Programs (ITP)
>> ( )
>> > University of Iowa Back Care (UIBC)
\ \
>> > _ University
>> > Iowa Spine Research
>> > Center (ISRC) \ * \ of Iowa
>> > 224-D Lindquist
>> > Center
\ /
>> > Hawkeyes
>> > The University of Iowa
> |_________________ )
>> > Iowa City, Iowa
>> > 52242 V
>> > (319) 335-5572 (voice-Lindquist)
>> > (319) 335-9921 (voice-Westlawn)
>> > (319) 335-6399 (fax)
>> > (319 530-8254 (cell & Voice mail)
>> > Kevin-Spratt@Uiowa.edu (e-mail)
>> >
_______________________________________________________________________
>>
>>
| 
