Change WORK location when using EG and SAS server

[JoonaH]

Hi

I'm running Enterprise Guide on my workstation and it uses SAS on our server. Be default my WORK-library is assigned to a server side folder generated separately for each session and I don't have physical access to that folder. I have a need to change the WORK library to a folder I do have access to. I have tried running DLGCDIR function to reassign my WORK. According to the log this runs fine and when I use the same function to check WORK location it appears changed (log below). Also assigning some new libref to that folder works just fine. However the WORK library still remains in the generated folder F:\SASwork\_TD32548_SERVERSAS4_\Prc2. Is there any way to change the WORK library location from the clint side?

28 data _null_;
29 rc=dlgcdir("\\data01\joonah\SAS\WORK");
30 put rc=;
31 run;

NOTE: The current working directory is now "\\data01\joonah\SAS\WORK".

34 rc=dlgcdir();
35 put rc=;
36 run;

NOTE: The current working directory is "\\data01\joonah\SAS\WORK".

And in case someone is interested why I need this it's because EG session crashes if there is even a slightest connection interruption while it's running and new connection creates new session and everything in WORK is lost to me. I want my WORK to be located in a location where I can restore it for the new connection. I do not wish to use some other library than WORK since I want the programs to be executable for other users easily and I already have tons of programs that use WORK and changing them would be a massive job.

[Kurt_Bremser]

Define a USER library. All single-level dataset names will then point to this instead of WORK, and they will not be deleted at session end.

[andreas_lds]

---

@JoonaH wrote:

Hi

[...]

And in case someone is interested why I need this it's because EG session crashes if there is even a slightest connection interruption while it's running [...]

---

This should be investigated, either by you local it-department or by sas technical support. EG should not crash when the connection is interrupted.

[JuanS_OCS]

Hello @JoonaH ,

From the client there is no good way to change the SASWORK dynamically. However, I think the solution provided by @Kurt_Bremser should work wonders for you.

In other hand, per definition,  you (and every SAS user) should have full access to the WORK folder in the server. Your admins should arrange that.

As side note, I would never use a shared folder as WORK. You technically can, but then all the data generated by WORK will travel through the network, instead of staying in the SAS server itself. Which, for one, it is a problem on security and network performance, but you will also experience much lower performance by running your SAS jobs.

[JoonaH]

@Kurt_Bremser This doesn't work for me or I'm missing something. EG query builder force you to always define a library for a dataset and therefore my programs are already littered with datasets explicitly assigned to WORK. I can't see a way around it without trasforming every singe query builder into a code block where I could define one-level dataset names

@andreas_ldsEG doesn't crash, the connection crashes. By that I mean that currently processed job ends in error, all further jobs are cancelled and connection is lost. When EG reconnects it reassigns the WORK to a new folder so all already formed datasets in WORK are lost to me.

@JuanS_OCS Will have to look into getting the access to the WORK folder. Not sure how difficult that is since every session creates a new folder and I should only have access to the folder specifically created by my sessions. This would mean a bit more manual work for me though since in case of a crash I would need to figure out the old and the new WORK physical location and then copy all the files the old to the new. By assigning the library myself I could avoid this since I could assign the same old WORK to the new session.

As for the security and performance I agree this is nowhere near ideal so I would definitely not mind a better solution. The easiest solution from my point of view would be that EG and SAS server could just remember the session during which the connection was lost and restore it, but I suppose this is much more difficult problem than it sounds since SAS has not been able fix it.

[JuanS_OCS]

Hi @JoonaH ,

I complete understand your point of view and makes sense. To be honest, that is more a responsibility for your IT department.

In other hand, if you don't generate large WORK files, or if you are capable to be in control of them, one very common setting is that your SASAdmin can set up several SASApps for you, each of them can have different settings, one of them could be the SASWORK location. In this new SASApp, the -work parameter could point to a user-based folder, such as "/home/youruser/SAS/work" in Linux or "F:\SASWORK\!USERNAME" in Windows.

This being said:

- I found your referred attempted solution here https://blogs.sas.com/content/sgf/2018/05/18/how-to-change-your-working-directory-for-sas-with-the-d...

Is it the one?

- @andreas_lds has a point. Your EG is not crashing, but your connection does. I suspect it happens after a certain while. It would be worth to analyse the root cause of those disconnection, by enabling SAS EG logging https://support.sas.com/kb/55/414.html and checking the Windows Event Logs (your sysadmin). I would check as well from SAS Management Console the value of the connection timeout for your SAS Workspace Server. The later can be increased and will take effect once the Object Spawner is restarted.

You could look as well to:

https://support.sas.com/kb/49/637.html

https://documentation.sas.com/?docsetId=bidaag&docsetTarget=p0gxmv2av4gkvun1vhamsvtrs6tv.htm&docsetV...

[JoonaH]

@JuanS_OCS Setting up another SASApp might be an option yes. Will have to see about that with our admins.

As for the guide about changing WORK-library, yes that is the guide I found.

And about the connection issues the reasons for those are already known and I can't affect them.

@Tom Thanks for the suggestion. Hadn't thought of that. Though I don't think that would be possible since all my projects so far are on EG and that's the tool others use as well in our company.

Why does changing WORK location has to be so **bleep** difficult 😛

[Kurt_Bremser]

---

@JoonaH wrote:

@Kurt_Bremser This doesn't work for me or I'm missing something. EG query builder force you to always define a library for a dataset and therefore my programs are already littered with datasets explicitly assigned to WORK. I can't see a way around it without trasforming every singe query builder into a code block where I could define one-level dataset names

---

Crutches have a habit of getting into your way; I have found that I am much more productive when coding directly. I only use the EG tasks to quickly get an initial shot when using a procedure I am not familiar with; after that, I copy the code to a program window and use the documentation and repeated test runs to refine the code.

[Tom]

If you cannot get your infrastructure problems fixes so your connections don't keep dropping you might want to look into switching from EG to SAS/Studio as your user interface.  That handles temporary connection issues much better in my limited experience.

[JoonaH]

I did figure out a workaround solution. I have a startup code that writes down the WORK library physical location for each session into SASUSER. In case of a session crash I can use that information to define OLDWORK-library and then move all data from that library into the current work. Not ideal since I need to dig out the old library location from SASUSER manually, run the code to move the data and wait for it to finish before I can continue, but at least it works.