Notes Re SAS V9 Installation and Usage at OSEDA

(Rev. 3/22/2010)

Contents :  


 

Versions

Version 9.2 is the latest version of SAS, and represents a significant change from Version 9.1 . We now have access to this version for Windows, but to date (7/09) it has not been installed on any of our AIX machines. Version 9.1 is the once-current version of SAS (maintenance release 3) and remains the version which is available for all flavors of Windows, and for our AIX RS6000 (Unix) machines.  (except oseda.missouri.edu), where it now runs as a 64-bit application. We have a site license for use of the software on both these platforms, so there is no extra charge for installations by students or employees of the University of Missouri.  You can even install a copy on your home PC if you would like.

We no longer have or support Version 8 on either platform. Back to top
 

Packages

Under the latest bundling option, the University has access to just about every optional package that SAS Institute offers.  Even if you have no immediate plans for using most of them (QC, ETS, or SPECTRAVIEW to name a few that we have never found anyone using) it is simpler just to do a standard installation that gives you access to all of them.  If you are installing the software on your own machine and are tight on disk space then you might want to do a custom install and specify just which packages you want loaded.  But for client installs, there is virtually no additonal cost in having SAS install everything.

Back to top
 

Windows Installation at OSEDA

This section is new and relatively untested. It is based on just two instances of doing the version 9.2 install - by Keith Jam

To install sas9.2 on your desktop proceed as follows:

  1. Uninstall any previous versions of SAS. If you have created any files within the SAS software directories (such as autoexec or config files) be sure to make backups before uninstalling, since those directories will be deleted as part of the de-installation.
  2. The files that you need to access in order to do the installation are located in something called a SAS depot (which was in turn created by running a setup on one of the orginal installation disks). This was done by Billy Moore in July of 2009 and the resulting SAS Depot can be accessed as your X: drive; to do this from the Windows Explorer window select Tools/Map Network Drive . Type "X:" in the Drive box and in the Folder box type: \\128.206.60.98\SASDepot\
  3. At this point you should close all running applications. You may need to disable any virus protection software such as the Symantec software. (We reconfigured Symantec to disable its automatic file scanning during the installation process. If in doubt, ask for help on this.)
  4. You should be looking at a list of the files in the SAS Depot folder from Windows explorer. To start the installation (using the "SAS Deployment Wizard") click on the setup.exe file in that directory.
  5. You may have to reboot the machine (the installation process seems to need to do this; it prints a message saying that there is a pending reboot although we got this message even in cases where we know it was not true.) Whatever the case, you should be aware that this will probably happen.
  6. The Deployment Wizard asks you to choose a language; at the next menu it has already selected the option "Install SAS Software"; at the next menu choose "Install Additional Software".
  7. The hardest step may be to identify which products to install. Be sure to include SAS Foundation as the critical choice here. Others are up to you. Chances are if you don't know what it is, you won't be needing it.
  8. When we did our installs in July 2009 we were not prompted for a "SID" file because a current version was included in the installation package and the software knew where to find it. Later, when that initial SID file expires, you will be prompted to point to a file with the current licensing information and passwords. Contact John Blodgett or Ray Bacon if you need to find out where the latest SAS SID file is located. (It will probably in in the \sas9 folder on the P: drive).
  9. The installation seems to run pretty smoothly and without need for user input from this point on. Installation time from this point forward is about 45 minutes (as close as we can estimate from memory; if you have a different experience please report to us.)
  10. The installation never asked us where we wanted to install the software (which is unusual and inconsistent with most installs and certainly previous SAS installs) but we can tell you where it put it on our machines:
    c:\Progam Files\SAS\SASFoundation\9.2
    You may want to navigate to this directory and then create a desktop shorcut to the sas.exe file within it. That file is, of course, the sas program (version 9.2).

   Modifying Existing autoexec files

If you have a current SAS autoexec file, you should be able to use it with the new version of SAS without any changes. We keep our autoexec.sas file in our C: drive root directory where SAS always finds it. If you do not have an autoexec file see the Setting up Your Autoexec File section in this document.

