When a SAS program is executed, SAS generates a log. The log echoes program statements, provides information about computer resources and provides diagnostic information.
Understanding the log enables you to identify and correct errors in your program. The log contains three types of messages: Notes, Warnings and Errors. Although notes and warnings will not cause the program to terminate, they are worthy of your attention, since they may alert you to potential problems. An error message is more serious, since it indicates that the program has failed and stopped execution.
Most of the errors can be easily corrected and this page discusses how some common errors occur and how to correct them.
Strategies in finding and correcting errors
1. Start at the beginning
Do not become alarmed if your program has several errors in it. Sometimes there is a
single error in the beginning of the program that causes the others. Correcting this error
may eliminate all those that follow. Start at the beginning of your program and work down.
2. Debug your programs one step at a time
SAS executes programs in steps, so even if you have an error in a step written in the
beginning of your program, SAS will try to execute all subsequent steps, which wastes not
only your time, but computer resources as well. Simplify your work. Correct your programs
one step at a time, before proceeding to the next step. As mentioned above, often a single
error in the beginning of the program can create a cascading error effect. Correcting an
error in a previous step may eliminate other errors.
Look at the statements immediately above and immediately following the line with the error. SAS will underline the error where it detects it, but sometimes the actual error is in a different place in your program, typically the preceding line.
3. Look for common errors first
Most errors are caused by a few very common mistakes.
Common errors
1. Missing semicolon
This is by far the most common error. A missing semicolon will cause SAS to misinterpret
not only the statement where the semicolon is missing, but possibly several statements
that follow. Consider the following program, which is correct, except for the missing
semicolon:
proc print data = auto
var make mpg;
run;
The missing semicolon causes SAS to read the two statements as a single statement. As a result, the var statement is read as an option to the procedure. Since there is no var option in proc print, the program fails.
proc print data = auto
44 var make mpg;
------------
202 202 202
45 run;
ERROR 202-322: The option or parameter is not recognized.
NOTE: The SAS System stopped processing this step because of errors.
The syntax for the following program is absolutely correct, except for the missing semicolon on the comment:
* Build a file named auto2
data auto2;
set auto;
ratio=mpg/weight;
run;
34 * Build a file named auto2
35
36 data auto2;
37 set auto;
-------
180
ERROR 180-322: Statement is not valid or it is used out of proper order.
38 ratio=mpg/weight;
-------
180
ERROR 180-322: Statement is not valid or it is used out of proper order.
39 run;
Taken out of the context of the program, both statements are correct.
set auto; ratio=mpg/weight;
However, SAS flags them as errors because it fails to read the data statement correctly. Instead, it reads this statement as part of the comment.
* Build a file named auto2 data auto2;
Why? Because the first semicolon it encounters is after the word auto2. Consequently the two correct statements are now errors.
2. Misspellings
Sometimes SAS will correct your spelling mistakes for you by making its best guess at what you meant to do. When this happens, SAS will continue execution and issue a warning explaining the assumption it has made. Consider for example, the following program:
DAT auto ; INPUT make $ mpg rep78 weight foreign ; CARDS; AMC 22 3 2930 0 AMC 17 3 3350 0 AMC 22 . 2640 0 ; run;
Note that the word "DATA" is misspelled. If we were to run this program, SAS would correct the spelling and run the program but issue a warning.
68 DAT auto ;
----
14 69 INPUT make $ mpg rep78 weight foreign ;
70 CARDS; WARNING 14-169: Assuming the symbol DATA was misspelled as DAT.
NOTE: The data set WORK.AUTO has 26 observations and 5 variables.
Sometimes SAS identifies a spelling error in a note, which does not cause the program to fail. Never assume that a program that has run without errors is correct! Always review the SAS log for notes and warning as well as errors.
The following program runs successfully, but is it correct?
data auto2; set auto; ratio = mpg/wieght; run;
A careful review of the SAS log reveals that it is not.
75 data auto2;
76 set auto;
77 ratio = mpg/wieght;
78 run;
NOTE: Variable WIEGHT is uninitialized.
NOTE: Missing values were generated as a result of performing an
operation on missing values.
Each place is given by:
(Number of times) at (Line):(Column). 6 at 77:15
NOTE: The data set WORK.AUTO2 has 26 observations and 7 variables.
Sometimes missing values are legitimate. However, when a variable is missing for every record in the file, there may be a problem with the program, as illustrated above. More often, when your program contains spelling errors, the step will terminate and SAS will issue an error statement or a note underlining the word, or words, it does not recognize.
65 proc print
66 var make mpg weight;
----
76
67 run;
ERROR 76-322: Syntax error, statement will be ignored.
NOTE: The SAS System stopped processing this step because of errors.
In this example, there is nothing wrong with the var statement. Adding a semicolon to the proc print solves the problem.
proc print; var make mpg weight; run;
The following code will successfully create a new dataset auto2.
data auto2; set uato; ratio = mpg/weight; run;
However, because we misspelled the dataset name in the set statement, the new dataset contains 0 observations.
2 data auto2;
3 set uato;
ERROR: File WORK.UATO.DATA does not exist.
4 ratio = mpg/weight;
5 run;
NOTE: The SAS System stopped processing this step because of errors.
WARNING: The data set WORK.AUTO2 may be incomplete. When this step was stopped there were 0
observations and 7 variables.
The error message indicates that no dataset exists with the name uato and the warning message hints that the new dataset may be problematic. Correcting the spelling solves the problem.
3. Wrong data type
Consider the following data step. It runs without an error message. But does it give us the intended result?
data test; input a b; cards; john 1 megan 2 ; run;proc print data = test; run;Obs a b 1 . 1 2 . 2
Obviously, variable "a" has not been created as desired. This is because that "a" should be created as a character variable using the dollar sign specification for character variables. Instead, since the dollar sign is missing, SAS assumes that "a" is of numeric type, such as an integer or a real number and SAS expects to encounter a numeric value whenever it is ready to read in something for "a". Now, let’s take a look at the log and see how SAS reacts to not seeing a number for "a":
2308 data test;
2309 input a b;
2310 cards;
NOTE: Invalid data for a in line 2311 1-4.
RULE: ----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8----+-
2311 john 1
a=. b=1 _ERROR_=1 _N_=1
NOTE: Invalid data for a in line 2312 1-5.
2312 megan 2
a=. b=2 _ERROR_=1 _N_=2
NOTE: The data set WORK.TEST has 2 observations and 2 variables.
NOTE: DATA statement used (Total process time):
real time 0.01 seconds
cpu time 0.01 seconds
2313 ;
2314 run;
2315 proc print data = test;
2316 run;
NOTE: There were 2 observations read from the data set WORK.TEST.
NOTE: PROCEDURE PRINT used (Total process time):
real time 0.00 seconds
cpu time 0.00 seconds
Indeed, there are no error messages in red. But each NOTE offers some detailed information. The first NOTE says that the data for variable "a" is invalid in line 2311 position 1-4. Since line 2310 is the line corresponding to the statement "cards;", line 2311 corresponds to the first line of data which starts with input john. So the NOTE is basically saying that "john" is not a valid numeric value. Once we understand the message, correcting our code is usually simple enough and in this case, we just need to add a dollar sign after variable "a" in the input statement as shown below.
data test; input a $ b; cards; john 1 megan 2 ; run;
4. Unmatched quotes/comments
Unclosed quotes and unclosed comments will result in a variety of errors because SAS will fail to read subsequent statements correctly. If you are running interactively, your program may appear to be doing nothing, because SAS is waiting for the end of the quoted string or comment before continuing. For example, if we were to run the following program,
proc print data = hsb2 (obs=10); var write math; title "printing first ten observations'; run;
SAS would not execute the run statement. Instead it reads it as part of the title statement, because the title statement is missing the closing double quotes. When this block of code is run, the program would appear to be doing nothing. System messages would indicate that it is running, which in fact it is. However, SAS is reading the rest of the program, waiting the double quote that will end the step it is currently stuck on.
Nothing appears in the output window (not shown). If we check the log, it does not have any blue notes indicating that the code has been executed.
In the program editor window, the font color offers a hint that something is amiss. Everything appearing after the opening double quote of the title appears in purple. If we correct the program by replacing the single quote with a double quote, as follows,
proc print data = hsb2 (obs=10); var write math; title "printing first ten observations"; run;
the program will now run successfully and here is what we should see in the output:
printing first ten observations Obs write math 1 31 44 2 40 43 3 65 48 4 44 49 5 57 50 6 41 43 7 52 41 8 49 43 9 59 63 10 37 42
5. Mixing proc and data statements
Since the data and proc steps perform very different functions in SAS, statements that are valid for one will probably cause an error when used in the other. Although a program may include several steps, these steps are processed separately.
A step ends in one of three ways:
1. SAS encounters a keyword that begins a new step (either proc or data)
2. SAS encounters the run statement, which instructs it to run the previous step(s)
3. SAS encounters the end of the program.
Each data, proc and run statement causes the previous step to execute. Consequently, once a new step has begun, you may not go back and add statements to an earlier step. Consider this program, for example.
data auto2; set auto; proc sort; by make; ratio = mpg/weight; run;
SAS creates the new file auto2 when it reaches the end of the data step. This occurs when it encounters the beginning of a new step (in this example proc sort). Consequently, the assignment statement (ratio = mpg/weight;) is invalid because the data step has been terminated, and an assignment statement cannot be used in a procedure.
40 data auto2;
41 set auto;
NOTE: The data set WORK.AUTO2 has 26 observations and 5 variables.
NOTE: The DATA statement used 0.12 seconds.
42 proc sort; by make;
43 ratio = mpg/weight;
------
180
44 run;
ERROR 180-322: Statement is not valid or it is used out of proper order.
NOTE: The SAS System stopped processing this step because of errors.
Simply moving the assignment statement solves the problem.
data auto2; set auto; ratio = mpg/weight; proc sort; by make; run;
7. Using options with the wrong proc
Similarly, although many options work with a variety of procedures, some are only valid when used with a particular procedure. Remember to evaluate all errors in context. A perfectly correct statement or option may cause an error not because it is written incorrectly, but because it is being used in the wrong place.
88 proc freq data = auto2;
89 var make;
---
180
90 run;
ERROR 180-322: Statement is not valid or it is used out of proper order.
NOTE: The SAS System stopped processing this step because of errors.
The var statement is not valid when used with proc freq. Change the statement to tables and the program runs successfully.
proc freq data = auto2; tables make; run;
Conversely, the tables statement may not work with other procedures.
92 proc means data = auto2;
93 tables make;
------
180
94 run;
ERROR 180-322: Statement is not valid or it is used out of proper order.
NOTE: The SAS System stopped processing this step because of errors.
In this example, the var statement is correct:
proc means data = auto2; var make; run;
8. Logic errors
Consider the log generated when the following program is run:
106 data auto2; 107 set auto; 108 if tons > .5; 109 tons = weight/2000; 110 run; NOTE: The data set WORK.AUTO2 has 0 observations
Although the program ran with no errors, the new data set has no observations in it. Since we would expect most cars to weigh more than half a ton, there is probably an error in the program logic. In this case, we are subsetting on a variable that has not yet been defined.
Changing the order of the programming statements yields a different result:
118 data auto2; 119 set auto; 120 tons = weight/2000; 121 if tons > .5; 122 run; NOTE: The data set WORK.AUTO2 has 26 observations.
9. Missing options when dealing with missing data
Consider following data stored in a text file called test.txt and the data step for reading the data.
john 11 megan 22 4data test; infile 'd:temptest.txt'; input a $ age y; run; proc print data = test; run;
Here is the output from proc print:
Obs a age y 1 john 11 .
This is obviously not what we have intended. There should be two observations and there is only one. Most likely this is due to missing data and this is the case for this example. The value for the variable "y" is missing from row 1. In this case, we need to use the option "missover" of the infile statement to instruct SAS not to go a new input line if it does not find valid values in the current input line. Here is corrected version of the code together with the output.
data test; infile 'd:temptest.txt' missover; input a $ age y; run; proc print data = test; run;Obs a age y 1 john 11 . 2 megan 22 4
10. Not sorting data before using statements that require sort
Although steps are executed independent of each other, some steps require a previous step in order to be carried out properly. A common example is the use of a by statement in a data step. This requires that the data has either been sorted by the variable(s) in the by statement or that the data was read in already sorted. If the code below is run without a previous sort on type,
data auto2; set auto; by type; retain types 0; if first.type then types = types + 1; run;
the log indicates the omission of this step and prints the first line in the dataset that suggests non-sorted order of the variable(s).
70 data auto2; set auto;
71 by type;
72 retain types 0;
73 if first.type then types = types + 1;
74 run;
ERROR: BY variables are not properly sorted on data set WORK.AUTO.
Make=Acura Model=NSX coupe 2dr manual S Type=Sports Origin=Asia DriveTrain=Rear MSRP=$89,765
Invoice=$79,978 EngineSize=3.2 Cylinders=6 Horsepower=290 MPG_City=17 MPG_Highway=24 Weight=3153
Wheelbase=100 Length=174 FIRST.Type=0 LAST.Type=1 types=2 _ERROR_=1 _N_=7
NOTE: The SAS System stopped processing this step because of errors.
NOTE: There were 8 observations read from the data set WORK.AUTO.
WARNING: The data set WORK.AUTO2 may be incomplete. When this step was stopped there were 6
observations and 16 variables.
WARNING: Data set WORK.AUTO2 was not replaced because this step was stopped.
Adding a proc sort before this data step corrects this problem.