SAS® Programming 1: Essentials Activity p103a02.sas Not understanding Table results

[ivarenho]

Hello,

I'm taking the Programming 1 course and I believe there's a syntax issue with my code because I believe I'm only supposed to be getting results in the table that are missing the min pressure value. I've included images but I'm not sure what the syntax issue is.  

[Kathryn_SAS]

The WHERE clause is still commented out. Try the following:

proc print data=pg1.storm_summary;
where minpressure is missing;
run;

[Cynthia_sas]

Hi:

  My suggestion is that you go back and review the section on comments in the lectures. In your screen shot, note how the WHERE statement is green and the RUN statement is also green. That means that BOTH of those statements are essentially comments. So that means your WHERE is not working because it is being treated as a comment. The code for that activity originally looks like THIS: 

***********************************************************;
*  Activity 3.02                                          *;
*    1) Uncomment each WHERE statement one at a time and  *;
*       run the step to observe the rows that are         *;
*       included in the results.                          *;
*    2) Comment all previous WHERE statements. Add a new  *;
*       WHERE statement to print storms that begin with   *;
*       Z. How many storms are included in the results?   *;
***********************************************************;

proc print data=pg1.storm_summary(obs=50);
	*where MinPressure is missing; /*same as MinPressure = .*/
	*where Type is not missing; /*same as Type ne " "*/
	*where MaxWindMPH between 150 and 155;
	*where Basin like "_I";
run;

Note that in a regular SAS Editor, like SAS Studio, the 4 WHERE statements should be showing as green, which indicates that each WHERE statement is a comment. So, when you "uncomment" and the code as instructed, you should be running code 4 different times showing only one active (not green) WHERE statement each time. So, this is how your code would look each time -- basically, for each run, you would delete just 1 asterisk at the beginning of the WHERE and that should turn the comment into a regular code color (as opposed to a comment color) -- then you submit the code with only 1 WHERE statement active, review the results. Then go back to the code and re-comment the WHERE you just ran and then uncomment the next WHERE and run the code again. You do this 4 times, with a review of the output each time.

Then at the very end of submitting each WHERE statement and reviewing the output, you have to do one final WHERE. You can either delete the 4 original WHERE statements or leave them as comments in the code when you run your final activity code. The solution to the activity shows only the final WHERE that you need to write:

Hope this clarifies the activity.

Cynthia

[ivarenho]

For some reason when I did uncomment by doing Ctrl, Shift, and /, the * was still left in front of the where statement. I did go back and rewatch the video regarding special where statements multiple times. Thank you for the step by step explanation.

[Tom]

---

@ivarenho wrote:
For some reason when I did uncomment by doing Ctrl, Shift, and /, the * was still left in front of the where statement. I did go back and rewatch the video regarding special where statements multiple times. Thank you for the step by step explanation.

---

So you tried to use the tool built into the editor to modify the code for you.

In that case you really need to LOOK at the results and make sure the editor did not do something stupid.

Remember that SAS/Studio is NOT really part the actual SAS (or VIYA) langauge.  It is an additional product that SAS produced to help you edit and submit code.  So they TRY to make it do the right thing, but in the end SAS itself will decide what the code you submitted will do.  Not SAS/Studio or the color coding logic that they build into it.

[Cynthia_sas]

Hi: I have worked in enough different editors, that I don't ever use the keyboard shortcuts. I have learned over time to manually edit the code and if the editor does have color coding, then I pay attention to the colors changing as I edit. It is always a good idea to make sure that the statements that are going to run are not accidentally being turned into comments -- one of the things that is revealed by using a SAS editor ; or that you don't have too many or too few quotes -- which is another thing that can cause you issues when you run your code.
Cynthia

[Tom]

You can modify the code to just use statement comments and avoid having issues with the comment/uncomment feature of the editor.

proc print data=pg1.storm_summary(obs=50);
	*where MinPressure is missing; *same as MinPressure = .;
	*where Type is not missing; *same as Type ne " ";
	*where MaxWindMPH between 150 and 155;
	*where Basin like "_I";
