Many software applications are either menu driven, or command driven (enter a commandsee
the result). SAS is neither. With SAS, you use statements to write a series of instructions called a
SAS program. The program communicates what you want to do and is written using the SAS
language. There are some menu-driven front ends to SAS, for example SAS Enterprise Guide
software, which make SAS appear like a point-and-click program. However, these front ends still
use the SAS language to write programs for you. You will have much more flexibility using SAS
if you learn to write your own programs using the SAS language. Maybe learning a new
language is the last thing you want to do, but be assured that although there are parallels
between SAS and languages you know (be they English or FORTRAN), SAS is much easier to
SAS programs A SAS program is a sequence of statements executed in order. A statement
gives information or instructions to SAS and must be appropriately placed in the program. An
everyday analogy to a SAS program is a trip to the bank. You enter your bank, stand in line, and
when you finally reach the teller’s window, you say what you want to do. The statements you
give can be written down in the form of a program:
I would like to make a withdrawal.
My account number is 0937.
I would like $200.
Give me five 20s and two 50s.
Note that you first say what you want to do, then give all the information the teller needs to
carry out your request. The order of the subsequent statements may not be important, but you
must start with the general statement of what you want to do. You would not, for example, go
up to a bank teller and say, “Give me five 20s and two 50s.” This is not only bad form, but would
probably make the teller’s heart skip a beat or two. You must also make sure that all the
subsequent statements belong with the first. You would not say, “I want the largest box you
have” when making a withdrawal from your checking account. That statement belongs with “I
would like to open a safe deposit box.” A SAS program is an ordered set of SAS statements like
the ordered set of instructions you use when you go to the bank.
SAS statements As with any language, there are a few rules to follow when writing SAS
programs. Fortunately for us, the rules for writing SAS programs are much fewer and simpler
than those for English.
The most important rule is
Every SAS statement ends with a semicolon.
This sounds simple enough. But while children generally outgrow the habit of forgetting the
period at the end of a sentence, SAS programmers never seem to outgrow forgetting the semicolon
at the end of a SAS statement. Even the most experienced SAS programmer will at least
occasionally forget the semicolon. You will be two steps ahead if you remember this simple rule.
Chapter 1: Getting Started Using SAS Software 3
Layout of SAS programs There really aren’t any rules about how to format your SAS
program. While it is helpful to have a neat looking program with each statement on a line by itself
and indentions to show the various parts of the program, it isn’t necessary.
SAS statements can be in upper- or lowercase.
Statements can continue on the next line (as long as you don’t split words in two).
Statements can be on the same line as other statements.
Statements can start in any column.
So you see, SAS is so flexible that it is possible to write programs so disorganized that no one can
read them, not even you. (Of course, we don’t recommend this.)
Comments To make your programs more understandable, you can insert comments into your
programs. It doesn’t matter what you put in your commentsSAS doesn’t look at it. You could put
your favorite cookie recipe in there if you want. However, comments are usually used to annotate
the program, making it easier for someone to read your program and understand what you have
done and why.
There are two styles of comments you can use: one starts with an asterisk (*) and ends with a
semicolon (;). The other style starts with a slash asterisk (/*) and ends with an asterisk slash (*/).
The following SAS program shows the use of both of these style comments:
* Read animals’ weights from file;
INPUT Lions Tigers;
PROC PRINT DATA = animals; /* Print the results */
Since some operating environments interpret a slash asterisk (/*) in the first column as the end of a
job, be careful when using this style of comment not to place it in the first column. For this reason,
we chose the asterisk-semicolon style of comment for this book.
Errors People who are just learning a programming language often get frustrated because their
programs do not work correctly the first time they write them. To make matters worse, SAS errors
often come up in bright red letters, and for the poor person whose results turn out more red than
black, this can be a very humbling experience. You should expect errors. Most programs simply
don’t work the first time, if for no other reason than you are human. You forget a semicolon,
misspell a word, have your fingers in the wrong place on the keyboard. It happens. Often one small
mistake can generate a whole list of errors. Don’t panic if you see red.