Back to top
 

Starting SAS on the Desktop

The easiest way is to add a shortcut to the SAS system to your desktop.  In some previous (and perhaps future) versions of the installation this was done automatically for you, but it does not seem to be the case with the current version.  If you do not know how to create such a shortcut ask for help.    You should also be able to get to the SAS program by the usual Start - Programs - SAS System click sequence.  By default, you can click on a file with the .sas extension from the Windows explorer and start SAS that way as well (but, for some strange reason, it is much slower to start when done this way.)   We assume you will be starting an interactive session.  Batch invocation is a separate issue.   The easiest way is to right click on a .sas program file from the Windows explorer and then select the Batch Submit option.   Another possibility for Ultraedit users is to set up Ultraedit to invoke SAS and pass it the current .sas file that you are editing in Ultraedit.  See Batch Submission Using Ultraedit if you are interested in this option.

Back to top
 

SAS on AIX (UNIX)

Running SAS in the UNIX environment is quite a bit different than on Windows. It reflects the differences in the two operating systems and the .... (to be continued)

Starting Interactive SAS Sessions from AIX

With versions 8 and later of the SAS system you can only run interactive SAS sessions with an X-windows interface.  This means that you need to have X-windows session manager software installed on your PC.  At OSEDA this will usually mean the Hummingbird Exceed software.  Ask Steve for help with having this installed and configured.  Then come see me about a few final configuration items you'll need to take care of before starting your first SAS session under X windows.

The command to start a SAS interactive X windows session is
     sas9 &

The "&" is used to specify a process that you want to have run in background mode.  It does not seem to make sense that your interactive session should be run in background, but it turns out this is the best way.  It starts the interactive window session as a new process and then frees up the window from which you issued the sas9 command, so that you can use it to issue Unix commands while your interactive session is running.  Without the "&" that window is still waiting for the sas9 command to complete and will not let you enter more commands.
Back to top
 

Running SAS in Batch (Background) Mode from AIX

This is something that seems to be  much more likely to be done from the Unix environment than from Windows.  In this mode you create a file with your SAS program statements and then you invoke SAS and point it to that program file, indicating that you want it to execute the statements in the file and then stop; no interactive environment is established (or allowed; some SAS commands are not permitted in batch jobs.)   The easiest way to do this is to use the cd command to make the directory containing the program you want to run the active directory.  Then type:
    sas9 [file-name] -noterminal &
For example, if you have create a SAS program file named first.sas in the practice subdirectory of your home directory, you could run that program in batch mode by issuing the following commands:
cd ~/practice
sas9 first -noterminal &
The tilde (~) is a Unix notation indicating the current user's home directory.  Notice that foward slash separating directories in Unix rather than the backward slashes used in Windows.  There are actually many other possible options that can be entered in the line that invokes SAS, but in most cases you will never need them.  The first option must be the name of the file containing the program to be run.  Notice that the ".sas" extension is implied.   The -noterminal option tells SAS that there is no terminal associated with this session, which would seem to be implicit given that we are specifying to run from a SAS program file rather than starting an interactive session, but it turns out that when certain kinds of errors occur in such programs this option is needed to keep the SAS session from hanging.   The trailing "&" specifies background mode and frees up your current window for entering other Unix commands while your session is running.  If all you plan to do is wait for the SAS program to finish, then you can omit the & in the command.

When these batch SAS programs run, they create a log file and, if you have any standard printed output, a listing file.  In the above example, running the program first.sas from the practice directory would result in the creation of first.log and  first.lst files in that directory.  (No first.lst file would be created if your program did not create any output on the standard SAS print file; this file is the batch equivalent of the Output window in interactive SAS sessions.)   You will, of course, need to have a tool for viewing the results of your batch program.   One easy, standard command for doing this is:
    more first.log
