Using run; after multiple data steps

Viewed 23

I work on a team that runs this big data QA project. In addition to the QA I'm often tasked with trying to improve the speed/efficiency of the SAS code (the QA evolves a lot). One coworker will write multiple DATA or PROC steps and then put a RUN; at the end of them all- I never learned to code that way. All I care about is speed and memory use- does this style of coding impact that?

example"

data a;
set b;
if yadda yadda;

proc transpose data= a;
out= c;
id ;
var;

data ;
set;

data;
set;
run;
2 Answers

Any execution speed impact (plus or minus) from leaving off the explicit step ending statements will be trivial. SAS will determine the step has ended when it sees that you have started another step (PROC or DATA).

Only speed impact would be if you were running interactively, say in Display Manager, and left the last DATA step unterminated. The SAS session would just wait for you to finish defining the data step before it would start to compile and run it.

But leaving them off might have a large impact on your ability to maintain the code or debug any issues by reading the SAS logs. You also might run the risk of coding mistake impacting more than one step. If the step has been ended with a RUN statement and does not contain any coding errors it will run. But if there is a coding error in the first line of the next step then that might impact both steps ability to be understood and executed by SAS.

I would consider this poor programming style, but it doesn't affect the functioning of the program.

SAS will consider a DATA or PROC step terminated when it either encounters a step boundary, such as:

  • RUN
  • QUIT
  • DATA
  • PROC

Any of those ends the current step.

From SAS's RUN documentation:

Although the RUN statement is not required between steps in a SAS program, using it creates a step boundary and can make the SAS log easier to read.

For that reason, I consider it mandatory in my environment. But it doesn't affect the actual running time. However, to me running time is less important than programmer time.

Related