09-08-2014 10:11 AM
I am hoping to get some direction on this. We use SAS Server and every day you log in a new temporary work directy is assigned to you. Is there an easy way to assign this directory to a libname with out manually copying it from the log each mornig into a libname statemnent?
Appreciate any input, thanks!!
09-08-2014 10:45 AM
Actually, the work directories are designed to go away when you end the SAS process. You should not attempt to reuse them. Our SAS Admin runs the cleanwork tool to delete any orphan work and utility directories that are left by uses who exit SAS abruptly.
09-08-2014 12:04 PM
Thanks for the info Doc@Duke.
I understand they go away after I end my session however I frequently look at the temp tables I'm creating so I was looking for an easier way to create an accessable library instead of copying the temp folder from my log into a libname statement.
09-09-2014 07:01 AM
What client are you using?
A situation where I'm using this is when executing code in DI Studio, and then wish to ad-hoc query the intermediate tables, using Enterprise Guide.
09-09-2014 07:09 AM
How are you doing this? Copy the work tables to somewhere else? Or actually using the physical path for WORK from the one session as path for a libname statement in another session?
09-09-2014 07:35 AM
The dull answer is I do the same as Ody descibes (and in your second alternative). DI Code editor, libname work list; Copy/paste into EG.
But I would love a neater solution.
09-09-2014 08:16 AM
You could as part of the EG session invocation run a bit of code which scans the directories under your root path for WORK for sub-folders (I believe they all start with _TD) and create a concatenated library pointing to all existing folders.
09-09-2014 09:01 AM
You could use Quentins idea.
Get the work directory from the Di session running: %put "%sysfunc(pathname(work))" ; as some user-code. Then put in EGuide: libname MyWork "copy/paste" the data.
If you home directory is open for personal files you could save that info from DI in an file at your personal profile directory and activate that in EGuide. Almost as near getting it fully automated.
As long it is Unix/Windows you only have locking on files, that are the tables. Just avoid locking issues knowing what you are doing.. Work as usual.
09-09-2014 09:36 AM
To clarify :
In Server SAS I need to log on every morning (Run > Sign On) which prompts me for the a SAS Session ID and then my network user name and network password. After these are successfully entered I am assigned a temporary Work Library on the SAS Server.
A message like this appears in my log: "Your work directory is J:\SASWORK\_TD26644_B000010455_"
I do not use the Work folder under the Active Library because every piece of code submitted is done via Remote Submit (Run > Remote Submit) and all temp tables are placed in my temp directory. If I want to view those I need to submit something like: "libname Temp_LIB 'W:\_TD26644_WAPPRIB00001040_';" to create a library in my Active Library.
I'm curious if there is an easy way automate assigning the libname for this temp network directory.
09-09-2014 12:18 PM
As I understant your situation, your SAS server logon/initialization processing assigns a WORK library (e.g., J:\SASWORK\_TD26644_B000010455_) and a TEMP library (e.g., W:\_TD26644_WAPPRIB00001040_). Your programs use the TEMP library instead of the WORK library. Both are deleted at the end of the SAS session. (I don't see the point but there must be one.)
Jaap tells how to map the remote (server-side) WORK directory for local (desktop) access but you want to map the TEMP library for local access. SAS allows you to map any remote library for local access.
Let's say in your signon/connect program you've assigned the remote server the alias 'bigOne' and the TEMP library is named 'temp'. In the SAS editor, in the local environment issue one of these two commands:
To use a libref name different from the remote libref when you access it from the local environment use the construct Jaap provided --
libref remTemp remote server=bigOne slibref=temp; ** remote is not required but is a visual aid to make it even more obvious that I'm referencing a remote libref. ;
To use the same libref name as the remote when you access it locally --
library temp remote server=bigOne; ** remote is not required. ;
I don't use EG, but to make it run automatically you can add either of these librefs to the bottom of your connect program (if you can modify it) -- just be sure it is after the remote libref TEMP is assigned.
You might want to look at my 2011 SGF paper "Using SAS to Move Data Between Servers".
09-09-2014 10:01 AM
You are telling something about using SAS-connect. That is behind "run > sign on" There is a for a server-name (must have been setup somewhere) and then the user-id password.
The server is obviously a Windows server. That is offering a lot of opportunities.
The SAS way works also with Unix and Mainframe using the Conenct options. Slibref SAS/CONNECT(R) 9.4 User's Guide, Second Edition
Setting the conection in asynchronous mode using: options connectwait=no will let your dms system free for other work. Progress on the other/server side can be followed as "rdisplay"
"llibname work<serverid-xxx> server=<serverid> slibref=work ; " will give you open access to the remote work.
Your <serverid> must be a sas-macro variable containg DNS-address and port of the SAS server (spawner). serverid-xxx must be a macro-var with some 3 letters as shorten of the server. A libname is limited to a string of 8 chars.
You can all this having automated at startup as sasscripting.
With Windows when you are knowing the Uncname of the server and can share data at that location you could use a program rsubmit that and getting it back by sysrput so you can epand the uncname with that temp-name for a libname.
Do you have access to that windows sas server at that work using an uncname?