You could also browse the log file in any editor (such as pico or vi) that runs under Unix, or if you are an Ultraedit user, you can browse the log file (as well as creating the .sas file program in the first place) using the FTP features of that editor.  This is our second favorite way of doing batch SAS processing on Unix.  The favorite way involves submitting SAS jobs to the background from X-Windows SAS sessions and is too complicated for this document.  See the author's paper in the on-line Proceedings from SUGI 22 if interested.

Note:

Using this method involves assigning certain SAS commands to certain keys on your keyboard. Getting the X-windows application to recognize the necessary keys involves a special system specs file. How you specify this to your UNIX X-windows application is a good example of why people prefer Windows to UNIX. You have a UNIX environment variable called XAPPLRESDIR. The value of this variable (which typically gets assigned in a file named .profile in your home directory) is a path (directory). Within this directory, applications that are looking for information on how to set up their interace with the X software will look for files within this directory. The SAS software looks for a file named SAS in this directory.
We have created one of these files in my "X applications directory" which you can either copy or point to. The file is /u/john/john-app-defaults/SAS . If your user name is mary you might want to create a directory named mary-app-defaults in your home directory (i.e. in /u/mary). Then you could type the commands: cd ~/mary-app-defaults cp /u/john/john-app-defaults/SAS . This will create the file named SAS in your current directory, which is your X application defaults directory. Or at least it will be if (and only if) you have the following lines in your .profile file (in your home directory):
XAPPLRESDIR=$HOME/$LOGNAME-app-defaults
export XAPPLRESDIR

If you do not already have such a directory and would rather not have one you can always just point to mine. I.e. add the following lines to your .profile instead of the above:
XAPPLRESDIR=/u/john/john-app-defaults
export XAPPLRESDIR
Now you do not have to create the directory and copy the SAS file.
Back to top

 

Copying Display Manager Key Definitions

You may find it convenient to be able to copy DM key defintions so you don't have to enter them from the Keys window. We have created a public catalog with standard key definitions, specifically for use with the "interactive batch" mode of submitting SAS programs. To make these key defintions your own you need to start an interactive SAS session, making sure that the sasuser library is your current sasuser library. Then you should be able to submit the following code:
libname sasctlgs '/pub/sasctlgs/v9'; *<---this should already be defined in your autoexec.sas file---;
proc build c=sasuser.profile batch;
merge c=library.keydefs etype=keys replace; run;
*--need the following statement, run from Display Manager, to make them effective *immediately*--; dm 'keys ; copy dmkeys; save; end';
After running this code you should be able to use the following keys on the keypad of your keyboard (NumLock should be on): Note that if it works you should be able to open the Keys window to verify these definitions by hitting F2 . (If hitting F2 does not open the Keys window then it did not work.)

Documentation

The best and primary source of documentation for SAS software is the SAS Online Doc.  This product provides the content that once appeared in dozens of fat SAS manuals as on-line "books" in both HTML and PDF format. To access the HTML version you need to start a web browser (Internet Explorer is advertised to be "better" for this, but I have used both IE and Netscape and have not really noticed much difference) and open the URL:
http://support.sas.com/onlinedoc/913/docMainpage.jsp .

    On Line Help from Interactive Windows Session

There is also some direct on-line help available to you when running an interactive SAS session on Windows (we strongly recommend ignoring the online help under Unix).  It is typically much less detailed than what is avaiable in the Online Doc.  If you select the Help option off the top menu bar while in an editor window you will get a drop-down window with a number of options for SAS help.  The problem with the SAS help for new users is that there is almost too much of it, and it is frequently (like a lot of SAS in recent years) somewhat redundant.  There are almost too many choices, with none of them necessarily the obvious best way.  There are even several interactive tutorials avaiable off this page when you select the Getting Started With SAS Software option or if you select Books and Training and then SAS Online Tutor.  The former is a basic tutorial that will let you get familiar with the basics of SAS, including the Windows interactive environment.   The latter is an extensive tutorial that takes you through a series of rather detailed interactive lessons in using the software.  It appears that we have some kind of installation problem with this tutorial which we need to resolve so that it gets installed properly for client versions of SAS.  However, you can invokde the tutorial from your browser by using the following URL:
    http://128.206.60.81:2575/help/oltutor.hlp/welcome.htm .
