Frequently Asked Questions (FAQs) about SAS/SHARE

You use SAS/SHARE software in the following situations

You can read about SAS/SHARE in the following documents:

No. The users who add and maintain data continue to use the SAS procedures and windows that they already know: PROC FSEDIT, PROC APPEND, PROC FSVIEW, and so on.

Instead of requiring users to change the SAS tools they already know and use, SAS/SHARE takes advantage of the SAS Multi Engine Architecture to allow those SAS tools to access data through a “traffic cop” that is formally known as a SAS/SHARE server. A SAS/SHARE server allows many users to read and update data concurrently in one or multiple SAS files by tracking locks on observations, catalog entries, and SAS files.

No. There are three roles that users assume with respect to SAS/SHARE:

The three roles can be performed by the same person, or one person might perform two roles, or each role might be assigned to a separate group of people.

It's not unusual for the same person to perform the tasks of an applications developer and a server administrator, for example, when the person who develops an application is responsible for the SAS/SHARE server or servers used by that application.

No, three roles. The three roles help organize the efforts so that shared maintenance of data is possible. In real life, the responsibilities of the various people involved in a project might overlap. Often, the same person who develops an application also maintains a SAS/SHARE server.

To help you keep track of how responsibilities usually are divided when multiple users need to update a SAS file at the same time, the remainder of this section answers the questions most frequently asked by end users, application developers, and server administrators.

You use an application that someone else developed to read, add, or update data in one or in multiple SAS files. Occasionally, you find that an observation, a catalog entry, a file, or a library is locked by another user. If that happens, a message appears and you cannot modify the data. SAS/SHARE keeps track of which users have which data locked, so users cannot cause each other's changes to become mysteriously “lost.”

The SERVER= option is required in a LIBNAME statement (or, in SCL programs, any LIBNAME() function) for a library to be accessed through a SAS/SHARE server.

When a library is accessed through a server, the information that is displayed in the Log window about the LIBNAME statement shows you that the engine that was used to access the library is named REMOTE, and the physical name is a subdirectory accessed by the server SAS session.

Use the LIST option in a LIBNAME statement to obtain information about how a SAS library is defined to a SAS session. This information includes the following:

See SAS/SHARE: Learning to Use.

Topics of importance for applications developers include SAS library access, locking data objects, and SAS programming considerations. See Writing End-User Applications to Access Shared Data. For a sample SCL application, see SAS Component Language (SCL) Application. For complete details about locking, see Locking SAS Data Objects.

You might also find helpful information about how server administrators manage SAS/SHARE servers. See Managing a SAS/SHARE Server (Server Administrators). For specific details about creating a SAS/SHARE server and setting SAS options to enhance performance and to establish logging parameters, by operating environment, see Creating the SAS/SHARE Server Environment.

You have to add a SERVER= option to each LIBNAME statement that a user will use to access the library.

You might want to predefine one or more libraries to a server. Include a LIBNAME statement for each library before executing the PROC SERVER statement. Including a LIBNAME statement removes the requirement for a physical name in each user's LIBNAME statement that accesses any of those libraries. This can make it easier to maintain your application.

For more information about server libraries, see Managing a SAS/SHARE Server (Server Administrators). For details about the LIBNAME statement, see Remote Library Services.

Yes, but you usually do not want to organize it that way.

Even though a SAS/SHARE server is not exactly like other file servers that you might be familiar with, it is still a process that generates a lot of disk I/O because a server generates I/O to files on behalf of a large number of users. Therefore, you want the path length between the server SAS session and the physical disk to be as short as possible. Try to store data on the same computer as the server that is used to access that data, whenever possible.

Not really. Usually, file servers are not aware of the content of the files they manage, but a SAS/SHARE server allows several users to update the same copy of a SAS file at the same time.

SAS/SHARE is tuned to manage locking conflicts within SAS files, such as two users attempting to update the same observation of a SAS data file or two users attempting to modify the same entry in a SAS catalog. SAS/SHARE is not optimized to provide the bulk data transfer services at which many file servers excel.

Yes. A server administrator uses SAS options to enable this.

If your application requires the use of more than one communications access method, ask your server administrator to set up the server for your application with the access methods that you need. For more information about access methods, see Specifying a Communications Access Method.

