There is a SAS metadata directory object associated with the application server context. This is where the default path comes from.
It doesn't appear to be something exposed through the user interface (SMC). I'm not sure its a good idea to change it.
EDIT: You can update it inside the Schedule Manager plugin inside SMC. You right click the plugin, click "Deployment Directories". You get a UI to view this metadata and update it.
Just noticed you are talking about the browse for source code button, not the deployment directories. This uses the file service offered by the SAS Workspace Server. The schedule manager plugin does not include an override for where to start this search from, its using the default path of the file service. On Linux it looks like this path defaults to $HOME, on Windows %MYSASFILES%.
Kept code spelunking for you. The file service has a special flag you pass it to tell the service that you want the contents of the users home. The "ListFilesModeUser" flag is what is used in the schedule manager plugin to start the navigation at the users home. Sensible so far.
The file service uses some other code to find the home directory of the user. There are different implementations for the various operating systems. On Windows the function to find the users home directory looks up the shell variable SASUSER and returns this path, if its unset the current working directory of the process is used. Not entirely sure why its done like this but I guess the reasoning is that SASUSER is 99.99% of the time in the users "My Documents" folder on Windows by virtue of using the result of the Windows SHGetKnownFolderPath function for FOLDERID_Documents at startup because of the default value of SASUSER is set like this: -SASUSER "?FOLDERID_Documents\My SAS Files\9.4". On Linux/UNIX the ~ path is expanded and used.
You could change the default path by setting the Windows shell variable SASUSER to some other path. It not advisable, good chance that breaks stuff in your SAS session. Many places in SAS (and user written code) likely assume the shell variable SASUSER references the filesystem location of the SASUSER library.
If this is causing huge amounts of pain then give me a call tomorrow, or when you are free and we can talk about this. I'm sure we can find an elegant solution to whatever is causing you problems.
No worries Simon. You have already spent too much time on this.
I was just hoping that users who want to schedule jobs don't have to navigate.
We are using service accounts for scheduling.
The SASUSER env var was not defined so I defined it in the registry and it worked.
1 %put &sysuserid; srv-lsfadmin 2 3 filename CMD pipe 'set | find "SASU"'; 4 data T; 5 infile CMD; 6 input; 7 put _infile_; 8 run; NOTE: Compression was disabled for data set WORK.T because compression overhead would increase the size of the data set. NOTE: The infile CMD is: Unnamed Pipe Access Device, PROCESS=set | find "SASU",RECFM=V,LRECL=32767 SASUSER=F:\SASJobs\LSF\Admin NOTE: 1 record was read from the infile CMD. The minimum record length was 28. The maximum record length was 28.
But the default path for deployment is still the same
That's fine, users will have to click and navigate to their folder on drive F: for now.
I had to try but the cost/benefit of this exercise is getting too high. 🙂
Thank you again for your thorough investigation!
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.