Fortunately, SAS system fixes some mistakes made by SAS programmers. For example, SAS has gotten so smart over the years that it is now almost impossible to get an error by misspellilng a keyword. If you misspelled a keyword in a SAS program, SAS will almost always figure out what you meant to say and run the statement correctly in spite of your poor spelling skills. But SAS cannot fix all programming errors for you, so here are some of the most comment errors and how to debug them.

Syntax = compilation time errors
For example: missing semicolon [proc means data=work.demog run;]

Semantic = compile time error when the language element is correct, but the element might not be valid
For example: DATA step procedures wrong results but no error message

Execution-time = when SAS attemps to execute a program and execution fails

Data = execution time error when data values are invalid
For example: missing values were generated, numeric to character conversion, invalid data or character field is truncated

Macro-related = when you use the macro facility incorrectly

The most important rule in debugging SAS programs is to always check the SAS log. It is important to review the log messages each time you submit your program. To review the log, check at the top for messages such as ERRORS, WARNING or NOTES.

WARNING: The data set WORK.DEMOG may be incomplete. When this step was stopped there were 0 observations and 5 variables.

This message tell you that SAS did run a DATA step or able to peform the action, but for some reason there are zero observations. This could be a non-issue, but generally speaking when you go to the trouble of creating a data set, you want some data in it.

NOTE: SAS went to a new line when INPUT statement reached past the end of a line.
NOTE: The data set WORK.DEMOG has 2 observations and 2 variables.

Notes are simple there to inform you of the status of your program. If you were expecting 27 observations, one for each input record, then this would tell you that something went wrong. Notes can also be useful to streamline codes but writing more efficient programs. For example, if the run-time (total process time) of a report takes too long to run then this is another way to check your code.

A missing semi-colon can be notorious for misleading error messages. The compiler depends on a sequence of key words to identify the type of statement. If you leave out a semi-colon then you hide the key word of the next satement. The compiler is likely to find something wrong, but it is usually not the real mistake – the missing semicolon. Hence the errors and warnings are just hints about what the compiler is seeing instead of the underlying problem.

One final note, you can insert a PUTLOG statements to check to idenfity error(s):

data demog;
set edc.demog_summary;
by patient_id;
if first.patient_id=1 then race=’white’;
putlog race=;
run;

proc print data=demog;
run;

The DATA step debugger offers SAS programmers a new way to investigae logic errors. Since SAS runs programs in two phases, SAS compiles it then executes the program. To invoke the debugger, add / DEBUG to the end of your DATA statement and then run your DATA step.

If we modify the previous DATA step:

data demog / DEBUG;
set edc.demog_summary;
by patient_id;
if first.patient_id=1 then race=’white’;
run;

After you submit the above code, two windows appear: the DEBUGGER LOG window and the DEBUGGER SOURCE window. As you may have imagined, the DEBUGGER LOG window contains messages from the debugger and command line. The SOURCE window contains your DATA step statements with current line highlighted. SAS executes each line of your program for the first observation, then returns to the top of the DATA step for the second observation and so on.

As you can see, there are many ways to check your SAS programs for errors, even when the ouptput looks fine. Notes are just as important as warnings and error messages. I strongly recommend that you learn how to use the debugger as it can save lots of time when debugging your program!

Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.

Advertisements