Running SAS on the Web

Michael Friendly
York University
At the most basic level the WWW provides the means to share SAS datasets, programs, macros, etc. using a more convenient interface than was provided for these functions previously by other internet protocols (FTP, email, listserves, discussion groups). And, starting with SAS 6.11, SAS itself can access remote datasets and files using the WWW-based URL method or the FTP method provided by the filename statement. But what possibilities exist for connecting SAS more directly to the web, and how can these possibilities be explored?

This note describes some of the possible forms of interaction between SAS and the World Wide Web, and gives some ideas about how to set them up, but it's also intended to stimulate discussion, comments and suggestions.

Server-side vs. Client-side SAS processing

The client-server model provides for processing to be split cooperatively between a local machine and a remote host; ideally, each machine is delegates those parts of the task it can provide most readily.

In the WWW, servers provide files (text, images, sound, etc.) and processing functions (searching a database), while the remote user's client software transmits requests for those services and displays the results on the local machine. While most WWW applications transmit static information, the possibility has existed for a browser to launch processes or applications on the server, and vice-versa. (See B. Narasimhan's A Literate Program for a Hyper-Document for an impressive example (using xlispstat) of a connection between web documents and statistical processing.) Where does SAS fit into this client-server model?

SAS - WWW connectivity in a Student Lab

