One thing that we have a lot of at SAS: installations of SAS software that we can run. I have SAS for Windows on my laptop, and I have access to many centralized instances of SAS that run on Linux and Windows servers. (I also have access to mainframe SAS, though it's been a while since I've used it. When I log in, I picture a Rube-Goldberg style mechanism that pokes an intern to mount a tape so my profile can be reloaded.)
I often develop programs using my local instance of SAS and SAS Enterprise Guide, but deploy them for use on a central server. I might run them as batch jobs or interactively with SAS Enterprise Guide or SAS Studio or even in SAS/IntrNet.
Our IT department wants SAS employees to have seamless access to their files whether on Windows or on Unix-style file systems, and so they make it easy to access the same network path from Windows (using UNC notation, or "\\server\path" syntax) and Unix (using "/node/usr/path" syntax). As I develop my SAS programs, I want the programs to work the same whether run from Windows or Unix, and I don't want to have to change LIBNAME paths each time. Fortunately, SAS programs are usually portable across different operating systems, and while SAS data sets might have different encodings across systems, SAS can always read a data set that was created by a different version.
I have a simple technique that references the proper path for the operating system that I'm using. I build a SAS macro variable by using the IFC function and the &SYSSCP automatic variable to check whether I'm running on Windows, then assign the path accordingly.
/* Use the IFC function as a shorthand for if-then, returning a character string */ %let tgtpath = %sysfunc( ifc(&SYSSCP. = WIN, \\sasprod\root\dept\mydept\project, /r/node/vol/vol01/mydept/project ) ); libname tgt "&tgtpath."; |
When I run this on SAS for Linux, I see this in the log:
NOTE: Libref TGT was successfully assigned as follows:
Engine: V9
Physical Name: /r/node/vol/vol01/mydept/project
And on Windows:
NOTE: Libref TGT was successfully assigned as follows:
Engine: V9
Physical Name: \\sasprod\root\dept\mydept\project
9 Comments
Good tip. And probably worth mentioning that a further benefit to this approach is that Windows is happy to accept a / instead of a \ in directory paths, and doesn't mind a mix. So after making your TGTPATH macro variable you can do stuff like: %INCLUDE "&TGTPath/Code/BestProgramEver.sas"; and it will still work on both Windows and Linux.
Thanks Quentin! (BTW, my constant struggle is to figure out which program to name "BestProgramEver.sas")
Hi Chris,
Is it really a good idea for performance to store SAS Datasets on directories shared between systems, meaning they are accessed through network and not SAN attachment ?
That's really a good idea for SAS programs or SASEguide project nevertheless...
have a good day
Hi Pascal,
In our case, we have NetApp storage that we reference from Windows or Unix. Is it the most optimal? For my small applications, it's fine. For larger data we might use databases instead, delivering more optimized I/O with better query processing.
I have mounted a Linux folder in my Windows environment and I would like to create a library in that mounted folder. I do not have a UNC path to that folder but I only have a drive letter. Is there a way to create a library there? The reason I do not see a UNC as the server needs SSH connection to log on to it. A third party software was used to mount the Linux folder. Thanks in advance.
Usually mapped drives don't show up in your SAS session when you connect via EG. But it sounds like you might have EG on the desktop and your SAS session on Linux? If so, then your libname statement would reference the Linux path, not the Windows path.
Pingback: Using the SAS Macro Language to Create Portable Programs - SAS Learning Post
Hi Chris,
Very clever! Here's a related, albeit different challenge: Include SAS codes stored in a z/os env in a SAS program running in UNIX. Possible?
And, will we see you at SGF Orlando next week?
Thank you !!
I'll bet there is a way. FILENAME FTP, maybe. Or FILENAME CATALOG to include a SOURCE entry from a SAS/CONNECT remote library? I'm sure we could crack this nut! And yes, I'll be in Orlando -- see you there!