run;

Note that that first comment is a little off.

*where MinPressure is missing; 
*same as missing(MinPressure);
*same as MinPressure <= .Z;
*And when no special missing values are present then same as MinPressure=.;

[Tom · Accepted solution]

---

@ivarenho wrote:
For some reason when I did uncomment by doing Ctrl, Shift, and /, the * was still left in front of the where statement. I did go back and rewatch the video regarding special where statements multiple times. Thank you for the step by step explanation.

---

Also note that SAS has THREE different types of comments.  And it looks like that keyboard shortcut in SAS/Studio (it is command-/ on my Mac when using the SAS On Demand for Academics version of SAS/studio) only knows about ONE of them.

There are the normal SAS statement comments that the example code is using to comment out the WHERE statements.  Those start with an * and end with a semicolon (just like other SAS statements end).

Then there are the macro language statement comments.  Those start with %* and end with a semicolon (just like other macro language statements).

And finally there are block comments. Those start with /* and end with */.  Those are the type of comments that the SAS/Studio keyboard short cut knows how to add or remove.  But all it really tries to do is either add or remove block command around each line individually.

But this can cause trouble for lines that already had blocks on them that did not take up the whole line. 

Like the example lines in that program.

proc print data=pg1.storm_summary(obs=50);
  *where MinPressure is missing; /*same as MinPressure = .*/
  *where Type is not missing; /*same as Type ne " "*/
  *where MaxWindMPH between 150 and 155;
  *where Basin like "_I";
run;

When I using command-/ on that program it becomes:

/* proc print data=pg1.storm_summary(obs=50); */
/*   *where MinPressure is missing; /*same as MinPressure = . */
/*   *where Type is not missing; /*same as Type ne " " */
/*   *where MaxWindMPH between 150 and 155; */
/*   *where Basin like "_I"; */
/* run; */

Which is kind of good.  At least it did not try to NEST the new block comment around the existing block comment. SAS does NOT support nesting block comments.  So a line like this:

/*   *where MinPressure is missing; /*same as MinPressure = . */ */

Would have a block comment for most of the line and then the start of a statement comment that starts with / and continues until the next semicolon.

But the trouble comes when I try to use command-/ a second time to remove the comments from the lines.  This is the result.

proc print data=pg1.storm_summary(obs=50);
  *where MinPressure is missing; /*same as MinPressure = .
  *where Type is not missing; /*same as Type ne " "
  *where MaxWindMPH between 150 and 155;
  *where Basin like "_I";
run;

So now the second line has the original statement comment with the text of the WHERE statement in it.  But then the block comment at the end of the line is no longer closed. And in fact the one on the third line is also no longer closed.  So everything from /*same onwards is part of the comment.  Including the RUN: statement.

The only reason that the PROC PRINT actually ran is that SAS/Studio submits a special string after the code you asked it to run to try and match any unbalanced things like quotes or comments that might be in the code you submitted.  If you turn on the option in the preferences to have it show the code it inserts you can see what happened. (Here I substituted SASHELP.CLASS since I don't have your class dataset.)

 73         proc print data=sashelp.class(obs=50);
 74           *where MinPressure is missing; /*same as MinPressure = .
 75           *where Type is not missing; /*same as Type ne " "
 76           *where MaxWindMPH between 150 and 155;
 77           *where Basin like "_I";
 78         run;
 79         
 80         OPTIONS NOSYNTAXCHECK;
 81         ODS HTML CLOSE;
 82         &GRAPHTERM; ;*';*";*/;RUN;
 
 NOTE: There were 19 observations read from the data set SASHELP.CLASS.
 NOTE: PROCEDURE PRINT used (Total process time):
       real time           0.03 seconds
       cpu time            0.04 seconds

So you can see that the */ at the end of the extra code that SAS/Studio added signals the end of the block comment and the ;RUN; causes SAS to add an empty statement and a RUN statement so that the PROC PRINT executes.