Picture this – a student grabs the Programming 1 textbook, scans it quickly seemingly searching for
something specific, and shakes his head indicating an unsuccessful search. He plants himself smack dab in the front row, looks me squarely in the eye, raises one eyebrow quizzically and says, “Bad words?”
I must confess I’ve encountered my fair share of unusual questions, but this one just floored me. It broke every code in the instructor rule book which says-steer clear of 3 topics in the classroom:
- anything to do with politics
- religion
- sports
Technically his question didn’t fall under the 3 forbidden categories of student-land that we seldom wander into.
Blushing, not knowing what to say, I stammered “Sorry, Wwwhat?”
Student, “Oh, come on, you’re teaching a language. Whenever I learn a new language, the first thing I do is learn the bad words, makes it easy for me to know the rules when I know what not to do”.
Me, “Never thought of SAS rude words, but I’ll give it a try”. I have to admit shamefacedly I did end up teaching the class a lot of bad words! Remember my post has a PG rating!!
Much later after class was over, when I sat back to review the student evaluations, this student’s question surfaced in my mind. In this blog post I’ll try to coherently answer the question:
What are bad words that SAS doesn’t like?
The SAS language recognizes 5 types of errors. Here are two types with examples of each:
Syntax error
- Missing semicolon—like you end a sentence in English with a period, SAS statements end with a semicolon. Missing one makes SAS complain in the log.
- Commas are another no—unlike SQL, SAS prefers spaces as the separator between words
- Mismatched quotations—these cause your data step to run indefinitely
Data Error
- Bad Data—you’re trying to read in character data in a numeric variable or you’re trying to sum a character variable – in the example below model is character and the SUM statement fails resulting in an ERROR thus SAS stops processing the step
How does SAS complain?
There is no ambiguity or beating around the bush with SAS. What you see is what you get. Likewise when you talk rudely, SAS will complain. To correct your manners just check the log.
You’ll see one of these:
- A warning-in green, indicating SAS understands, despite the poor language, and it makes an assumption on your behalf and carries on. It’s not a bad thing.
- An ERROR- You can’t miss the bad words highlighted in red which SAS doesn’t recognize at all. Despite any trash talking, SAS retains its politesse. It even goes as far as to address foul language with the gentle name of ‘ERROR’. When you trash talk, SAS shows you the hand and won’t go any further. It completely stops processing your code. This is bad news.
How can I place closer attention to these Warnings/ERRORS during Run time?
Depending on your type of error, you might try out one of these techniques:
- Always check the log first – a golden rule to follow that every Programming 1 class I teach hears about a lot
- PUTLOG statement –puts informative messages that you specify in the log.The PUTLOG statement is also helpful when you use macro-generated code because you can send output to the SAS log without affecting the current file destination.
- Data step Debugger- you go behind the scenes and check out values of variables for each observation during execution. I hope to write my next blog on the inside workings of SAS and will elaborate on execution then.
You might be interested in checking out this useful paper .
Now you know some choice curse words in SAS … which I hope you’ll refrain from using, in your best interest. I’d love to hear about other times that SAS has complained.
13 Comments
nice
Nice and good input for the learners
Pingback: This week in blogs: What if, Generation Z, and curse words - SAS Voices
how about some good words ? imaginative
will do, stay tuned for an upcoming episode of good words :) thanks for writing.
Nice post. SAS often complains about my use of the language in too many ways to articulate, but two cases which I do quite frequently are the following:
1) Ending a data/proc step with URN instead of RUN. Thankfully I usually correct this before SAS has a change to complain, but my fingers haven't quite always learned not to say it.
2) Failing to add a percent sign when doing a macro do loop as in
%do i = 1 to 10 ;
Steve
true, lucky our mouthiness gets caught by SAS in the log :) thanks for taking the time to write.
What a clever post and I learned something as well....which is quite interesting since I am no where close to being a programmer.
Glad this post helped understand SAS some more. Thanks for writing in, Star.
/BEWARE
silent failure occurs rarely, but significantly when using END= on an INFILE DATALINES statement.
Quite painful if using END= to signal end of data when you want to create macro variables (like how much has been read).
Although a Restriction is documented there is neither NOTE nor WARNING created when END= is used on INFILE DATALINES.
BEWARE/
thanks /BEWARE for this note. Appreciate your writing in.
Nice post and good resources for dealing with error logs.
When I was an instructor, I had to add 'barbeque' to my list of forbidden topics (previously just politics and religion) after two students nearly went toe-to-toe debating the merits of Eastern North Carolina and Western North Carolina styles.
Wow, that's close to another comment that an instructor faced when talking about the blue sky--someone else started talking Sports animatedly. Thanks for reading Mark