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
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:
- 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
- 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.