SAS Companion for UNIX Environments

Sharing Files

If more than one user accesses a SAS file at the same time or if a single user has access to the same file from different SAS sessions, the results are unpredictable. By default, the FILELOCKS system option is set to FAIL, which prevents simultaneous access to the same SAS file. (See FILELOCKS.) If FILELOCKS has been set to NONE, then you should do one of the following:

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 nth session, you can use
```
   -sasuser ~/sasusern
```
For details, see Processing Configuration Files and SASUSER. The RSASUSER option can be used to control modifications to the SASUSER library when it is shared by several users (see RSASUSER).
If you run two or more SAS sessions simultaneously (either by using the X statement or by invoking it from two different windows) and you use the same PROFILE catalog, do not do anything within the SAS session to change that catalog (for example, using the WSAVE command or changing key assignments) because both sessions may use the same one.
If you and other people use the same data sets, avoid writing to them at the same time.

Sharing Files in a Network

The SAS System can be licensed to run on one or more workstations in a network of similar machines. The license specifically lists the workstations that the SAS System can run on. Other workstations in the network may have access to the executable files for the SAS System but not be able to run the SAS System.

If the licensed workstations are connected via NFS mounts so that they share a file system, they can all share a single copy of the SAS System executables, although this 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 sessions from accessing that file.

When the SAS System is installed on workstations of different types that are connected via NFS, each type of workstation must have its own copy of the SAS System executables. Catalogs and data sets, however, may be shared between certain combinations of machine types.

If the data set or catalog you want to process exists on your network but cannot be accessed with the LIBNAME statement because it resides on a different type of workstation, you have several alternatives:

You can log in to the remote machine and convert the file to SAS transport format using the CPORT procedure, copy the transport file to your machine or access it via NFS, and import it to your type of machine format.
You can log in to the remote machine and perform the work there. This alternative works best when the file is used rarely, or if the original file changes often.
You can do part of your work on your machine and the other part on the remote machine. One example of this alternative would be to run a set of statements on a small test case on the local machine, and then submit the real work to be done on the remote machine. Similarly, you might want to subset a large data set on another machine, and then do local analysis on that subset. This can be accomplished with SAS/CONNECT software.

To allow machines that cannot share SAS data sets or catalogs to coexist in the same networked file system, the SAS System adds a two-digit suffix to the file extensions. For example, if two SAS data sets named TEST are created on machines with different underlying architectures, one will be stored in file test.ssd01 and the other will be stored in file test.ssd02.

The SAS System may 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 filelocking daemons are running on both machines (usually statd and lockd).

Note: To test whether there is a problem with file locking, you can set the FILELOCKS system option to NONE temporarily. It is recommended that you do not set FILELOCKS to NONE permanently. [cautionend]

Chapter Contents
Previous
Next
Top of Page