Community talk about communities.sas.com. Meta!

Program stops because a dataset is open on someone's workstation

Reply
Learner
Posts: 1

Program stops because a dataset is open on someone's workstation

I am using SAS 9.4 in a client server model.

The sas jobs execute on Unix server. There can be many users who can open a dataset for viewing.

 

Now, when some one opens it for even viewing , and forgets to close it, my job fails when it tries to update those datasets.

Is there any way we can force to update those datasets without the jobs failing ?

Also is there any way if we can know if a dataset is open on someone's workstation?

 

Super User
Posts: 6,935

Re: Program stops because a dataset is open on someone's workstation

Method 1: Declare a time window for updating datasets and suspend workspace server operations during that time window.

Method 2: Use a trick that I do; I obtain the physical dataset filename from the library definition and the dataset name, and use one of the methods for system commands (X statement, call system() subroutine, %sysexec, filename pipe) to do a "rm -f filename". This works even when someone accesses the dataset. All users who have the dataset open will see the old version until they close and reopen.

---------------------------------------------------------------------------------------------
Maxims of Maximally Efficient SAS Programmers
Super User
Posts: 3,102

Re: Program stops because a dataset is open on someone's workstation

A variation of @KurtBremser's method 1 is to stop and re-start the SAS workspace server services before running any update jobs. This will drop all SAS sessions including any locks they have on SAS datasets.

Super User
Posts: 5,256

Re: Program stops because a dataset is open on someone's workstation

@SASKiwi - you mean "SAS workspace server sessions" I guess...?

 

If you have lots of data, and import updates etc (like en enterprise wide DW) you should consider another storage format that handles concurrent read/update operations. In SAS, SPD Server offers that. And most external RDBMS does as well.

Data never sleeps
Super User
Posts: 3,102

Re: Program stops because a dataset is open on someone's workstation

Actually @LinusH I was thinking of the Windows services that run to support a SAS Compute server. Stopping and restarting these drops all user sessions. I guess there is an equivalent under Unix but I'm not so familiar with that as I don't use it currently.

Super User
Posts: 6,935

Re: Program stops because a dataset is open on someone's workstation

On UNIX systems, terminating the spawner will not affect client sessions. But one could write a script that finds all workspace server sessions through the peculiarities of their command line, and terminates them.

 

I prefer my method of deleting the files, as it is less "destructive" for users.

---------------------------------------------------------------------------------------------
Maxims of Maximally Efficient SAS Programmers
Super User
Posts: 5,256

Re: Program stops because a dataset is open on someone's workstation

Maybe the hour is late, but I don't think stopping a service will take down workspace server sessions. Perhaps pooled ones, but not the regular ones.
I've used a simple script to kill all SAS (with some exceptions) sessions before the batch starts.
Data never sleeps
Super User
Posts: 3,102

Re: Program stops because a dataset is open on someone's workstation

@LinusH - I think you are correct however I should have explained that shutting down metadata server services will do the trick.

Contributor
Posts: 50

Re: Program stops because a dataset is open on someone's workstation

Hello,

 

How about to use PROC IOMOPERATE to list and stop your SAS sessions avoidind the jobs to fail the execution.

 

Here some useful links:

http://blogs.sas.com/content/sasdummy/2016/02/15/using-proc-iomoperate/

http://blogs.sas.com/content/sasdummy/2016/02/20/proc-iomoperate-custom-task/

 

Best Regards

Ask a Question
Discussion stats
  • 8 replies
  • 756 views
  • 2 likes
  • 5 in conversation