No. A server can share many files in the same SAS library and in many different SAS libraries at the same time.

No. There are no limits coded into the software, and you do not need to use SAS options to specify how many users or files a server will support at one time.

However, a server is the same as any other process on a computer; as it is asked to handle greater workloads it takes longer to do the work. It is possible to put so much traffic through a server that users complain about response time. If any of your servers become that busy, you should consider creating one or more additional servers and dividing the files among the servers.

See your server administrator about creating additional servers.

Probably not. As with other processes on a computer, SAS/SHARE servers can usually run for long periods of time without intervention. Sometimes periodic maintenance or backup activity requires processes to be stopped for a period of time and then restarted. Servers are not immune to such interruptions.

Read Getting Started with SAS/SHARE, giving special attention to when PROC SERVER is started and stopped. Occasionally, you might need to use PROC OPERATE, so you should read those tasks in this exercise.

Usually, a SAS/SHARE server is started when initialization of the operating environment is completed, and it continues to run until the computer is shut down or the server is terminated. You should be familiar with creating and managing those types of processes. Of course, a server only generates I/O or uses the processor while users are accessing data through it; a server doesn't process a residual amount of work when it is not processing work on behalf of other users.

Because a server executes within a SAS session, you need to know how to invoke SAS on each computer on which a server will run.

Not really. Ordinarily, file servers are not aware of the content of the files they manage, but a SAS/SHARE server allows several users to update a single copy of a SAS file at the same time. Also, SAS/SHARE servers automatically translate transmitted data when the client operating environment represents data differently from the server operating environment.

No! SAS/SHARE is designed to require no regular maintenance or other administrative activity.

Yes. By default, SAS/SHARE does not restrict who can connect to a server or which files they can access, but you can restrict access to a server with the OAPW= and UAPW= options in the PROC SERVER statement. The OAPW= option specifies a password, which the server administrator must supply (in the OPERATE procedure), to connect to the server. The UAPW= option specifies a password that the user must supply in the LIBNAME statement to connect to the server. Of course, your file system restricts a server's access to files based on the access permission set for the files and the server's process. You can also set up a secured server. For more information, see Server Security.

Yes. For each server, you can prevent users from defining libraries to the server and restrict them to using only those libraries that you define. To do this, use the NOALLOC option in the PROC SERVER statement. See Limiting the Libraries a Server Can Access.

Remember that passwords can be used to restrict access to individual SAS files. See PW= Data Set Option in SAS Data Set Options: Reference in SAS Data Set Options: Reference for more information about data set passwords.

First, decide whether you want the access terminated immediately or as soon as it is convenient for the user.

The QUIESCE USER command disconnects a user from a server when the user ends the SAS program step currently being executed or closes the window currently being used. The STOP USER command immediately terminates a user's connection to a server and might cause loss of updates that have not been communicated to the server.

In either instance, the user cannot reconnect to the server until a START USER command is executed, which lets the user reconnect, or until the server is restarted. Servers do not retain a list of stopped users when they are terminated and restarted.

See Quiescing User Access to a Server and Terminating User Connections to a Server .

The QUIESCE SERVER command causes a server to stop when all users have disconnected from the server. The STOP SERVER command immediately stops the server and might cause loss of updates that have not been communicated to the server.

See Quiescing a Server and Stopping a Server .

Yes, if your operating environment supports more than one communications access method. See Specifying a Communications Access Method for information about the communications access methods available on your operating environment.

You need to create a second server when the traffic on a server becomes so heavy that an application's performance is less efficient.

Just as you periodically check the resource consumption of the other service processes on a computer, you should, from time-to-time, consider the amount of CPU, I/O, and virtual storage the servers are using. Using operating environment management tools, you might notice that a server is executing a very large number of disk I/O operations or needs a very high percentage of the processor. When you observe those conditions, consider moving some of the work from that server to another, possibly new, server.

Distributing the workload among servers must be a cooperative effort between server administrators and applications developers. SAS provides a set of autocall macros that assign resources to servers symbolically. These macros can make moving resources from one server to another much easier. See SAS/SHARE Macros for Server Access.