Chapter Contents
Previous
Next
|
Chapter Contents |
Previous |
Next |
| SAS/SHARE User's Guide |
The following are answers to questions that are frequently asked by new users of SAS/SHARE software.
| General Questions |
You use SAS/SHARE software when
Instead of requiring users to change the SAS tools they
know and use, SAS/SHARE software takes advantage of the SAS Multiple Engine
Architecture (MEA) to allow those SAS tools to access data through a "traffic
cop" that's formally known as a SAS server. A SAS server
allows many users to read and update the data in one or more SAS files, all
at the same time by keeping track of locks on observations, catalog entries,
and SAS files.
It's not unusual for an applications developer and a
server administrator to be the same person. This happens when someone who
develops an application is responsible for the SAS server(s) used by that
application.
To help you keep track of how responsibilities usually are divided when more than one user needs to update a SAS file at the same time, the remainder of the questions and answers are divided according to the roles described above:
| Questions Asked by End Users |
There isn't much you need to know.
You use an application that someone else developed to
read, add, or update data in one or more SAS files. Occasionally you will
find that an observation, a catalog entry, a file, or a library is locked
by another user. When that happens, a message appears on your display and
you cannot modify the data. SAS/SHARE software keeps track of which users
have which data locked, so users cannot cause each other's changes to become
mysteriously "lost."
When a library is accessed through a server, the information that is displayed by the LIBNAME statement shows you that the engine, which 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, including:
| Questions Asked by Applications Developers |
Read Getting Started with SAS/SHARE Software. To understand your applications in perspective, it is very helpful to see how end users experience locking conflicts and how server administrators create and terminate SAS/SHARE servers.
Also, read through the sample SCL program in Appendix 5 of this book. It illustrates a variety of programming techniques for sharing data among users.
There is advice about the performance of your applications
in Appendix 4.
You might want to pre-define one or more libraries to a server. To do that, include a LIBNAME statement for each library before entering the PROC SERVER statement. This 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
Starting and Managing a SAS/SHARE Server. See The LIBNAME Statement for reference
information about server libraries.
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 you might be familiar with, it is still a process that does a
lot of disk I/O. That's especially true because a server does I/O to files
on behalf of a large number of users. For that reason, you want the path
length between the server SAS session and the physical disk to be as short
as possible. That means storing data on the same computer as the server used
to access that data, whenever possible.
SAS/SHARE software is tuned to manage locking conflicts
within SAS files, for example, 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 do 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.
However, a server is like any other process on a computer; as it is asked to do a great deal of work it takes longer to get that work done. 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.
| Questions Asked by Server Administrators |
Read Getting Started with SAS/SHARE Software, paying particular attention to when PROC SERVER is started and stopped. You may occasionally need to use PROC OPERATE, so you should at least read over those steps of the exercise.
A SAS/SHARE server is usually started when the operating system has completed its initialization, and it continues to run until the computer is shut down or someone decides that the server should be terminated. You should be familiar with creating and managing those kinds of processes. Of course, a server only does I/O or uses the processor while users are accessing data through it; a server doesn't do a residual amount of work while it is not doing work on behalf of other users.
Because a server executes within a SAS session, you
need to know how to invoke SAS software on each computer on which a server
will run.
Yes. By default, SAS/SHARE software does not restrict
who can connect to a server nor 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 that the server administrator must supply
(using the OPERATE procedure) to connect to the server. The UAPW= option specifies
a password that the user must supply in the LIBNAME statement to establish
communication with the server. Of course, your file system restricts a server's
access to files according to the privileges of 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 only those libraries that you define. To do this, use the NOALLOC option in the PROC SERVER statement. See Limiting Which Libraries the Server Can Access.
Remember that passwords can be used to restrict access
to individual SAS files. See SAS Language Reference: Dictionary for more information about data set
passwords.
The QUIESCE USER command causes a user to be disconnected from a server when the user finishes the SAS program step or window currently being executed. The STOP USER command immediately terminates a user's connection to a server and may cause loss of updates that have not been communicated to the server.
In both cases, the user cannot re-connect to the server until a START USER command is executed to give the user permission to re-connect or until the server is re-started. Servers do not remember a list of stopped users when they are terminated and re-started.
See Quiescing a User's Access to a Server
and Terminating a User's Connection to a Server.
See Quiescing a Server
and Stopping a Server.
Yes, if your host supports more than one communications access method. See Specifying a Communications Access Method for information about the communication access methods available on your host.
Refer to the Appendix "Configuration Instructions
for SAS/SHARE Software" in your installation instructions for information
about configuration requirements for the communication access methods.
Just as you periodically check the resource consumption of the other service processes on a computer, you should, from time to time, take a look at how much CPU, I/O, and virtual storage the servers are using. Using operating system management tools, you may 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, you should consider moving some of the work being done by that server to another, possibly new, server.
Distributing load among servers must be a cooperative effort between server administrators and application developers. SAS Institute supplies a set of autocall macros that assign resources to servers symbolically, which can make moving resources from one server to another much easier. See Using SAS/SHARE Macros for Server Access.
|
Chapter Contents |
Previous |
Next |
 Top of Page |
Copyright 1999 by SAS Institute Inc., Cary, NC, USA. All rights reserved.