Example: confidence

Errors, Warnings, and Notes (Oh My): A Practical Guide to ...

1 Errors, Warnings, and Notes (Oh My) A Practical Guide to debugging SAS ProgramsSusan J. Slaughter, University of California Extension, Davis, CALora D. Delwiche, IT/ANSA, University of California, Davis, CAWhy a paper on debugging SASprograms?Most of the documentation about the SAS Systemdoesn t even mention bugs, as if debugging wasn tworth talking about. This paper, on the other hand,is based on the belief that debugging is a good wayto get insight into how SAS works. Once youunderstand why you got an error, you ll be betterable to avoid it in the future. In other words, peoplewho are good debuggers are good can have different origins; some areaccidentally built into the software by developers,others are introduced by programmers.

A Practical Guide to Debugging SAS Programs Susan J. Slaughter, University of California Extension, Davis, CA Lora D. Delwiche, IT/ANSA, University of California, Davis, CA Why a paper on debugging SAS programs? Most of the documentation about the SAS System doesn’t even mention bugs, as if debugging wasn’t worth talking about.

Tags:

  Guide, Practical, A practical guide, Debugging, A practical guide to debugging sas, Debugging sas

Information

Domain:

Source:

Link to this page:

Please notify us if you found a problem with this document:

Other abuse

Transcription of Errors, Warnings, and Notes (Oh My): A Practical Guide to ...

1 1 Errors, Warnings, and Notes (Oh My) A Practical Guide to debugging SAS ProgramsSusan J. Slaughter, University of California Extension, Davis, CALora D. Delwiche, IT/ANSA, University of California, Davis, CAWhy a paper on debugging SASprograms?Most of the documentation about the SAS Systemdoesn t even mention bugs, as if debugging wasn tworth talking about. This paper, on the other hand,is based on the belief that debugging is a good wayto get insight into how SAS works. Once youunderstand why you got an error, you ll be betterable to avoid it in the future. In other words, peoplewho are good debuggers are good can have different origins; some areaccidentally built into the software by developers,others are introduced by programmers.

2 Recently,one of the authors of this paper had a conversationabout this topic with her father who is an aerospaceengineer but not knowledgeable about the SASS ystem. The conversation went like this:Susan: I m writing about how to debug : I thought they would have gotten the bugsout of SAS by , SAS Institute has done a good job ofgetting the bugs out of SAS , nobody has yet figured out how toget the bugs out of SAS System even fixes some mistakes made byprogrammers. For example, SAS has gotten so smartover the years that it is now almost impossible to getan error by misspelling a keyword. If you misspell akeyword in a SAS program, SAS will almost alwaysfigure out what you meant to say and run thestatement correctly in spite of your poor typing SAS can t fix all programming errors, so thispaper discusses some of the most common bugsand how to exterminate them.

3 1 debugging Myself by Hayes (1995) contains anentertaining discussion of human is a bug?Scientists have identified approximately 1 1/4 millionspecies of animals. Of those about 3/4, or 932,000,are insects. However, only the 82,000 speciesbelonging to the order Hemiptera are considered byscientists to be true bugs (McGavin, 1993).Fortunately, a taxonomy of SAS bugs would notidentify nearly so many aside, a bug is an error in a computerprogram that causes an undesirable, usuallyunexpected, result. One way of classifyingcomputer bugs is to divide them into three types oferrors: syntax, data, and logic. Syntax errors resultfrom failing to follow SAS s rules about the waykeywords are put together to make statements.

4 Withdata errors you have a program that is syntacticallysound but fails because of data values that do not fitthe program as it was written. With logic errors youhave a program that runs, and data that fits, but theresult is wrong because the program doessomething different than you bugs discussed in this paper can be classifiedas:Syntax missing semicolon uninitialized variable and variable not foundData missing values were generated numeric to character conversion invalid data character field is truncatedLogic DATA step produces wrong results but no to the SAS LogThe first and most important rule in debugging SASprograms is to always, always check the SAS running a SAS program many people turnimmediately to the output.

