Using SAS Files |
Sharing SAS Files |
If more than one SAS process has Write access to a SAS file (a data set, catalog, library, and so on) at the same time, you would get unpredictable results if the file was updated. SAS locks the file to prevent more than one user from having Write access to a file. When one SAS process opens a file with Write access, other processes are blocked from Write access until the first process closes the file. SAS provides statement and system options to override this file protection. However, in almost all cases, you should leave file protection turned on.
Options to Use for File Locking: SAS Files |
You can turn off file locking for SAS files in the following ways:
Use the FILELOCKS option in the LIBNAME statement.
Use the FILELOCKS system option.
File Locking for SAS Files: The FILELOCKS Statement Option |
By default, SAS restricts Write access to one user. The FILELOCKS option in the LIBNAME statement overrides the default and allows multiple users to have Write access to a file. SAS files that are opened under the libref in the LIBNAME statement are the files that are locked. Multiple users have Read access to files.
The FILELOCKS statement option applies to most (but not all) of the SAS I/O files (for example, data sets and catalogs) that are opened under the libref in the LIBNAME statement.
For more information, see LIBNAME Statement: UNIX.
File Locking for SAS Files: The FILELOCKS System Option |
By default, SAS restricts Write access to one user. The FILELOCKS system option overrides this default for both SAS files and external files and allows multiple users to have Write access to a file. The FILELOCKS system option enables you to apply a behavior globally to individual files that are opened.
You can use the FILELOCKS system option at start-up, in the OPTIONS statement, or in the command line. You can specify multiple instances of the FILELOCKS system option. Each instance is added to an internal table of paths and settings. The FILELOCKS system option applies to most (but not all) of the SAS I/O files (for example, data sets and catalogs) that are opened under the libref in the LIBNAME statement. For more information, see FILELOCKS System Option: UNIX and the LIBNAME Statement: UNIX.
Waiting to Use a Locked File |
If you want to use a SAS file that is locked by another process, you can use the FILELOCKWAIT option in the LIBNAME statement to specify how long SAS will wait for the locked file to become available to another process. The FILELOCKWAIT statement option affects only those files that are opened under the libref in a LIBNAME statement. For more information, see LIBNAME Statement: UNIX.
Conditions to Check When FILELOCKS=NONE |
When file locking is turned off (that is, when the FILELOCKS system option is set to NONE), SAS attempts to open a file without checking for an existing lock on the file. These files are not protected from shared Update access.
If multiple users open the same file for Write access, then the file might become corrupted. The FILELOCKS=NONE option is used primarily to determine whether a job failed because of a locked file.
If the FILELOCKS system option is set to NONE, then you should perform one of the following tasks:
Make sure that your sasuser directory is unique for each SAS session. Typically, the system administrator assigns this directory in the system configuration file. The specification in that file or in your personal configuration file helps ensure that the directory is unique as long as you run only one SAS session at a time.
If you run two or more SAS sessions simultaneously, you can guarantee unique user files by specifying different sasuser directories for each session. In the first session, you can use:
-sasuser ~/sasuser
In the n the session, you can use:
-sasuser ~/sasusernFor more information, see Order of Precedence for Processing SAS Configuration Files and SASUSER System Option: UNIX. The RSASUSER option can be used to control modifications to the Sasuser library when it is shared by several users (see RSASUSER System Option: UNIX).
If you run two or more SAS sessions simultaneously (either by using the X statement or by invoking SAS from two different windows) and you use the same Sasuser.Profile catalog, do not perform any actions (such as use the WSAVE command or change key assignments) within the SAS session to change the Sasuser.Profile catalog because both sessions can use the same catalog.
Multiple users can read the same data sets at the same time. However, only one user at a time should write to or update a data set so that data is not overwritten or corrupted.
When FILELOCKS=CONTINUE |
By default, SAS restricts Write access to one user. When you use the FILELOCKS=CONTINUE option, SAS fails to open a file if that file is locked by another user. However, if SAS returns a message that identifies some other error, then SAS disregards the lock on the file, opens the file, and continues to execute the job.
Sharing Files in a Network |
SAS can be licensed to run on one or more workstations in a network of similar computers. The license specifically lists the workstations on which SAS can run. Other workstations in the network might have access to the SAS executable files, but they might not be able to run SAS.
If the licensed workstations are connected through NFS mounts so that they share a file system, they can all share a single copy of the SAS executable files, although sharing of a single copy is not necessary. They can also share SAS files. However, if a SAS session attempts to update a data set or catalog, it must obtain an exclusive file lock on that file to prevent other SAS sessions from accessing that file.
If SAS is installed on different types of workstations that are connected through NFS, then each type of workstation must have its own copy of the SAS executable files. For information about how to move catalogs and data sets between hosts, see Compatible Computer Types in UNIX Environments.
You can access a file on a different type of workstation if the two computers are connected to the same file system. You can access external files that were created under a different operating environment.
If you create a data set or catalog and save it to a directory, and another computer on a different network wants to access the file, then you have several alternatives for working with that file.
You can log on to a remote computer and perform the work there. This alternative works best if a file is rarely used, or if the original file changes often.
You can log on to a remote computer and perform the work there if the original file changes often. This alternative ensures that you are accessing the most current version of the file. If you use PROC CPORT to copy the file to your computer, the original file might have changed between the time it was copied and the time it was read.
You can log on to a remote computer rather than transfer the file to your computer if you want to use the file once. It might not be efficient to use PROC CPORT, or you might not have enough disk space for PROC CPORT to run locally.
You can use the File Transfer Protocol (FTP) or the Routing Control Processor (RCP) to transfer a file from a remote computer to your computer.
You can do part of your work on your computer and the other part on a remote computer. One example of this alternative is to run a set of statements on a small test case on the local computer, and then submit the real work to be done on the remote computer. Similarly, you might want to subset a large data set on another computer, and then do local analysis on that subset. You can accomplish this task by using SAS/CONNECT software. For more information about Remote Library Services, see SAS/CONNECT User's Guide.
SAS might hang when accessing data over NFS mounts if the FILELOCKS option is set to FAIL or CONTINUE. To alleviate the problem, make sure that all NFS file locking daemons are running on both computers (usually statd and lockd). Your UNIX system administrator can assist with starting statd and lockd.
Note: To test whether there is a problem with file locking, you can set the FILELOCKS system option to NONE temporarily. If setting FILELOCKS to NONE resolves the problem, then you know that there probably is a problem with the statd and lockd daemons. It is recommended that you do not set FILELOCKS to NONE permanently because it might cause data corruption or unpredictable results.
Copyright © 2010 by SAS Institute Inc., Cary, NC, USA. All rights reserved.