Common Errors

SAS is creating too many levels of a variable when running PROC GLM or PROC FREQ. Go back and check the data very carefully. Alphabetic variables are case sensitive so the value "Trt1" is different from "TRT1." This problem often creeps into programs when data has been combined over several years or locations. If you have this type of data, try to formulate a consistent template for yourself and others to use for entering data. Define what the treatment codes and variable names will be ahead of time. The only way to handle this problem is to change the data or use the IF statement.

Debugging SAS can be a trying experience. Here are some techniques I use to help the process.

Build long complex programs a step at a time. Start by reading in the data. Print it. Check it. Then do any calculations, and then add PROCs and other DATA steps. Don't try to write the whole thing at once. Verify that a piece of code works and then move on.

Use Comments. Try to isolate problem code by commenting out sections of the program. This is a very useful technique. See comments.

Try writing programs with consistent and readable structure. Use line breaks and indentation where needed and throw in comments to explain what is happening in the program. This will help organize the program flow in your mind and point out where things are going wrong. See Programming Habits.

You have entered data with a spreadsheet and saved it as an ASCII text file, but SAS has trouble reading it. Examination of the file reveals no obvious problems. Most likely there are TABs (invisible on screen) in the data file. SAS has trouble reading TABs directly and spits out all kinds of weird messages when it encounters them via INFILE. There are two possible ways of dealing with the problem. One is to start with the spreadsheet (or word processor) and make sure it uses SPACE DELIMITED text when writing ASCII files. This cures the problem before it happens. If, however, you have the file already and don't want to output it again from your spreadsheet, try this trick. In your INFILE statement add a delimiter clause like:

infile 'g:\smpldata' delimiter='09'x            ;

While we can't tell SAS to directly "use TABS," we can tell it the computer code for a TAB. That's what the '09'x is. It is also possible to tell SAS to use other delimiters this way. The code for other characters are:

"," - '2C'x

";" - '3B'x

":" - '3A'x

Like other portions of SAS, the Listing and Log windows or files may be cumulative. If you know you have changed your calculations for yield from lbs to kilograms, but SAS seems to keep printing lbs in the output, make sure you have cleared out the Listing window. You are probably looking at an "old" output created before you changed things. This also applies to the Log window.

Leaving out a semicolon is probably the easiest mistake to make. The error message you get may vary here depending on where the mistake was made. Usually you get a message like "variable XXX not found" or "invalid option." SAS is trying to interpret the errant statement as part of the preceding statement and, therefore, gets its cyberfeet tangled. The solution is obvious: put in the missing ; and resubmit the program. 

Sometimes while running a program several times you'll notice that the PROC LOTTERY you had at the end of your program is missing from the output listing. So, thinking that SAS maybe just "forgot" to run it the first time, you run the program again. Now you find it at the top of the output listing instead of the bottom. What the heck is going on!? Remember that SAS runs both sequentially and cumulatively. The first time you ran the program, SAS saw the PROC LOTTERY at the end, but didn't find a RUN; statement. Without that it will hold on to the PROC and wait to execute it when it sees the next DATA or PROC step. When you run the program for the second time SAS first executes the PROC it is holding on to and then runs the submitted program (again leaving off the last PROC). This can cause confusion to no end (no pun intended). The solution, of course, is to put in the missing RUN;. By the way, before you go running to your SAS manuals looking for PROC LOTTERY, remember this is only an example.

SAS keeps insisting that it can't find your variable TRT0, but you know it's there in the INPUT statement. Check things carefully. You may have used O (capital oh) instead of a zero. This is very easy to do and is made worse by the fact that the two are physically close together on keyboards. Similar to problems with Case above, this mix up may also show up as a problem reading in data. The only solution is to change the problem characters to the appropriate values and try again. If this problem occurs a lot, you might consider trying a different font which uses a dot or slash when writing a zero.