The Little SAS Book

A Primer, Sixth Edition

Lora D. Delwiche, Susan J. Slaughter

• Éditeur: SAS Institute
• Année: 2019
• ISBN:
  9781642953435
• Édition: 6
• Sujet: Ciencia de la computación
• Sous-sujet: Ciencias computacionales general

A classic that just keeps getting better, The Little SAS Book is essential for anyone learning SAS programming. Lora Delwiche and Susan Slaughter offer a user-friendly approach so that readers can quickly and easily learn the most commonly used features of the SAS language. Each topic is presented in a self-contained, two-page layout complete with examples and graphics.Nearly every section has been revised to ensure that the sixth edition is fully up-to-date. This edition is also interface-independent, written for all SAS programmers whether they use SAS Studio, SAS Enterprise Guide, or the SAS windowing environment. New sections have been added covering PROC SQL, iterative DO loops, DO WHILE and DO UNTIL statements, %DO statements, using variable names with special characters, the ODS EXCEL destination, and the XLSX LIBNAME engine.This title belongs on every SAS programmer's bookshelf. It's a resource not just to get you started, but one you will return to as you continue to improve your programming skills.

CHAPTER 1

Getting Started Using SAS Software

1.1 The SAS Language

Many software applications are either menu driven, or command driven (enter a command—see the result). SAS is neither. With SAS, you use statements to write a series of instructions called a SAS program. The program communicates what you want to do and is written using the SAS language. There are some menu-driven front ends to SAS, for example, SAS Enterprise Guide, which make SAS appear like a point-and-click program. However, these front ends still use the SAS language to write programs for you. You will have much more flexibility using SAS if you learn to write your own programs using the SAS language. Maybe learning a new language is the last thing you want to do, but be assured that although there are parallels between SAS and languages that you know (be they English or Java), SAS is much easier to learn.

SAS programs A SAS program is a sequence of statements executed in order. A statement gives information or instructions to SAS and must be appropriately placed in the program. An analogy to a SAS program is a trip to the bank. You enter your bank, stand in line, and when you finally reach the teller’s window, you say what you want to do. The statements you give can be written down in the form of a program:

I would like to make a withdrawal.

My account number is 0937.

I would like $200.

Give me five 20s and two 50s.

Note that you first say what you want to do; then give all the information the teller needs to carry out your request. The order of the subsequent statements might not be important, but you must start with the general statement of what you want to do. You would not, for example, go up to a bank teller and say, “Give me five 20s and two 50s.” This is not only bad form, but would probably make the teller’s heart skip a beat or two. You must also make sure that all the subsequent statements belong with the first. You would not say, “I want the largest box you have” when making a withdrawal from your checking account. That statement belongs with “I would like to open a safe deposit box.” A SAS program is an ordered set of SAS statements like the ordered set of instructions you use when you go to the bank.

SAS statements As with any language, there are a few rules to follow when writing SAS programs. Fortunately for us, the rules for writing SAS programs are much fewer and simpler than those for English.

The most important rule is

Every SAS statement ends with a semicolon.

This sounds simple enough. But while children generally outgrow the habit of forgetting the period at the end of a sentence, SAS programmers never seem to outgrow forgetting the semicolon at the end of a SAS statement. Even the most experienced SAS programmer will at least occasionally forget the semicolon. You will be two steps ahead if you remember this simple rule.

Layout of SAS programs There really aren’t any rules about how to format your SAS program. While it is helpful to have a neat looking program with each statement on a line by itself and indentions to show the various parts of the program, it isn’t necessary.

♦ SAS keywords can be in upper- or lowercase. (In this book we use uppercase to set off keywords from non-keywords, but SAS doesn’t care.)

♦ Statements can continue on the next line (as long as you don’t split words in two).

♦ Statements can be on the same line as other statements.

♦ Statements can start in any column.

So you see, SAS is so flexible that it is possible to write programs so disorganized that no one can read them, not even you. (Of course, we don’t recommend this.)

Comments To make your programs more understandable, you can insert comments into your programs. It doesn’t matter what you put in your comments—SAS doesn’t look at it. You could put your favorite cookie recipe in there if you want. However, comments are generally used to annotate the program, making it easier for someone to read your program and understand what you have done and why.

There are two styles of comments that you can use. One style starts with an asterisk (*) and ends with a semicolon (;). The other style starts with a slash-asterisk (/*) and ends with an asterisk-slash (*/). The following program shows both styles of comment:

* Convert miles to kilometers;

DATA distance;

