Running SAS on the Web
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
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
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
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:
- IPPBR Facts about Kansas, collection of cgi scripts and SAS programs
by Larry Hoyle, which generate tables or graphical output based on form-input.
The collection includes some examples which use
java scripts and VRML.
- WebPower: Power Analysis for ANOVA designs.
This application runs a SAS macro to carry out a power/sample-size
size analysis for an experimental design.
The cgi script gets user input from a web form,
writes a SAS file which calls the macro, substituting
the user's imput parameters, runs the SAS file,
and returns the listing file to the web browser as the
- Sieve Diagrams.
This application is based on a set of SAS/IML modules which
produce a graphic display of association in a two-way frequency table.
The cgi script allows the remote user to enter the frequency data
and other parameters from a web form, writes and runs
a SAS file which calls the IML program, producing a PostScript
output file containing the graph. Because most WWW browsers
cannot handle postscript, another program (ghostscript) is called to
convert the .ps file to a .gif image.
- SAS Institute has also started a collection of web-related tools
on their tech support server.
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
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
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
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
- by examining the CGI environment
variable HTTP_ACCEPT (which contains the list of mime
types acceptable to the browser), or
presenting the file first as plain/text for the user to
view, and providing a link which would cause the script to run again,
but serve the file as application/x-sas.
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
When invoked in this way, the script sends an HTML file which includes the
text of file.sas and a link
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.
The sample programs for my courses are set up to include datasets
stored in a common directory, and referenced in the program
where data is defined as a collection of directories to be searched by a filename statement
in the system autoexec.sas 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:
file.sas 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.
In order for the Launch button to work, set up your browser to accept
mime-type application/x-sas, as described below.
- [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.
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:
- Rather than documenting a program with boxed comment blocks,
one can use special comment delimeters, such as
which can signal a cgi script to treat lines contained within as ordinary
text, rather than pre-formatted text. See the bubble plot
- hgrind is a program based on vgrind that processes program listings into HTML. It processes a variety of languages, including C, C++, Pascal, and FORTRAN. There is the added capability of embedding HTML so that the listing can be its own documentation. Here is a vgrindefs file with definitions for SAS. [The output from hgrind for .sas programs is not
as attractive as for C programs, however.]
- A list of programming language filters lists a variety of other filters that produce HTML
from source code, some of which may be useful for .sas.
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
Netscape for Windows
You can set up Netscape to run SAS files from the Options menu.
- Choose Preference, then Helper Applications.
- Select New Type...
- Enter application for File Type.
- Enter x-sas for Subtype.
- Enter sas for the file extension
- In the action fields, select Launch Application, and enter the
command to run SAS on your system. For example,
With this command, if Netscape receives a file which is served
as application/x-sas, it will
- Save the SAS file in a temporary directory.
- Run SAS in batch mode on that file.
- The SAS .log and .lst files will be written to Netscape's temporary directory.
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
Sample MOSAIC.INI setup
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:
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.
- in your home directory, create a .mime.types
file with following line:
- in your home directory, put the following line
in the .mailcap file:
application/x-sas; sas %s
- 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
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, (firstname.lastname@example.org)) which runs
SAS in an X-term window:
- copy the .sas program to an incoming directory,
- take precautions that against the .sas program doing any
- run SAS on it in batch mode
- do something intelligent with the output, such as
display the text of the listing file, show a plot.
- clean up
USAGE='Usage: '`basename $0`' <sas-file> '
INCOMING = '~/incoming/web/sas/'
CONFIG = '~/sasuser/myconfig.sas'
## Need an argument
if [ "$1" = "" ]
echo "$USAGE" 1>&2
mv $1 $INCOMING
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
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.
My home page