Last year I began to convert SAS-related course materials for several courses ( Psychology 3030: Intermediate Statistics, Psychology 6140: Multivariate Data Analysis from a mainframe to a Novell-based PC lab. Course documents were converted to HTML and linked to SAS files on the server.

Although this had many beneficial effects, it created two disconnected environments for the students' work: they could read course materials and the linked SAS files with Netscape, but had to use cut/paste or find the files on the local filesystem to run them with SAS. So, it made some sense to look for ways to connect SAS programs more dynamically to web documents.

Server-side SAS processing

A WWW server can be set up to run any program on its own machine and return the results to the client. Some common examples are the search programs (e.g., wwwwais) which allow you to search a server for documents based on keywords.

Some examples of SAS programs run on a WWW server are:

Client-side SAS processing

Server-side SAS processing seems most useful and/or appropriate when: (a) the result to be returned to the client is a single file such as a table or a graph; (b) the result is based on datasets which must remain with the server; (c) the server can handle a possibly large number of processes being run.

However, when one or more of these conditions is not true, it may be more useful for web-based interaction to run SAS (or other statistical applications) on the client machine.

Setting up a WWW server for client-side SAS processing

SAS files sent by a WWW server are normally delivered as the MIME type plain/text, which means they are displayed as text in the browser window. Servers which are set up to allow you to have those files run locally by SAS will send a SAS file as the MIME type application, with a subtype such as x-sas, where the "x" designates an experimental MIME type.

This document will refer to the MIME-type for SAS programs to be run locally as application/x-sas, but with no implication that this designation should be adopted as a standard. (Another possibility would be application/x-stat-sas, which conforms with some usage for other statistical WWW applications.)

Hence, if you are running a WWW server, all you need do to enable .sas files to be run by SAS on the client machine is to add a MIME type to your server's configuration file which would cause .sas files to be served as application/x-sas.

This is probably a very bad idea (see below for another solution), but here is how you would do it. This description applies to the NCSA httpd server.

The server configuration file, srm.conf understands an AddType directive, which allows the server to serve new MIME types for files with a particular extension. To serve .sas files as application/x-sas, add a line like this to your srm.conf file:

AddType application/x-sas .sas
The reason this is a bad idea is that it creates security problems for the (client) user, and does not allow him/her to view the .sas file before running it, or offer a choice of what to do with that file.

Let the user decide

An alternative to serving all .sas files as an application mime type is to use a cgi script which allows the file to be served either as plain/text or as application/x-sas. The choice can be made either

sasfile cgi script

As an example of this kind of interaction, I've written a perl cgi script, sasfile. The script is normally invoked from a web document by including a reference of the form
<a href=""></a>

When invoked in this way, the script sends an HTML file which includes the text of and a link

<a href=""></a>
Click here to run me on your machine!

The addition of the keyword parameter ?run to the URL is the signal the script uses to decide to send the file as application/x-sas.

Handling %includes

The sample programs for my courses are set up to include datasets stored in a common directory, and referenced in the program by
%include data(datafile);
where data is defined as a collection of directories to be searched by a filename statement in the system file, eg,
filename data ('k:\home\sasuser\data',
As well, these programs use a collection of directories for macro programs, set up as an autocall library. Since a remote user is not likely to have these data and macro files, the sasfile script scans the lines of the original files for lines starting with %include, and presents a list of them, in the form:

%includes includes references to the following server data files and macros. You may wish to download them first. (With most browsers, shift-Click on the link and select an appropriate directory.)


To see how this works, the examples below contains a sasfile-link to programs from my Intermediate Statistics and Computer Methods courses.
[R] Resistant line for IMR data. Fits a resistant line predicting infant mortality rate from per capita income, and compares this with a log-log fit.
A bubble plot, with embedded comments.
In order for the Launch button to work, set up your browser to accept mime-type application/x-sas, as described below.

Literate programming

Serving .sas files by a script offers other advantages as well. SAS programs can be made more literate by incorporating documentation together with the program source, in a way that the program code can be read more easily, can be used to describe algorithms, and so forth.

Here are a few ideas:

Setting up your browser to run SAS locally

In order to make this work, you have to set up your web browser (Netscape, Mosaic or Cello, etc) to recognise SAS files which are served as application/x-sas.

Netscape for Windows

You can set up Netscape to run SAS files from the Options menu.

Other Windows browsers

Look in the documentation for your browser for instructions on how to set up a viewer. To do this in Mosaic for Windows you must edit the mosaic.ini file in the Windows directory. Three lines must be added;
Sample MOSAIC.INI setup

application/postscript="ghostview %ls"
image/gif="c:\viewers\lview\lview31.exe %ls"
image/jpeg="c:\viewers\lview\lview31.exe %ls"
video/mpeg="c:\viewers\mpegplay\mpegplay.exe %ls"
application/x-sas="c:\sas\sas.exe %ls"


Unix browsers

Unix WWW clients have a similar means to associate a local program to be run to "open" various types of web documents. One many Unix systems, this is the file .mailcap, located in your home directory. Sometimes, an additional file, ~/.mime.types must be created or modified as well.

The following procedure works with SAS 6.11 and Netscape 2.0 on a Sun workstation:

  1. in your home directory, create a .mime.types file with following line:
       application/x-sas   sas
  2. in your home directory, put the following line in the .mailcap file:
       application/x-sas; sas %s
  3. in Netscape, under Options|General|Helper make sure the Personal Types File points to your .mime.types file and the Personal Mailcap File points to your .mailcap file.
When Netscape encounters a file with .sas extension, it will then automatically run that file as a SAS program. (Seeing the results in Netscape requires some additional shelI programming). This procedure works with all sorts of files and applications.

SAS client "wrappers"

The method described above configures the client machine to run SAS in batch mode. Any output listing, saslog, or graphic files are written to some directory, but not displayed.

The interaction could be enhanced by writing a client-side script which acts as intermediary between the web browser and the user. For example, such a script could launch SAS in a new X-terminal window on the user's display. Alternatively, the script could:

For example, here's a simple sas.wrap script (borrowing from Tony Rossini, ( which runs SAS in an X-term window:

USAGE='Usage: '`basename $0`' <sas-file> '
INCOMING = '~/incoming/web/sas/'
CONFIG = '~/sasuser/'

## Need an argument
if [ "$1" =  "" ]
    echo "$USAGE" 1>&2
    exit 1

xterm -e sas -config $CONFIG $1
To install sas.wrap (or equivalent for other systems) as your .sas file "Viewer", change the browser launch association from sas to sas.wrap, e.g., the line in .mailcap should read
   application/x-sas; sas.wrap %s

Comments? Suggestions?

I'd be interested in receiving comments or suggestions about the ideas expressed here. The sasfile script is linked here if you want to look at how or what it does.
Michael Friendly
My home page