5 This is understandable,2but not advisable. It is entirely possible and soonerof later it happens to all of us to get output thatlooks fine but is totally bogus. Often checking theSAS log is the only way to know whether a programhas run logs contain 3 types of messages: Errors, warnings, and you get an error message in your program, you willknow it. Error messages get your attention becauseSAS will not run a job with one of these bugs. Errormessages are not quiet, discrete, or subtle; they arethe loud, rabble-rousers of SAS messages. Thismessage, for example:ERROR: No CARDS or INFILE a program dead in its tracks. This messagetells you that SAS could not find any data to read withthe INPUT are less dire than errors.

6 SAS printswarnings in your log and then goes ahead and runsthe job anyway. Many people, including someprofessional programmers, try to ignore t you be one of them. Sometimes the situationsthat result in warnings are indeed harmless; othertimes they indicate grave problems which, ifunresolved, will render your results worthless. Youshould check all warnings to see if they are harmlessor hazardous. This message:WARNING: The data set may beincomplete. When this step was stopped therewere 0 observations and 3 you that SAS did run a DATA step, but for somereason there are zero observations. This could beOK, but generally speaking when you go to thetrouble of creating a data set, you want some data are the most innocuous messages that SASwrites in your SAS log.

7 They simply inform you of thestatus of your program. Notes contain informationsuch as the number of records input from an externalfile, or the number of observations written in a SASdata set. Don t be fooled by demure little Notes ; theyare a critically important way of catching messages:NOTE: 29 records were read from the infile' '. The minimum record length was 27. The maximum record length was : The data set has 14observations and 3 you that while 29 records where read from a rawdata file, the resulting SAS data set contains only 14observations. If you were expecting only 14observations, then this would be fine. But if youwere expecting 29 observations, one observationfor each input record, then this would tip you off thatsomething went type of note can help you write efficientprograms.

8 At the end of every step SAS prints anote similar to this:NOTE: The PROCEDURE PRINT used you are running a one-time report, you may notcare, but if you run the same program over and overthen you may want to check your Notes to see whichsteps can benefit the most from species dataThe data for the next few examples appear in Table1. Each observation contains data about one orderin the class Insecta (La Plante, 1996). The variablesare the name of the order (ORDER), the number ofspecies in that order found in North America(NASP), and the number of species found outsideNorth America (OUTSP).3 Table 1 Species data. ORDER NASP OUTSP Thysanura 20 230 Diplura 30 370 Protura 30 70 Collembola 325 1675 Ephemeroptera 550 950 Odonata 425 4575 Plecoptera 34 1266 Grylloblattodea.

9 6 Saltatoria 110 21890 Phasmida ..Dictyptera ..Isoptera 45 .Dermaptera 20 1080 Embioptera 10 140 Psocoptera 150 950 Zoraptera 2 17 Mallophaga 320 2280 Anoplura 65 285 Thysanoptera 625 2375 Hemiptera 8750 46250 Neuroptera 350 4350 Mecoptera 70 280 Trichoptera 950 3550 Lepidoptera 10500 189500 Diptera 16700 68300 Siphonaptera 250 850 Hymenoptera 14600 90400 Coleoptera

10 27000 530000 Strepsiptera 120 180 The missing semicolonEven the newest of SAS programmers knows thatevery SAS statement ends with a semicolon; so it isironic that one of the most common bugs is themissing most SAS error messages are clear and easyto understand, the hallmark of a missing semicolon isconfusion. Missing semicolons often produce a longstream of baffling messages. In the followingexample, the absence of a semicolon at the end ofthe DATA statement causes two error messages,three warnings, and a suspicious DATA species2 INFILE ' '; -------------- 2003 INPUT order $ 1-15 nasp outsp;4 RUN;ERROR 200-322: The symbol is not : No CARDS or INFILE : The SAS System stopped processing thisstep because of : The data set may beincomplete.