@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;
... View more