tags:

views:

244

answers:

3

In the enhanced editor, the coloring might give you a hint. However, on the mainframe I don't believe there is anything, in the editor, that will help you.

I use

OPTIONS OBS=0 noreplace;

The obs=0 option specifies that 0 observarions are read in from the input dataset and NOREPLACE tells SAS not to overwite an existing SAS dataset with one of the same name. If you are creating a new datastet, it will be created with all the attributes, but with 0 observations. (Be sure to reset the options, if needed, to Options Obs=All replace ; when no more syntax errors are found).

I'd be interested in any other techniques. Thanks

Explanation about options came from here.

+8  A: 

I use the cancel option on the run statement. It will check the syntax of the data step then terminate it without actually executing it. It's the data step analog to the noexec option in proc sql.

data something;
<stuff here>
run cancel;

Lots more details in this SUGI pdf

cmjohns
Good tip. I remember now getting a tip (from a class or a paper) to use a macro var instead of cancel. Then you can change the macro var to be blank when you really want to run the program. Thanks for the link. It's a good paper.
CarolinaJay65
Great tip! Thanks!
Martin Bøgelund
A: 

I write all of my code on my PC with SAS on my PC and the enhanced, color coded editor. I then use SAS/CONNECT to process it on the mainframe. If the datasets are on DASD, I use SAS/CONNECT and Enterprise Guide to directly run the code onthe mainframe (no JCL!) If there is a data tape involved and therefore must be a batch run, I use SAS/CONNECT and the SAS ftp engine to send the code to the mainframe batch queue. I use the SAS email engine to email me back my output and my log. I put and ODS sandwich aound my code to have the mainframe generate a WORD document for output. I use a PROC download to download the output to my server so I can open it in WORD.

A: 

This advice is language agnostic.

I would argue that a preferable technique for catching syntax (and logic) errors is to perform a close read (or inspection) of your own code (which should catch the majority of syntax errors), followed by unit tests on small datasets (which will catch any remaining syntax errors, as well as many logic errors if your tests are well-designed).

I agree there's some worth to syntax checking in isolation, but to read and understand your code thoroughly enough before the first compile so that you know it will compile is a good ideal to strive for. Steve McConnell touches on this idea in Code Complete (see page 827 of the 2nd Edition).

Matt

P.S. You mentioned syntax highlighting in your original post; there are other editors (such as VIM) that will perform syntax highlighting on SAS files.

Matt Nizol