ERROR 180-322: The story of an error message


First, if you landed on this topic because you encountered this SAS message:

ERROR 180-322: Statement is not valid or it is used out of proper order.

...then I'll tell you right now: you've probably left off a semicolon in one of your SAS statements. If you're lucky, the SAS log will show you where it happened by highlighting the offending line with the "180" error number:

proc sql
create table f as select * from sashelp.class;

Punctuation is important in any language. (Recommended reading: Eats, Shoots & Leaves: The Zero Tolerance Approach to Punctuation.) It's especially important in a programming language like SAS, where semicolons are the only way that SAS can determine where one instruction ends and the next one begins.

So why doesn't SAS just say, "Hey buddy -- you're missing a semicolon!" ? The reason is that there are other potential causes for this message. For example, if you drop in a statement that SAS just doesn't understand -- or doesn't understand in the current context -- then the error message "Statement is not valid or it is used out of proper order" pretty much says it all.

But I was curious about the error number: 180-322. Where did that come from? To find out, I had to step into the SAS Wayback Machine.

Error numbers are historical

At SAS, the "Wayback Machine" is personified in Rick Langston, a 35+ year SAS employee who is the main steward of the SAS programming language. I asked Rick about the origin of the error number 180-322, and he immediately logged in to SAS 82.4 to check the behavior.

That's right: He ran SAS 82.4 -- as in, the version of SAS that was available in 1982. He didn't even have to climb into his DeLorean and drive 88MPH. We actually have SAS 82.4 running on a mainframe at SAS. Here's the log from Rick's syntax error test:

1       S A S   L O G    OS SAS 82.4         MVS/XA JOB SAS824   STEP SAS      
NOTE: CPUID   VERSION = 00  SERIAL = 035EA6  MODEL = 2964 .                     
NOTE: SAS OPTIONS SPECIFIED ARE:                                                
1          DATA TEMP; X=1; BLAH;                                                
ERROR:                     180                                                  

While Rick couldn't tell me why the number was set to 180 originally, it's clear why it's there today: legacy. Automated processes depend on error codes, and you can't go changing those error codes after a world of SAS users begin to rely on them. Maybe the "180" is a reference to "180 degrees," as in "turn around and look behind you: you forgot a semicolon!"

The second part of the error code, "322", indicates a grouping of related syntax error messages. Here is a sample of other messages that you'll encounter with the -322 suffix:

75-322 Syntax error, expecting one of the following: <expected keywords>
76-322 Syntax error, statement will be ignored.
77-322 The statement is being ignored.
181-322 Procedure name misspelled.
216-322 No simple repair for the syntax error. The statement is being ignored.

That last one is my favorite but I've never seen it in action. I wonder what sequence of statements would coax the "No simple repair" message into your SAS log? If you can make it happen, let me know in the comments. It sounds like my approach when my family asks me to fix something around the house. "No simple repair -- so IGNORE." (Not recommended, by the way.)

Where to learn more about ERROR and WARNING messages

If you're just getting started with SAS programming, it's a good idea to learn how to interpret the SAS log messages. Here are some papers that help:


About Author

Chris Hemedinger

Senior Manager, SAS Online Communities

+Chris Hemedinger is the manager of SAS Online Communities. Since 1993, Chris has worked for SAS as an author, a software developer, an R&D manager and a consultant. Inexplicably, Chris is still coasting on the limited fame he earned as an author of SAS For Dummies.  He also hosts the SAS Tech Talk webcasts each year from SAS Global Forum, connecting viewers with smart people from SAS R&D and the impressive work that they do.


  1. I learned on 82.4 (and had a hand-me-down 79.5 manual as a reference), but it's spooky to find out there's still a copy running.

    Doesn't make me feel any younger.

    (One day I left work and walked to the parking lot to get my ride, only to discover to my dismay that somebody else's dinosaur had eaten my dinosaur while it was just sitting there in my regular parking space.)

  2. Such a great post - especially to share with the new programmers I teach. Thanks! Does that old mainframe require 1.21 gigawatts?

  3. Peter Lancashire on

    It's interesting to see that the error numbers have a structure. There is some software engineering behind them.
    Other software I have used has come as standard with a comprehensive catalogue of error numbers with explanations and suggestions for how to solve the problem. This was an enormously valuable resource for a beginner.
    Please could you ask your SAS software engineers to share this information with us users? They invented the numbers and the text, so must know what they mean. We need an official place to document (and find) the "well-known" solution to 180-322: look for a missing semi-colon. And all the myriad others.

    • Chris Hemedinger
      Chris Hemedinger on


      Of course it's most helpful when the error message itself is descriptive enough for you to determine the next action. Error messages at SAS go through some review (multiple reviews, actually, since they also need to be localized into many languages). I think that the software has grown to the point that a comprehensive directory of all error messages would be unwieldy. A casual search of Base SAS shows nearly 5000 messages! Thankfully, the most common messages have been described in communities, doc, and SAS Notes.

      • Peter Lancashire on

        The Informix 7.1 book I have from 1994 has over 500 pages with about 5 errors described per page, so roughly 2500. Each has a unique identifier. They also delivered a finderr script to search for them. I imagine software engineering has developed since 1994, so documenting and organizing 5000 explanations should be no problem. Searching for them is difficult (I have tried) because they do not have unique identifiers. Maybe all these online resources have made us lazy?

        • Chris Hemedinger
          Chris Hemedinger on

          I used to work for IBM way back, and I remember working on the tomes that documented all error messages...and wondering, "who's going to read all of these?" Now I know :)

          But all error messages are not equal. There are a handful that people see all of the time, triggered by the most common conditions. And then there are those that cover the very rare events that almost no one will see. I think the common messages are well documented, but the rare messages remain hidden until you hit just the right combination of events to uncover them.

  4. I do not know why I even know/remember this but error 180 used to be a common COBOL error code when something was out of place or when a date/datetime was incorrect... Maybe Data steps did a bit of cobol behind scenes in 70s/80s?

  5. Ods Graphics on/ Attrpriority=none;
    Proc sgplot data=growth;
    Title'Plot of Meanrcd vs family';
    Styleattrs datacontrastcolors=(red blue green orange)
    datasymbols=(Circlefilled trianglefilled squarefilled
    diamondfilled) datalinepatterns= (solid dash shortdash
    series x=repno y=meanrcd/group=family markerattrs=(size=3px)
    I am getting error message that ERROR 180-322: Statement is not valid or it is used out of proper order.for statement styleattrs

Leave A Reply

Back to Top