Why the variable being dropped still being used to calculate in the same datastep?

[ResoluteCarbon]

Hi all,

I have a code below, I am wondering why the StormLength still being calculated while the EndDate being dropped by the drop statement in advance?

data storm_complete;
	set pg2.storm_summary_small; 
	length Ocean $ 8;
	drop EndDate;
	where Name is not missing;
	Basin=upcase(Basin);
	StormLength=EndDate-StartDate;
	if substr(Basin,2,1)="I" then Ocean="Indian";
	else if substr(Basin,2,1)="A" then Ocean="Atlantic";
	else Ocean="Pacific";
run;

The answer from the instructor is not clear to me, I do not know why values have been generated for StormLength. My standpoint is: while the datastep running, it will run from the first statement to the last statement to finish one loop and continue the next loop from the data statement. So, logically speaking, while the drop statement coming before the computing equation of StormLength, there should be no result for StormLength from my opinion.

Thank you in advance.

[Kurt_Bremser]

The DROP statement only excludes the variable from being written to the output, but it stays present in the PDV and can be used in calculations.

And since the DROP statement is a declarative statement, its position in the code is irrelevant.

[Tom]

They did not provide very good explanation.

Your understanding is right, but you are missing something.  Not all statements are "executable".  That is they don't actually take any action when the data step is running. Instead they just help determine how the data step will run.  The DROP statement just means that the variable is not included in the data written to the output dataset.  The fact that variable is not written out has no impact on the values the variable can have while the data step is executing. Since the DROP statement has no executable component it does not matter where in the data step it appears.  Personally I normally put the DROP statement at the bottom of the step as it makes more sense to me there.

[Reeza · Accepted solution]

This is the mistake: it will run from the first statement to the last statement to finish one loop and continue the next loop from the data statement

This is not 100% true, it's a simplification used when you start programming.

KEEP, DROP, WHERE, BY are a few examples that can go in several places without needing to necessarily be in the correct order. Some PROCs will complain if BY isn't before some statements and others won't which can also be annoying.

FYI you can test your assumptions. A good way to do that is to use PUT statements. So if you added a PUT _all_ ; statement to your code (after SET & before RUN are good places) it would put all variables and their values, which would let you see what is happening 'behind the scenes'.

[ResoluteCarbon]

Hi @Reeza , @Tom , @Kurt_Bremser 

Thank you for your tips, 

I just found another way to see what happened behind the scene is to use the debugger button in SAS EG to see what inside the PDV after each excutable statement or each data iteration.

Thank you!

[Reeza]

Yeah, but the PUT statement is a technique that works in all languages and platforms 😄