Ways to overcome the ERROR: A lock is not available for dataset

[ykk]

We are facing this error more frequently. We are different process flows which will use the same dataset for processing. It works fine but sometimes it does fail with the error

ERROR: A lock is not available for PROGRESS.RA_EMEAR_PLS_CSPP_1YR.DATA.

ERROR: Lock held by process 346

Do we have any options to overcome this error or remove the lock if we have any

[Quentin · Accepted solution]

Typically datasets are locked when a process is writing to them, or when another process is reading the data with a table-level lock.  Assuming the datasets really are locked, and you just want to have your process wait until the dataset is available, you can try a macro like %trylock:

http://www.lexjansen.com/pharmasug/2005/posters/po33.pdf

Editor's note:

In SAS Enterprise Guide, you can use the View Open Data Sets window to release any lock that the SAS Enterprise Guide process is holding.

[ridgeknight]

I tried to use this trylock macro described in the paper http://www.lexjansen.com/pharmasug/2005/posters/po33.pdf.  I have several parallel run processes and they may access and update a common dateset.  Those processes still fail when trying to lock the dataset with this commond "lock &dataset_name".  How to turn off this for SAS from failure and exiting the process when it encounts error "654 ERROR: A lock is not available for ****." when trying to lock a dataset?

[Astounding]

The easiest way, if it is feasible, is to start your process by copying the permanent data sets(s) to temporary data sets, then processing the temporary data sets within the process.  Even a simple step like this locks the data set:

proc sort data=my.dataset;

   by id;

run;

Nobody else can use the data set until the PROC SORT completes.  You could probably overcome the problem in this example, by rewriting the process to use:

proc sort data=my.dataset out=dataset;

   by id;

run;

Then the rest of the process would have to use "dataset" instead of "my.dataset".

Good luck.

[jakarman]

All kind of datasets are locked by either reading or writing them. Writing is requiring exclusive access.

You could specify a max-waittime SAS(R) 9.4 Companion for UNIX Environments, Fourth Edition
removing a lock is not very sensible when that is caused by updating the data. In the middle of an update stopping that will cause corrupted datasets.

When it is caused by users that interactive are reading that dataset (automatically open in eg EGuide) let them not automatically open it.

When you are creating an updated version of the data while users can use that data. Split the creation and the update to the resulting location. 

[FVR]

I was getting this error intermittently and I suspected it was due to latency issues with regard to our network. 

After some searching and hair pulling, I discovered that there is a SAS startup/configuration variable that allows me to increase the amount of time that SAS waits before declaring/throwing a 'File Lock' error.

For version 9.4, the SAS startup configuration file is located at (in Windows):

    c:\program files\SASHome\SASFoundation\9.4\nls\en\sasv9.cfg

The following configuration option variable was set by adding a line to the above referenced sasv9.cfg file

-FILELOCKWAIT 20

This option/value compels SAS to wait up to 20 seconds before throwing a 'File Lock' error.  You can/should experiment to see how long you need (i.e., there is nothing sacred
about the 20 value). 

As with any configuration file, attention must be paid to where the new line is inserted.  Guidance is provided in the existing configuration file.

After you restart SAS, you may check that the new values by executing proc options; run;

This has solved my problem.  Your mileage may vary. 

[shephia]

t worked for me too.

[Kurt_Bremser]

If the locked state persists (eg some other user has opened the file in Enterprise Guide to look at it), and you want to completely rewrite the file, you can use the suitable OS command to delete it.

On UNIX, this means that the directory entry (the "link") is removed, but the data will persist as long as the other user keeps the file open (the 'inode' and the data are still there). You can write the new file, and once the user closes his file handle, the inode is also deleted and the data area is released.

Because of this, I never use proc append in batch jobs. Instead I do a set with multiple datasets in a work location, then delete the file with rm -f, and then copy the dataset from the work location to the target library.

[chverma]

I encountered such errors few times, and almost all of those times, turned out the dataset was open on another system too. Making sure, the dataset is not open on other systems and servers will come in handy, and the error goes away, provided everything else is in place.

[shephia]

I solved the problem too. I was writing to a folder that was synchronised with Google Drive. So Google Drive was backing up the file when I wanted to use it,

[kanivan51]

We can also see the number of the blocking session in the log. Sometimes it happens that the file is not used in fact, but the lock is not removed from it. And with this script you can check the number of each session:

data _null_;

pid     = &SYSJOBID;

put 'PID: ' pid '*';

run;

[shephia]

I found that the problem was caused by Google Drive. I was saving datasets to a GoogleDrive folder that synchronised them with a copy on the Cloud somewhere. The synchronisation process locked the dataset. Storing the data on a local folder solved the problem 🙂  

[EspenSorensen]

On unix you can use the filelocks=none option in the library statement, which allow read access to multiple processes at the same time. Example:

libname mydata '/data' access=readonly filelocks=none;