Miles = 26.22;

Kilometers = 1.61 * Miles;

RUN;

PROC PRINT DATA = distance; /* Print the results */

RUN;

Some operating environments interpret a slash-asterisk (/*) in the first column as the end of a job. For this reason, we chose the asterisk-semicolon style of comment for this book. However, comments using the slash-asterisk style do have some advantages. Because they do not use a semicolon, they can contain embedded semicolons, and can be placed inside SAS statements.

Programming tips People who are just starting to learn a programming language often get frustrated because their programs do not work correctly the first time they write them. Writing programs should be done in small steps. Don’t try to tackle a long complicated program all at once. If you start small, build on what works, and always check your results along the way, you will increase your programming efficiency. Sometimes programs that do not produce errors are still incorrect. This is why it is vital to check your results as you go even when there are no errors. If you do get errors, don’t worry. Most programs simply don’t work the first time, if for no other reason than that you are human. You forget a semicolon, misspell a word, have your fingers in the wrong place on the keyboard. It happens. Often one small mistake can generate a whole list of errors. If you build your programs piece by piece, programs are much easier to correct when something goes wrong. Also, as you write programs, it is a good habit to save them frequently. That way, you won’t lose your work if unexpected problems occur.

1.2 SAS Data Sets

Before you run an analysis, before you write a report, before you do anything with your data, SAS must be able to read your data. Generally speaking, SAS wants your data to be in a special form called a SAS data set. (See Section 2.1 for exceptions.) Getting your data into a SAS data set is usually quite simple as SAS is very flexible and can read almost any data. Once your data have been read into a SAS data set, SAS keeps track of what is where and in what form. All you have to do is specify the name and location of the data set you want, and SAS figures out what is in it.

Variables and observations Data, of course, are the primary constituent of any data set. In traditional SAS terminology the data consist of variables and observations. Adopting the terminology of relational databases, SAS data sets are also called tables, observations are also called rows, and variables are also called columns. Below you see a rectangular table containing a small data set. Each line represents one observation, while ID, Name, Height, and Weight are variables. The data point Charlie is one of the values of the variable Name and is also part of the second observation.

Data types Raw data come in many different forms, but SAS simplifies this. In Base SAS there are just two data types: numeric and character. Numeric fields are, well, numbers. They can be added and subtracted, can have any number of decimal places, and can be positive or negative. In addition to numerals, numeric fields can contain plus signs (+), minus signs (-), decimal points (.), or E for scientific notation. Character data are everything else. They may contain numerals, letters, or special characters (such as $ or !) and can be up to 32,767 characters long.

If a variable contains letters or special characters, it must be a character variable. However, if it contains only numerals, then it may be numeric or character. You should base your decision on how you will use the variable. Sometimes data that consist solely of numerals make more sense as character data than as numeric. US five-digit postal codes, for example, are made up of numerals, but it just doesn’t make sense to add or subtract postal codes. Such values make more sense as character data. In the preceding data set, Name is obviously a character variable, and Height and Weight are numeric. ID, however, could be either numeric or character. It’s your choice.

Missing data Sometimes despite your best efforts, your data may be incomplete. The value of a particular variable may be missing for some observations. In those cases, missing character data are represented by blanks, and missing numeric data are represented by a single period (.). In the preceding data set, the value of Weight for observation 5 is missing, and its place is marked by a period. The value of Name for observation 6 is missing and is just left blank.

Size of SAS data sets Prior to SAS 9.1, SAS data sets could contain up to 32,767 variables. Beginning with SAS 9.1, the maximum number of variables in a SAS data set is limited by the resources available on your computer. The number of observations, no matter which version of SAS you are using, is limited only by your computer’s capacity to handle and store them.

SAS data libraries and data set members SAS data sets are stored and accessed via SAS data libraries. A SAS data library is a collection of one or more SAS data sets that are stored in the same location. Some SAS data libraries are defined by default, but you can also define your own. The individual data sets within a SAS data library are called its members. (See Section 2.2 for further discussion of SAS data libraries and data set members.)

Rules for names of variables You make up names for the variables in your data. It is helpful to make up names that identify what the data represent. While the variable names A, B, and C might seem like perfectly fine, easy-to-type names when you write your program, the names Sex, Height, and Weight will probably be more helpful when you go back to look at the program six months later.

The specific rules for variable names depend on the value of the SAS system option VALIDVARNAME= on your system. (See Section 1.7 for more information about system options.) However, if you stick with the following rules, then your variable names will always be valid:

♦ Mak...