|
|
|
||||
|
|
|||||
When a SAS program is executed, SAS generates a log.
- Echoes program statements
- Provides information about computer resources
- 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
- 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.
However, the majority of errors are easily corrected.
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.
4. Look for common errors first.
Most errors are caused by a few very common mistakes.
3.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.
3.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;
3.3 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; var make mpg; Title "Auto File '; run;
SAS would not read the run statement. Instead it reads it as part of the title statement, because the title statement is missing the closing double quotes. When 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 for the end of the step, which it will never find because it has become part of the title statement. When executed, the program will disappear from the program editor.
Nothing appears in the output window (not shown). If we check the log, it indicates the program is running.
If we correct the program by adding the double quotes, and the program will now run.
Note that SAS includes the string 'run; in the title when it prints the output listing.
Auto File ';run; OBS MAKE MPG 1 AMC 22 2 AMC 17 3 AMC 22 4 Audi 17 5 Audi 23 6 BMW 25 7 Buick 20 8 Buick 15 9 Buick 18 10 Buick 26 11 Buick 20 12 Buick 16 13 Buick 19 14 Cad. 14 15 Cad. 14 16 Cad. 21 17 Chev. 29 18 Chev. 16 19 Chev. 22 20 Chev. 22 21 Chev. 24 22 Chev. 19 23 Datsun 23 24 Datsun 35 25 Datsun 24 26 Datsun 21
3.4 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, 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 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 statement solves the problem.
data auto2; set auto; ratio = mpg/weight; proc sort; by make; run;
3.5 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 was 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;
Variable uninitialized Variable not found
These errors mean that your program includes a reference to a variable name that SAS has never seen. The mostly likely cause is a spelling error. If all variables and programming statements are spelled correctly, check that you are in fact reading the correct data set and not one with a similar name.
- Check spelling
Has the variable name been spelled correctly?
- Consider data errors
Are you reading the correct data set?
Have the data changed?
Has the variable been dropped?
Consider logic errors
Are you using a variable before it has been built?
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.
Invalid option
This means that the option is not valid for the
procedure in which it is being used.
Check procedure/options
Is the option appropriate for the procedure?
Option or parameter not recognized
This error means that although the option may be correct
as written, it is not being used correctly in the program.
Check procedure/options
Is the
option appropriate for the procedure?
Look for missing semicolon.
Is there a missing
semicolon in a preceding statement?
Statement is not valid or is used out of proper
order
This means that the statement itself is incorrect as written.
Check your syntax
UCLA Researchers are invited to our Statistical Consulting Services
We recommend others to our list of Other Resources for Statistical Computing Help
These pages are Copyrighted (c) by UCLA Academic Technology Services