You should have an interactive SAS session running before invoking this URL.  You should bookmark this URL so that you can start the tutorial easily from your browser directly, rather than via the Help menu in SAS.  (The tutorial requires a web server to be run directly on the desktop and most of our PC's do not have a web server installed.)
 

    help keyword   command

A very useful and not very well documented feature of the SAS on-line help is that you can at any time go to the command box and type the word help followed by a keyword that is the name of a sas procedure, a sas statement, a sas function, a sas option, etc.  The result is a new help window opening with some sort of help related to the keyword topic.  The usefulness of this help can vary a great deal.  In the case of SAS statement keywords (such as retain, set, input , etc.) it takes you to a single help page where all the SAS statements are summarized in a very brief here's-the-syntax manner which is probably only going to be useful if you already know the answer to your question but just need a reminder of what the syntax is.  But in many cases that is all you will need.  So, if you know that there is some option on the infile statement that can be used to specify that this is a comma-delimited file you can type "help infile" and get this page (it will not even take you directly to the infile portion of the page, you will need to scroll to it), and you will be able to get a list of the option keywords for that statement and when you see the dsd option you will have the information you need.  For an actual explanation and example of what this option is all about you would want to go to the Online Doc.
 
 

    SAS Books

There are not nearly as many books (hard copy) about SAS as there used to be.  We still have a few left over from the late 80's but these are clearly obsolete in many ways.   We do have several copies of  The Little SAS Book by Delwiche and Slaughter, which we use as the outline of our in-house short course for new SAS users.  We also have one copy each of DiIorio's SAS Applications Programming: A Gentle Introduction and the SAS Institute manual Step-by-Step Programming with Base SAS Software.  Either of these can be checked out from the author for up to 3 days at a time.
 

Back to top

 

Setting up Your SAS Autoexec File

As with many software applications SAS provides a way to have a series of initialization commands/statements that can be specified which will be executed at the time SAS begins execution (in either interactive or batch mode.)  This is done using a file named autoexec.sas, which is typically stored in the same directory where you install SAS.  The latter directory is typically referred to within the SAS system as !sasroot .  (The value of this symbolic variable is specified in your SAS configuration file; to view your SAS configuration file from within a SAS session enter the command:  fslist '!sasroot\sasv9.cfg'  in the command box.  Look for the line that begins with -SET sasroot  . For example, on my desktop the complete line used to be -SET sasroot d:\sas8   which meant that at that time I had installed SAS on my d: drive in the directory \sas8.)    On Unix systems where many users share the SAS root directory, you should store your autoexec.sas file in your home directory.    SAS will search for an autoexec.sas file there first, before looking for one in !sasroot.

We have set up a special OSEDA-default autoexec file for both Windows and AIX.   For Windows it is stored on the P: shared drive in the \sas9 directory, filename autoexec.sas.   It currently contains the following statements (but you should always point to the current version of that file, not to these lines): 

%let ourpath=%str(P:\SAS Tools);  *--edited 10-29-07 after L: drive went away--; 

*--Following 2 statements allow SAS to search for and make use of our standard SAS
   permanent format library.  Required because we have refs to these in many datasets;
libname sasctlgs v9 "&ourpath\sasctlgs";    *<==========Updated to v9 format catalog 10-08 !!==;
options fmtsearch=(sasctlgs sasuser library);

*--as of 1/05 the sampdata directory was empty--;
libname sampdata   "&ourpath\sampdata" access=readonly;

*--the sysprint option syntax has changed for v7. The port spec not used (LPTx:)-;
*--options sysprint="HP LaserJet 8000 PCL 6";
*--Cannot get the sysprint option to work any more, but it should default OK-;

filename sasmacro "&ourpath\sasmacro";
 options mautosource sasautos=(sasmacro sasautos);

filename sascode  "&ourpath\sascode";
*filename copykeys "&ourpath\sascode\copykeys.sas";

**filename rlink '!sasroot\connect\saslink\tcpunix.scr';*--fix later-;
filename  rlink 'p:\sas9\tcpunix.scr';   *--connects to a v9 session on AIX;

%let oseda=oseda.missouri.edu;

%let mcdc=mcdc2.missouri.edu;  *--added 7-25-01-;
options comamid=tcp remote=mcdc noxwait noxsync;  *--remote option changed from oseda to mcdc, 11-2-05-;
There are a number of things that this autoexec does for you.  Mostly it issues libname and filename statements to define some key shared resource files.  For example, it defines the file rlink where it will find the special script file used to connect to a remote Unix session using the tcp access method.   It references a number of files and directories stored in the special L:\SAS Tools directory. This, of course, will not work for anyone trying to run SAS from a location that does not have access to the OSEDA LAN, where the L: drive lives.   Those of you wanting to run SAS outside of this environment are going to have to either make your own copies of these files/directories and edit this autoexec file to reference the copies, or live without some of the convenience/power features that the autoexec provides.   These can be summarized as follows: Another file that you will find in the P:\sas9 directory is named model.autoexec.sas.  We encourage you to use this file as the template for your personal autoexec.sas file.  You should open a copy of this file in a text editor and save the edited version on your drive as file c:\autoexec.sas.
You should note the statements:
    *--include the standard autoexec file stored on the shared drive.--;
    filename sysautox 'P:\sas9\autoexec.sas';
    %include sysautox;
What this does is to have the standard oseda autoexec file be executed as part of your own personalized autoexec module.  This way everyone can easily share the statements that we all tend to use, and then code the things that will personalize your own session, such as special libname or filename statements referencing libraries and files that you tend to use all the time.

For AIX SAS users the equivalent of the P:\sas9\autoexec.sas file is stored in /mscdc/sascode/autoexec8.sas (on oseda - is anyone still running sas9 on this box?) and in /pub/sascode/autoexec9.sas (on mcdc2 and any other future AIX boxes).   These will be invoked by default for any SAS startup.  You can create your own personal autoexec.sas file in your home directory as file autoexec.sas.  Such a file should include a %include statement referencing the default file, i.e. the SAS statement:
    %include '/pub/sascode/autoexec9.sas';

This autoexec provides the same kind of setup access to the formats and macro libraries as the Windows version does.


Back to top

 

SAS/Connect Setup

SAS/Connect is the component of SAS software that permits you to be running SAS on one platform (the "local" session) while being linked to one or more instances of SAS running on a different platform (the "remote" session(s)).  At OSEDA, this typically means running SAS under Windows as the local session, while accessing a SAS session running on one of the AIX Unix machines as the remote session.  In order for this connection to be established your machine has to have an Internet connection and you have to specify your remote session's IP address.  A special script file, associated with the special filename ("fileref" is the proper SAS terminology for this kind of file nickname) rlink needs to be defined as well.  This script provides commands necessary for you to login to the remote system and initiate a special kind of SAS session.  The OSEDA standard autoexec.sas file contains SAS statements that will take care of the housekeeping tasks needed to establish the linkage from your Windows session to a remote session on any OSEDA  Unix box  (any of our AIX sites that have SAS installed).  All you should need to do to connect to an AIX platform is enter the command "signon" from the command line of your PC SAS session.  You will then be prompted to enter your userid and password as part of the remote login process.   Obviously, this means that you cannot use SAS/Connect unless you have an active userid on the remote site and know your password.

Automating the Signon Process With Custom Connect Profile

If you do this enough (i.e. signon to remote sessions)  that you would like to automate the signon so that your userid and password are embedded in the script, you can proceed as follows:
  1. From a SAS editor window (or Ultraedit - any text editor will do) open the file
    P:\sas9\tcpunix2.scr
  2. Read the comments in the first few lines of this file. They explain what the script is about.
  3. Per the instructions in the comments edit the file to include your unix userid and password.
  4. Save the file to your C: drive. Suggest using C:\tcpunix2.scr. Do not save back to the P: drive, unless you want your userid and password to be public information!
  5. Now you have to tell SAS to use the new script file whenever you execute a signon command. To do this:
    • Open your autoexec.sas file using your favorite editor. (This is usually file c:\autoexec.sas).
    • Add the following lines following the line %include sysautox;
      filename rlink clear;
      filename rlink 'c:\tcpunix2.scr'; *<--or whatever you called it when you saved it, above.;
    • If you want to test this to make sure it works, just submit the above 2 lines during a SAS session. Then try entering a signon command. If everything works as planned, you should be signed on without having to enter a userid or password.
    • Save your edited autoexec file. The next time you start SAS it should point to this new script file and you should not have to ever enter your userid and password again.

    This also makes it much easier to run batch jobs that have dynamic signon statements.

    Back to top

     

    SAS/Share Servers

    Note: This is a somewhat general discussion of SAS/Share servers and the steps required to make use of them. See the web page at http://mcdc2.missouri.edu/jgb/sas9/mcdcshr.html for a discussion specfically aimed at the mcdcshr server running on the mcdc2.missouri.edu UNIX server. Much of the material covered here is covered in the mcdcshr document as well.

    While establishing a remote session via SAS/Connect is a good way to have access to data stored on remote Unix systems while having the benefits of the more user friendly Windows interactive environment, there are some drawbacks to using SAS/Connect.  One of the most obvious is that you have to have an active userid in order to signon to the remote system.   Another has to do with efficiency involved with the extra overhead of starting up all those remote sessions (which sometimes leave behind worthless SAS sessions and their temporary file allocations when something goes wrong and the remote link gets broken.)  A good alternative for users who just want to be able to access data on those remote sites, but without the ability to actually run SAS code on the remote system, is to take advantage of something called a SAS/Share Network server.  These are just instances of SAS that run on the remote machines as a service application (much like an ftp service).   To use a SAS/Share server requires several things on the part of the SAS user running on a Windows (or even another Unix) client:

    • You have to create an entry in your local machine's services file defining the service.  See details below.
    • You have to create a macro variable containing the IP address of the server that can be used as part of the reference to the service from within SAS.
    • You need to know the name of the SAS/Share server and, in most cases, the password for accessing it.
    • Some SAS/Share servers let you code your own libname statements that point to directories on the server machine.  For example I could code something such as:
      libname myname '/pub/data/pl9490' server=mcdc.servername sapw=sesame;
      Here, I choose my own libref  ("myname") and I have to specify the path within quotes.  As always, I have to specify the 2-part server name and (if required by the way the server was set up) a server access password (sapw).  The first part of the server name corresponds to a macro variable which has been assigned the IP address of the server.  So, for example, we have the SAS statement 
      %let mcdc=mcdc2.missouri.edu; 
      in our autoexec.sas file which defines the macro variable mcdc; so SAS would be looking for a SAS/Share service running on that machine.  The second level name - "servername" in our example - identifies the specific SAS/Share server running on that machine.  This name is the one specified when the server is initiated on the server machine and is also the name that is specified in your local machine's services file.
    • Other SAS/Share servers do not permit the client session to define their own librefs and paths.  Instead, they have pre-defined libref's pointing to predefined directories, and usually specifying read-only access, that users can access.  In this situation, the syntax for a libname statement will be similar to our previous example except that the path value enclosed in quotes will be omitted and the name specified (i.e. the libref -- which in our example was myname) must match the name used when the pre-defined reference was set up on the server.
    • The mcdcshr SAS/Share server that we run on the mcdc2.missouri.edu machine is set up as described above. It provides read only access to a pre-defined set of data libraries. You can (if you are authorized - i.e. if you know that access password) use this server to access the most popular data collections here at OSEDA/MCDC by coding a libname statement as simple as the following:
      libname sf1 server=mcdc.mcdcshr;
      Here, the name "sf1" is the pre-defined libref. It happens to point to the data directory /pub/data/sf12000 on the mcdc2 AIX box. But you do not need to know or code the path. All you need to know is what name we used when we created the pre-defined reference to it when the server was started. See the reference, below, to the actual SAS code file used to created these predefined data libraries.

        Adding the entry to your local services file

    On my Windows NT machine the special file where services get defined is c:\winnt\system32\drivers\etc\SERVICES.  In order to access the demoserv SAS/Share server running on the oseda AIX machine (oseda.missouri.edu) I have added the entry:
        demoserv 8010/tcp    #--SAS/Share server
    to this services file.   Here demoserv is the name of the server as it was defined when I started the SAS/Share service on the oseda platform, and 8010 is the port number associated with the service on my machine.   The "/tcp" indicates that the type of service; all SAS/Share servers (at least the ones we'll be using) are of the type tcp.

    In that same services file I also have the following two entries:
        mcdcshr          8012/tcp    #--SAS/Share server on mcdc2, public
        mcdcshr2        8013/tcp    #--non-public SAS/Share server on mcdc2

    These lines allow me to access two other SAS/Share services running on the mcdc2.missouri.edu (Missouri Census Data Center machine at OSEDA).  The first is a public server, the second a private one.  To access any of these you will need to create the entries in your services file and you will need to know the access passwords for them.  We will provide you with the access passwords we think you will need.  For security reasons, they will be subject to periodic change and will not be published.   We plan to create a separate document that will provide more detailed information about specific SAS/Share servers running on the oseda machines. In the mean time you can see the librefs that are pre-defined for our two key servers by viewing two members of the /pub/sascode library on mcdc2. The members are


     

        SAS/Share from Unix machines

    This works on Unix platforms as well, but you do not have to do anything about a services file.  That is handled by the Unix system administrator, and everyone gets to share the work.   What this means is that if you are running a SAS program on the mcdc2 AIX platform and need to access a SAS data set stored on the oseda.missouri.edu machine you can do so by coding something such as:
         libname coredata server=oseda.demoserv sapw=xxxxxx;  *-- (substitute actual password here) -;
    All you need to do to insure this works is to have the statement
        %let oseda=oseda.missouri.edu;
    specified somewhere, such as in an autoexec.sas file.  Once this libname statement has been submitted and successfully allocates the library reference you can use the various interactive windows to display metadata and data associated with the data library.  In this coredata example, above, I could use the Display Manager (DM) command
        dir coredata
    to get a window with the list of SAS data sets in this library.   I could then left click on any of thoese data sets and be browsing the actual data within them using a Viewtable window.  Or, I could right click (and hold down the right button - bug, I believe) on one and click on View Columns  to get a "Properties" window that will display all the variables in that data set along with metadata such as the type (numeric or character), label, and format codes.   You can also bring up this information directly by going to the command box and typing
        var coredata.building .
    Similarly, you can directly browse the data using either the viewtable or fsbrowse windows by entering the commands:
        vt  coredata.building
        fsb coredata.building .
    This is, of course, not restricted to the Unix environemnt.  These commands also work just fine in Windows.

    Back to top

     

    Getting Help

    Online help is a great thing and can make learning SAS without the manuals almost doable.  But there are always going to be situations where you get stuck and need the help of an actual human being.   SAS Institute offers award winning technical consulting services, but these are not supposed to be used directly by all the people at a site that has a site license.  So you should not be directly contacting SAS support services with your questions.   Instead, you should be consulting your local SAS support specialist.  For the time being at OSEDA that will be the author, John Blodgett.  If at all possible, please send your questions via e-mail and try to include as much detailed information about what happened, or what you want to happen, as possible.   It is hoped that after we get more people trained in the use of SAS at our site, that we can divide up this support function among many more people.  We will put their names here.

    No assistance will be given to anyone who is found to not have access to the SAS Online Doc facility.  Without that access, learning or using SAS is virtually impossible.  In many instances, our reply to your question may simply be a URL pointing to the page in the online doc that answers your question.   Remember to RTFM -- Read the Friendly Manual -- before asking for consulting help.  If you ask "How can I get proc print to print double spaced" the answer will be
         file:/L|/SAS OnlineDoc v9/sasdoc/sashtml/proc/z0057825.htm -- the page within the online doc describing the Print procedure.

    Back to top

     

    Batch Submission Using Ultraedit

    If you use the Ultraedit ("UE") editor to edit your SAS programs you can configure UE to start SAS and run the current program file in batch mode. To make this work you need to do a special configuration of the Toolbar menu in UE. Here are the steps you must follow to do this:
    1. Click on Advanced on the toolbar menu, and then on Tool configuration... on the dropdown.
    2. In the dialog window you need to type an entry in the "Command Line" box. This is the hard part. The key here is to type the command that you use to start SAS on your system. Typically, the easiest way to get this information is from the icon on your desktop that you use to invoke SAS. If you right click on this icon and then choose "Properties" you will get a window that includes a box labeled "Target". This is where the command is stored; you should be able to right click the Target box and then select "Copy" to store the command line in clipboard. Then you go back to the UE window and paste this text into the Command Line box.

      As an example of what this will look like, on my desktop the command used to start sas is:

      C:\Program Files\SAS\SASFoundation\9.2\sas.exe -CONFIG "C:\Program Files\SAS\SASFoundation\9.2\nls\en\SASV9.CFG"  
       
    3. You now have the gist of what you need in the Command Line box but you need to do some editing. Go to the end of the current line (the part you just pasted) and continue it by typing
      -noicon -nosplash -batch -sysin %n . These are 3 useful SAS system options for running a batch job (noicon, nosplash and batch) followed by the critical "-sysin" option where you can specify the name of the file containing the sas program that is to be run. In the Ultraedit world the "%n" reference causes the name of the current file to be inserted (without the ".sas" extension, which is implied.)
    4. In the Working Directory box all you have to enter is %p. This reference will cause UE to tell SAS to start from the directory (path) associated with the file that is currently being edited.
    5. In the Menu Item Name box just type "sas8" (or whatever you want to appear on the menu.)
    6. Check the two option boxes "Check if Windows program" and "Save all files first".
    7. Click on the "Insert" button on the right in order to insert the new entry. Then on OK to leave the window.

    This completes the configuring of this new "Invoke SAS in batch tool". To use it, you need to open the .sas file containing the program you wish to run in batch. Then click on the Advanced item on the toolbar. You should now see an extra item at the bottom of the dropdown menu -- labeled "sas8" (or whatever you entered in the "Menu Item Name" box while configuring.) Click on the new option and it should automatically save the current file and run the sas command that you specified, passing it the name of the current program file and path (working directory). A mini window will open up telling you that SAS is running and showing the name of the file being used. When the program completes, this window will close.

    When the program completes you can view the resulting .log and .lst file (if any) using UltraEdit. Just select File-Open and pick these files out of the current directory. I.e. if you are running a program named test1.sas in the C:\mysaspgms directory, you should be able to view the file C:\mysaspgms\test1.log and/or c:\mysaspgms\test1.lst .

    If there are errors in the program or if you need to run it again, you can do so by editing the .sas file and submitting the job again. If you still have the .log file open in UE, it will actually tell you that another program has modified this file and ask you if you want to reload it. This is very handy (although for some inexplicable reason it seems to only work part of the time.)

    Feedback

    Please direct all feedback -- questions, comments, suggestions, etc. (e-mail preferred) to the author:
    John Blodgett
    OSEDA (Office of Social & Economic Data Analysis)
    626 Clark Hall -- University of Missouri
    Columbia, MO  65211
    PH: 573-884-2727  FX: 573-884-4635
    e-mail: blodgettj@umsystem.edu
    URL: http://mcdc2.missouri.edu/jgb/sas9/usgnotes.html