filelockwait for work library

[peterPNFP]

I know filelockwait can be added to a libname statement, but how could I give this option to the work library?

Your help is much appreciated!

Peter

[ballardw]

Are you sharing your Work library with another user?

Why do you think you need to set this for your Work library?

[peterPNFP]

Because we encounter a lot of random lock errors when running large datasets over many iterations. Currently we modified our codes to move some datasets to a user-defined library with the filelockwait option, but if we can have the option to the work library, we don't need to change many of our codes. 

[ballardw]

"We" implies some group which leads me to believe that this is a server environment. Talk to your SAS admin about looking to the setting of the server using FILELOCKWAITMAX.

But "random" issues like this quite often points to some sort of network constraint or workload issue  and it may be worth working with SAS technical support to identify and address the cause of the "random" issue.

[Quentin]

Can you provide example code that replicates the problem?  Maybe simulate a dataset, and show how you're iterating and seeing random lock conflicts?  I've never seen a lock error for the work library.  If your work library is on a network / server, I'd be suspicious of backup routines or virus scans or something like that.

[SASKiwi]

You most definitely should not be getting file locking problems with SAS WORK libraries, especially if you are referring to batch SAS processing. You can run into locking issues with SAS EG or the SAS Windowing System if you are viewing a WORK table at the same time as updating it but you can only fix those by closing the SAS viewer.

I suggest you provide more details of examples where this is happening.

[Patrick]

---

@peterPNFP wrote:

Because we encounter a lot of random lock errors when running large datasets over many iterations. Currently we modified our codes to move some datasets to a user-defined library with the filelockwait option, but if we can have the option to the work library, we don't need to change many of our codes. 

---

Each SAS session creates its own session specific WORK area. It's impossible that a SAS process from one session locks a table in WORK that belongs to a different session.

Within the same SAS session there is only one process that executes at a time so also there no locking can occur. 

The only way to lock a table in WORK with SAS is when you use a client like EG or Studio and you open a table and then run a SAS script in the same session that tries to write access (drop, create, update, insert) this table. 

If that's the problem then for EG (and there must be something similar for Studio) set below option.

If above is not the problem then some other non-SAS process must be locking the table. The most common culprit is a virus scanner.

That's something your IT guys would need to investigate and then amend their rules to exclude *.sas7b* files from scanning.

You could use "trickery" along the line of what @Ksharp proposes - but I would point the new libref still to the WORK folder as that's for a good designed environment the storage location with the best I/O available.  I don't recommend to use below code as it's a workaround obfuscating a problem instead of solving it. ...and if it's a virus scanner or the like that's causing the issue then the workaround wouldn't even work as it still stores the tables in the same location as WORK.

libname work2 "%sysfunc(pathname(work))" filelockwait=200;
options user=work2;

data x;
 set sashelp.class;
run;

[Ksharp]

You could make your library be WORK library.

Like the following:

libname x v9 'c:\temp\' filelockwait=200;

options user=x;

data x;
 set sashelp.class;
run;