05-30-2013 10:56 PM
Without looking into this too much, it means another process is accessing the table you are trying to access.
Are there anyother processes running in LSF at the same time, any users using EG etc. There are tools out there that will show you what is locking a particular file.
05-31-2013 07:24 AM
Thanks for the reply, Can you tell me the Tool names please
Users are not closing the session properly it could be a SAS EG, or SAS DI or any Client Tire tools. that's why when we ran the LSF we are facing Table lock errors, How do we take this ?
06-01-2013 06:14 AM
most of our sas users complaint the same , as they want to open tables at any time though the ETL jobs are running , we plan of using lock proc . But i want to know other option out of this which make sas users do there read dataset and ETL jobs do their update dataset
06-01-2013 07:27 AM
Usually this is what database technology is used for. There are some analytics oriented database out there that are optimized for many readers / one writer. Alternatively, SAS/Share might be an option, although I haven't used it.
Aside from those, I know that many SAS users have developed home-grown synchronization processes over the years...maybe a search of SGF papers would pop some up.
06-12-2013 02:22 PM
As everybody mentionned, this is very typical of a multi-user SAS environment. The idea that Tom proposed of using a database engine would probably be the best approach. The Base SAS engine is a very poor choice for multi-user environment as it relies on the operating system file locking mechanism.
If you want to keep using the Base SAS engine, you can use the fuser command on any UNIX-like operating system to list active locks on a file. It is easy to build a small script that will kill the locking processes but this is a very drastic approach.
I hope this helps a little,
06-19-2013 08:03 AM
As said by Barry Stevens, it is not a big issue just check the process number in log and verify on server about the owner of that process.
Request user to kill the process which will realse the lock. Process can be veirfied in SAS Management Console by connecting to workspace server.
06-21-2013 01:05 AM
One brute force solution to the SAS table locking problem is to bounce your SAS workspace server(s) just prior to running your ETL jobs. This works well if your ETL jobs are run overnight in batch. Often it is good practice to restart your SAS servers on a regular basis anyway just to get rid of any orphan server processes and to do backups etc.
Of course this approach is not useful if ETL jobs have to run at the same time as user jobs....
06-21-2013 04:55 AM
Even we have a cleanwork utility in SAS which we can use for cleaning the workarea, all we need to do is chaning the paramters in it acooridng to your environment and schedule it to run for every 2 hours, this will clean the work area relase some of the files.
06-24-2013 10:10 AM
cleanwork is a script which will be provided by SAS used for cleaning the temp work files, it will be available under SASHOME/SASFoundation/version(9.3/9.2)/utilities/bin on server.
All you need to do is execute the above script againist your SAS Work area.
/sas/bau/saswork is your work area where temp files will get created, you need to execute the above script againist this filesystem as shown below:
Go to the location where cleanwork available and execute it against work area: ./cleanwork /sas/bau/saswork
For locating cleanwork you can give locate cleanwork on your LINUX/UNIX server.