Access to Remote Library Services
Once the server is started, running a remote access program is simply a matter of specifying the correct LIBNAME options. Example 4.4 utilizes SAS/SHARE to implement a true client/server approach.
Example 4.4 Remote Library Services
libname SHARED slibref=SASHELP server=hygelac.shr1 sapw=user
passwd=_prompt_;
proc print data=SHARED.RETAIL;
title "Retail Sales Total by Month: 1991-1994";
where YEAR gt 1990;
var MONTH SALES;
id YEAR;
run;
The SAS LIBNAME SHARED references the SAS directory on the remote Linux server where the RETAIL data set is stored.
Chapter 4 Remote Access to SAS 85
Four keyword parameters are included on this statement:
slibref – a previously allocated remote SAS LIBNAME that will be mapped to the local LIBNAME SHARED; alternately, you can also specify a remote directory such as /usr/local/SAS_9.1/sashelp.
server – a two-level name for the remote service; the first level is the server name (specified in the hosts file) followed by the service name defined in the services file.
sapw – the user password specified when the service was started (uapw).
passwd – the password for the specified login; using _prompt_ will avoid hardcoding the password in the program.
The SAS client program sends a request to the server on the remote system. The server selects the observations requested by the statement where YEAR gt 1990 and sends them to the client, where the PRINT procedure executes. (The output is not shown, since it is simply the result of the PRINT statement.) The client/server approach eliminates the need to send any unnecessary observations over the network connection between the two systems. In addition, SAS/SHARE allows concurrent updates; more than one user can write to the shared data file at the same time.
If SAS Management Console has been used to configure the server, the LIBNAME statement shown previously can be modified to use the new feature in SAS®9 that allows you to specify a port number rather than a named service. Note in this case that it is not necessary to add this port to your services file; the Server Manager has taken care of that for you. The following example replaces the LIBNAME statement shown in Example 4.4, and connects to a remote data library on a Windows server. The port number 8551 is prefixed by two underscores to indicate the specific TCP/IP connection.
libname SHARED slibref=SASHELP server=hunding.__8551;
The resulting output is the same as for Example 4.4.
Remote SQL Pass-Through (RSPT)
In addition to specifying the server on the LIBNAME statement, as in Example 4.4, it is also possible to use PROC SQL to connect to a remote server, as the following example illustrates:
Example 4.5 Remote SQL Pass-Through
proc sql;
connect to remote
(server=hygelac.shr1 sapw=user user=frederick password=_prompt_);
select * from connection to remote (select YEAR, MONTH, sum(SALES)
format=dollar12. label='Total Sales' from SASHELP.RETAIL
group by YEAR, MONTH);
quit;
The first SQL statement establishes a connection to the remote server. The parameters on the CONNECT TO REMOTE statement are the same as we have seen previously in Example 4.4.
The SELECT statement downloads the entire result set from the parenthesized query. This second query is referred to as SQL pass-through, since the SELECT statement is executed on the server and only the results are returned to the client. Compare this statement to the following alternative:
select YEAR, MONTH, sum(SALES)
format=dollar12. label='Total Sales' from connection to remote
(select * from SASHELP.RETAIL) group by YEAR, MONTH;
In this version of the program, all of the data is transferred from the server, and the summation is done on the client. The advantage is that this reduces the load on the server; the drawback is of course that a lot of unnecessary records are copied over the network connection.
Remote Compute Services with SAS/CONNECT
The SAS/CONNECT product relies on an entirely different approach, essentially ignoring the processing resources of the local computer. Instead, the client serves only as a kind of post office, sending the program over the network where it runs entirely on the remote machine.
As with SAS/SHARE, using SAS/CONNECT requires that a server program be started on the remote system. This program is called a Remote Host Spawner. The spawner program listens for a connection to the host, just like a Web server. (Do not confuse the Remote Host Spanner with the Object Spawner, which provides IOM services.)
Starting a Remote Host Spawner
Starting the spawner is handled differently on Windows and UNIX, although again the principle is the same across all platforms.
On Windows, the spawner program is stored in the SAS root directory. Just run spawner.exe -comamid –install
from a command window to install the spawner as a service. For a complete list of the available options, see “Spawners and Files,” in the SAS System Help contents under SAS Products X SAS/CONNECT X Communications Access Methods.
Note that SAS/CONNECT spawners can also be implemented using SAS Management Console.
The default installation scripts will install the service if this product is licensed at your site; you do not need to run the spawner.exe program if you are using a metadata profile to manage your hosts.
On UNIX, the spawner program is installed by default under the SAS root directory as
$SASROOT/utilities/bin/sastcpd. Just as with SAS/SHARE, the TCP port must be defined in the /etc/services file, as for example:
spawner 4016/tcp # UNIX spawner port
Assuming that this service name has been defined, the remote host spawner can be started with the following command:
sastcpd -service spawner –shell &
Chapter 4 Remote Access to SAS 87
The sastcpd program runs by default as a daemon, so it is not necessary to use nohup. As with the SAS/SHARE server, if you want it to restart when the server reboots, install the script under the init.d directory.
Signing On to a Remote SAS Server
SAS/CONNECT requires an initial SIGNON command to the remote server. This can be accomplished by submitting something like the following statements:
options remote=hygelac.spawner;
signon cscript=”E:\sas\connect\saslink\tcpunix.scr”;
TheREMOTE= option is used to identify the specific network host and the service name. The SIGNON script files tcpunix.scr (for UNIX) and tcpwin.scr (for Windows) are supplied by the SAS/CONNECT installation. Both scripts are on the local client in the specified directory, along with the scripts for TSO, CMS, etc. Again, be sure the option COMAMID=TCP is specified so that SAS can use TCP/IP to communicate with the server.
You may need to modify the SIGNON script. For example, if you need to connect to a UNIX host and the SAS executable is not in your default PATH on that system, you will need to edit the tcpunix.scr script to add the absolute path to the startup options. Search for the string
type 'sas -dmr -comamid tcp -device grlink -noterminal ';
and modify the string as necessary (e.g., replace the sas command with /usr/local/bin/sas or wherever your startup may be). Be careful, since this string may occur more than once in the script; you should modify it anywhere that it appears.
You can also submit the SIGNON command from the SAS Display Manager; select the menu item Run X Signon, and enter the script filename and remote session name as shown in Display 4.7.