Hello Community, I like to understand how SAS working directories works and also how to delete orphaned (I think) folders.
I have SAS installed on a windows servers. From EG when I run this code
proc options option=work;
run;
result is:
SAS (r) Proprietary Software Release 9.4 TS1M4
WORK=W:\SAS\SASWork\_TD7652_SASVASERVER_\Prc2
When I run this code
data _null_;
rc=dlgcdir();
put rc=;
run;
result is:
NOTE: The current working directory is "D:\SAS\SASConfig\VA\Lev1\SASAppVA".
Question:
Both W: and 😧 are locations on my VA server. When I run a code on EG, for example, I see a folder is getting created on the VA server in W:\SAS\SASWork\ _TD7652_SASVASERVER_. The above D:\SAS\...\SASAppVA is location of SAS.Bat and other programs. I am assuming D:\ is where SAS program (sas.exe) starts SAS and execute the EG code and result of the session is a creation of a folder in “Working” directory W:\SAS\SASWork\! Am I correct or totally off course?
Now, it looks like I have some orphaned sub folders in W:\SAS\SASWork\ folder
Q1- How do you know which folder is an Orphaned and which one is not?
Q2- How can I clean these folders, for example is it a good practice to delete any sub folders older than two days?
On a blog I found something about Cleanwork utility for Windows 64-bit is it something that normally administrators use?
Thank you again for your assistants
CleanWork will check for & clean up orphaned SASWORK files/folders. It tends to be an administrative function, but can be run by any user who has the rights to delete SASWORK files/folders. Generally, your typical user will not have the rights to delete SASWORK files/folders created by other users.
It is generally run as a super-user (root or group owner) as a scheduled overnight task.
Why not give it a go?
The clean work utility is documented here
Thank you @AndrewHowell and @Reeza for the info. I am the SAS admin (well we are very new to SAS). I will read the document and will give it a try.
Much appreciated.
Best
Just to dig a little deeper into what the cleanwork utility does:
When a SAS process creates its WORK library location, a hexadecimal representation of the process number is made part of the directory name. Therefore it is quite easy for the cleanwork utility to detect if a WORK directory is "orphaned" or not.
Note that this is what I see happening on UNIX systems, the toyboxes might work a little differently.
Thank you @Kurt_Bremser for the info, is there anyway or it is possible when the folder + the hexadecimal number is created to associated with a user? I also did some testing, opened EG, put some code and run the code. Noticed a new folder was created and then I didn't log out, just killed the EG process and the folder was deleted. I want to know in what situations where the folders are not automatically deleted!
best
In most cases, the workspace server deals with the loss of its frontend in a graceful way. Even "hard" losses (like a network outage) will be handled by a timeout.
Orphaned WORKs are usually the result of a crash (segfault or similar) or some kind of hard termination on the server (power outage, kill -9).
On UNIX, a simple ls -ld of the directory will reveal the owner.
Hi @Kurt_Bremser, I did run the cleanwork.exe, and it looks like it removed some of the directories but still got bunch of folders. I tried to delete them manually and it basically can't because the or folder is open in another program. Since at this moment I don't have any users logged in I am assuming these folders perhaps are somehow are folders that being used by SAS!!
One other question if you have time, I have a network area setup for users to save their EG (projects or programs) to their own group but can't globally map that network for them i.e. S:\mySASTeam. Is there a config file that I can change so automatically point the users to it when they try to save their files with-in EG or SAS Studio like \\myNetwork\SASUsers\mySASTeam\Scripts...
thanks again
On a server, you will have several SAS processes running all the time, metadata server, OLAP server, pooled workspace servers, stored process servers, all having their own WORKs.
The recently used path for storing code files is in one of the xml files in %appdata%\SAS\EnterpriseGuide\7.1.
Found it, the file called SaveDlg but it will change each time a file get saved and it keeps the location of last saved file ;-(
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
SAS technical trainer Erin Winters shows you how to explore assets, create new data discovery agents, schedule data discovery agents, and much more.
Find more tutorials on the SAS Users YouTube channel.