CHAPTER 1
Getting Started Using SAS Software
1.4 The DATA Step’s Built-in Loop
1.5 Choosing a Method for Running SAS
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 statements can be in upper- or lowercase.
♦ 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—but SAS data sets with more than 32,767 variables cannot be used with earlier versions of SAS. 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. (See Section 2.2.) The individual data sets within a SAS data library are called its members.
Rules for names of variables, SAS data libraries, and data set members You make up names for the variables in your data, for SAS data libraries, and for the data set members themselves. It is helpful to make up names that identify what the data represent, especially for variables. 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:
♦ Make variable names 32 characters or fewer in length.
♦ Start names with a letter or an underscore ( _ ).
♦ Include only letters, numerals, or underscores ( _ ). No %$!*&#@, please.
These rules apply when VALIDVARNAME=V7. If you have VALIDVARNAME=ANY, then the rules are the same except that variable names can begin with and contain any character including blanks. (See Section 3.18 for how to use variable names containing special characters.) Names for SAS data libraries and data set members follow the rules listed above except that libraries are limited to 8 characters in length. The VALIDVARNAME= system option has no effect on names of data libraries and members. It is possible that in the future some of these rules could change.
Capitalization of SAS names Another important point is that SAS is insensitive to case so you can use uppercase, lowercase, or mixed case—whichever looks best to you. SAS doesn’t care. The data set name heightweight is the same as HEIGHTWEIGHT or HeightWeight. Likewise, the variable name BirthDate is the same as BIRTHDATE and birThDaTe. However, there is one difference for variable names. SAS remembers the case of the first occurrence of each variable name and uses that case when printing results. That is why, in this book, we use mixed case for variable names but lowercase for other SAS names.
Documentation stored in SAS data sets In addition to your actual data, SAS data sets contain information about the data set such as its name, the date that you created it, and the version of SAS that you used to create it. SAS also stores information about each variable, including its name, label (if any), type (numeric or character), length (or storage size), and position within the data set. This information is called the descriptor portion of the data set, and it makes SAS data sets self-documenting. You can use PROC CONTENTS to produce a report about the descriptor portion of a SAS data set. (See Section 2.3.)
1.3 DATA and PROC Steps
SAS programs are constructed from two basic building blocks: DATA steps and PROC steps. A typical program starts with a DATA step to create or modify a SAS data set and then passes the data to a PROC step for processing. Here is a simple program that converts miles to kilometers in a DATA step and prints the results with a PROC step:
DATA and PROC steps are made up of statements. A step may have as few as one or as many as hundreds of statements. Most statements work in only one type of step—in DATA steps but not PROC steps, or vice versa. A common mistake made by beginners is to try to use a statement in the wrong kind of step. You’re less likely to make this mistake if you remember that, generally speaking, DATA steps read and modify data while PROC steps analyze data, perform utility functions, or print reports.
DATA steps start with the DATA statement, which starts, not surprisingly, with the keyword DATA. This keyword is followed by a name that you make up for a SAS data set. The DATA step above produces a SAS data set named DISTANCE. In addition to reading data from external, raw data files, DATA steps can modify existing SAS data sets and include DO loops, IF-THEN/ELSE logic, and a large assortment of numeric and character functions. DATA steps can also combine data sets in just about any way you want, including concatenation and match-merge.
Procedures, on the other hand, start with a PROC statement in which the keyword PROC is followed by the name of the procedure (PRINT, SORT, or MEANS, for example). Most SAS procedures have only a handful of possible statements. Like following a recipe, you use basically the same statements or ingredients each time. SAS procedures do everything from simple sorting and printing to analysis of variance and 3-D graphics.
A step ends when SAS encounters a new step (marked by a DATA or PROC statement); a RUN, QUIT, STOP, or ABORT statement; or, if you are running in batch mode, the end of the program. RUN statements tell SAS to run all the preceding lines of the step and are among those rare, global statements that are not part of a DATA or PROC step. It is not necessary to insert a RUN statement between steps, but including them is a good habit. Having RUN statements between steps make your programs easier to read and debug. In the program above, SAS knows that the DATA step has ended when it reaches the PROC statement. The PROC step ends with a RUN statement, which coincides with the end of the program.
While a typical program starts with a DATA step to input or modify data and then passes the data to a PROC step, that is certainly not the only pattern for mixing DATA and PROC steps. Just as you can stack building blocks in any order, you can arrange DATA and PROC steps in any order. A program could even contain only DATA steps or only PROC steps.
To review, the table below outlines the basic differences between DATA and PROC steps:
As you read this table, keep in mind that it is a simplification. Because SAS is so flexible, the differences between DATA and PROC steps are, in reality, more blurry. The table above is not meant to imply that PROC steps never create SAS data sets (most do), or that DATA steps never produce reports (they can). Nonetheless, you will find it much easier to write SAS programs if you understand the basic functions of DATA and PROC steps.
1.4 The DATA Step’s Built-in Loop
DATA steps read and modify data, and they do it in a way that is flexible, giving you lots of control over what happens to your data. However, DATA steps also have an underlying structure, an implicit, built-in loop. You don’t tell SAS to execute this loop: SAS does it automatically. Memorize this:
DATA steps execute line by line and observation by observation.
This basic concept is rarely stated explicitly. Consequently, new users often grow into old users before they figure this out on their own.
The idea that DATA steps execute line by line is fairly straightforward and easy to understand. It means that, by default, SAS executes line one of your DATA step before it executes line two, and line two before line three, and so on. That seems common sense, and yet new users frequently run into problems because they try to use a variable before they create it. If a variable named Z is the product of X and Y, then you better make sure that the statements creating X and Y come before the statement creating Z.
What is not so obvious is that while DATA steps execute line by line, they also execute observation by observation. That means SAS takes the first observation and runs it all the way through the DATA step (line by line, of course) before looping back to pick up the second observation. In this way, SAS sees only one observation at a time.
Imagine a SAS program running in slow motion: SAS reads observation number one from your input data set. Then SAS executes your DATA step using that observation. If SAS reaches the end of the DATA step without encountering any serious errors, then SAS writes the current observation to a new, output data set and returns to the beginning of the DATA step to process the next observation. After the last observation has been written to the output data set, SAS terminates the DATA step and moves on to the next step, if there is one. End of slow motion; please return to normal gigahertz.
This diagram illustrates how an observation flows through a DATA step:
SAS reads observation number one and processes it using line one of the DATA step, then line two, and so on, until SAS reaches the end of the DATA step. Then SAS writes the observation in the output data set. This diagram shows the first execution of the line-by-line loop. Once SAS finishes with the first observation, it loops back to the top of the DATA step and picks up observation two. After SAS outputs the last observation, it automatically stops.
Here is an analogy. DATA step processing is a bit like voting. When you arrive at your polling place, you stand in line behind other people who have come to vote. When you reach the front of the line you are asked standard questions: “What is your name? Where do you live?” Then you sign your name, and you cast your vote. In this analogy, the people are observations, and the voting process is the DATA step. People vote one at a time (or observation by observation). Each voter’s choices are secret, and peeking at your neighbor’s ballot is definitely frowned upon. In addition, each person completes each step of the process in the same order (line by line). You cannot cast your vote before you give your name and address. Everything must be done in the proper order.
If this seems a bit too structured, don’t worry. DATA steps are very flexible. SAS offers a number of ways to override the line-by-line and observation-by-observation structure. These include the RETAIN statement (see Section 3.15) and the OUTPUT statement (see Sections 3.10 and 3.11). It is even possible to have a DATA step that does not read or modify existing data. Here is the DATA step from the previous section. If you look at it, you may notice something interesting.
DATA distance;
Miles = 26.22;
Kilometers = 1.61 * Miles;
RUN;
This simple DATA step has no input data set. Consequently, SAS will execute the DATA step once, output a single observation, and then terminate the DATA step because there are no more observations to process. The DATA step is covered in more detail in Chapters 2, 3, and 6.
1.5 Choosing a Method for Running SAS
So far we have talked about writing SAS programs, but simply writing a program does not give you any results. Just like writing a letter to your representative in Congress does no good unless you mail it, a SAS program does nothing until you run it.
In recent years, there has been a proliferation of ways to run SAS programs. The following methods are included with Base SAS: SAS Enterprise Guide, SAS Studio, the SAS windowing environment, and batch or background mode. The best method for you will depend on your preferences and your operating environment. If you are using SAS at a large site with many users, then ask around and find out which method is the most accepted. If you are using SAS on your own personal computer, then choose the method that suits you.
SAS Enterprise Guide Using tasks and queries in SAS Enterprise Guide, you can write and run SAS programs without ever writing a single line of code. Tasks and queries are point-and-click windows for generating SAS code. However, you can also open a Program window and write your own programs. The program editor in SAS Enterprise Guide color codes your program and displays automatic syntax help as you type. There is a program analyzer that will generate a diagram of your program to help you visualize the various steps and how they fit together. If you have SAS installed on more than one computer (maybe on your local machine and on a server), then you can choose where SAS runs your code. In SAS Enterprise Guide, you can store related programs, SAS logs, results, and references to data in a single file called a project. SAS Enterprise Guide displays projects in elegant process flow diagrams, so it is easy to see how the various data sets, programs, and tasks work together. You can view and edit SAS data sets in a Data Grid. If your program creates a new SAS data set, then by default SAS Enterprise Guide will automatically display it. SAS Enterprise Guide runs only under Windows.
For a good introduction to SAS Enterprise Guide, search the internet for the video “Getting Started with SAS Enterprise Guide.”
SAS Studio SAS Studio runs in web browsers. With SAS Studio, you can access SAS on your local machine or on a server. Like SAS Enterprise Guide, SAS Studio has tasks and queries that can generate code for you, or you can open a Program window and type your own program. When you write programs, SAS Studio color codes your program and displays automatic syntax help. You can view SAS data sets, and if your program creates a new SAS data set, then by default SAS Studio will automatically display it.
SAS Studio is the interface for SAS University Edition and SAS OnDemand for Academics which are available free for academic, noncommercial use. When you download SAS University Edition, it installs a virtual Linux server on your local computer along with SAS software. SAS OnDemand for Academics runs on Linux servers hosted by SAS Institute. Regardless of which operating environment your local computer runs (Windows, Linux, or OS X for Macs), SAS University Edition and SAS OnDemand for Academics still run on Linux servers. You access those Linux servers via SAS Studio from your local computer.
For a good introduction to SAS Studio, search the internet for the video “Getting Started with SAS Studio.”
SAS windowing environment Also known as Display Manager, the SAS windowing environment is the oldest interactive interface for running SAS. The SAS windowing environment has fewer features than SAS Enterprise Guide or SAS Studio, but you can still write and edit SAS programs, run programs, and view and print your results. The SAS windowing environment has a syntax-sensitive editor that color codes your programs. There are windows for performing tasks such as managing SAS files, accessing SAS Help and Documentation, and importing or exporting data. In addition, you can view and edit SAS data sets using the Viewtable window. The SAS windowing environment does not automatically display new SAS data sets that your programs create. However, you can open data sets yourself by navigating to them in the SAS Explorer window (located on the left) and double-clicking their icons.
For a good introduction to the SAS windowing environment, search the internet for the video “Getting Started with the SAS Windowing Environment.”
Batch or background mode With batch or background mode, you save your SAS program in a file. You can create that file using one of the preceding SAS interfaces, or a text editor such as Microsoft Notepad. Then you submit the file for processing by SAS. Your SAS program may start executing immediately, or it may start at a time you specify (midnight, for example), or it could be put in a queue behind other jobs. After you submit your job, you can work on other things, or better yet, go to a baseball game and let SAS work while you play. Batch processing is a convenient way to set up production jobs to run automatically on a schedule, maybe once a week or once a month. When your job is complete, the results will be placed in a file or files, which you can display or print at any time.
To find out how to submit SAS programs for batch processing, check the SAS Documentation for your operating environment, or check with other SAS users at your site. Even sites with the same operating environment may have different ways of submitting jobs in batch mode.
1.6 Reading the SAS Log
Every time you submit a SAS program, SAS writes messages in your log. Many SAS programmers ignore the SAS log and go straight to the output. That’s understandable, but dangerous. It is possible—and sooner or later it happens to all of us—to get bogus results that look just fine. The only way to know they are bad is to check the SAS log. Just because it runs doesn’t mean it’s right.
Where to find the SAS log The location of the SAS log varies depending on the operating environment you use, the method you use to submit your program (SAS windowing environment, SAS Enterprise Guide, SAS Studio, or batch), and local settings. If you submit a program in the SAS windowing environment, you will, by default, see the SAS log in your Log window. In SAS Enterprise Guide and SAS Studio, by default, you will see a Log tab.
If you submit your program in batch mode, the log will be written to a file that you can view or print using your operating environment’s commands for viewing and printing. The name given to the log file is generally some permutation of the name you gave to the original program. For example, if you named your SAS program Marathon.sas, then it is a good bet that your log file will be Marathon.log.
What the log contains People tend to think of the SAS log as either a rehash of their program or as just a lot of gibberish. OK, we admit, there is some technical trivia in the SAS log, but there is also plenty of important information. Here is a simple program that converts miles to kilometers and prints the result:
* Create a SAS data set named distance;
* Convert miles to kilometers;
DATA distance;
Miles = 26.22;
Kilometers = 1.61 * Miles;
RUN;
* Print the results;
PROC PRINT DATA = distance;
RUN;
If you run this program, SAS will produce a log similar to this:
❶ NOTE: Copyright (c) 2016 by SAS Institute Inc., Cary, NC, USA.
NOTE: SAS (r) Proprietary Software Version 9.4 (TS1M6 MBCS3170)
Licensed to XYZ Inc., Site 0099999001.
NOTE: This session is executing on the W64_8HOME platform.
NOTE: SAS initialization used:
real time 1.40 seconds
cpu time 0.96 seconds
❶ 1 * Create a SAS data set named distance;
2 * Convert miles to kilometers;
3 DATA distance;
4 Miles = 26.22;
5 Kilometers = 1.61 * Miles;
6 RUN;
❸ NOTE: The data set WORK.DISTANCE has 1 observations and 2 variables.
❹ NOTE: DATA statement used (Total process time):
real time 0.03 seconds
cpu time 0.03 seconds
❷ 7 * Print the results;
8 PROC PRINT DATA = distance;
9 RUN;
NOTE: There were 1 observations read from the data set WORK.DISTANCE
❹ NOTE: PROCEDURE PRINT used (Total process time):
real time 0.01 seconds
cpu time 0.00 seconds
The SAS log above is a blow-by-blow account of how SAS executes the program.
❶ It starts with notes about the version of SAS and your SAS site number.
❷ It contains the original program statements with line numbers added on the left.
❸ The DATA step is followed by a note containing the name of the SAS data set created (WORK.DISTANCE), and the number of observations (1) and variables (2). A quick glance is enough to assure you that you did not lose any observations or accidentally create a lot of unwanted variables.
❹ Both DATA and PROC steps produce a note about the computer resources used. At first you probably won’t care in the least. But if you run on a multiuser system or have long jobs with large data sets, these statistics may start to pique your interest. If you ever find yourself wondering why your job takes so long to run, a glance at the SAS log will tell you which steps are the culprits.
If there were error messages, they would appear in the log, indicating where SAS got confused and what action it took. You may also find warnings and other types of notes which sometimes indicate errors and other times just provide useful information. Chapter 11 discusses several of the more common errors that SAS users encounter.
1.7 Using SAS System Options
System options are parameters you can change that affect SAS—how it works, what the output looks like, how much memory is used, error handling, and a host of other things. SAS makes many assumptions about how you want it to work. This is good. You do not want to specify every little detail each time you use SAS. However, you may not always like the assumptions SAS makes. System options give you a way to change some of these assumptions.
OPTIONS procedure Not all options are available for all operating environments. You can see a list of system options and their current values by using the OPTIONS procedure. To use the OPTIONS procedure, submit the following SAS program and view the results in the SAS log:
PROC OPTIONS;
RUN;
The list of options produced by PROC OPTIONS is long and can be overwhelming. If you know the specific options you are interested in, then you can request just those values. This statement will display just the MISSING, VALIDVARNAME, and YEARCUTOFF system options:
PROC OPTIONS OPTION = (MISSING VALIDVARNAME YEARCUTOFF);
RUN;
Changing option settings There are several possible ways to specify system options:
1. Create a SAS configuration file that contains settings for the system options. This file is accessed by SAS every time SAS is started. Configuration files are created by systems administrators. (This could be you if you are using a personal computer.)
2. Specify system options at the time you start up SAS from your system’s prompt (called the invocation).
3. Specify system options in an autoexec file, or in the Edit Autoexec File window in SAS Studio, or in an autoexec process flow in SAS Enterprise Guide.
4. Use the OPTIONS statement as a part of your SAS program. If you are using the SAS windowing environment, you can specify options in the SAS System Options window.
The methods are listed here in order of increasing precedence; method 2 will override method 1, method 3 will override method 2, and so on. In the SAS windowing environment, the SAS System Options window and the OPTIONS statement will override each other—so whichever was used last will be in effect. The OPTIONS statement is covered in this section. To find out more about other methods check the SAS Documentation for your operating environment.
OPTIONS statement The OPTIONS statement starts with the keyword OPTIONS and follows with a list of options and their values. For example:
OPTIONS LEFTMARGIN = 1IN NODATE;
The OPTIONS statement is one of the special SAS statements that do not belong to either a PROC or a DATA step. This global statement can appear anywhere in your SAS program, but it usually makes the most sense to let it be the first line in your program. This way you can easily see which options are in effect. If the OPTIONS statement is in a DATA or PROC step, then it affects that step and any following steps. Subsequent OPTIONS statements in a program override any previous ones. System options that are set in this way apply only to your current program or session. Once you exit SAS, the system options will be set back to their default values.
Selected general options Here are some system options you might want to use:
|
CENTER | NOCENTER |
controls whether output is centered or left-justified. |
|
DATASTMTCHK = value |
Specifies which SAS statement keywords are prohibited from being specified as a data set member name to protect against overwriting an input data set. See Section 11.3 for an example. Possible values are COREKEYWORDS (the default), ALLKEYWORDS, or NONE. |
|
DATESTYLE = value |
Determines order of month, day, and year when the ANYDTDTE. informat is ambiguous. Possible values include MDY (the default), DMY, and YMD. See Section 3.13. |
|
MISSING = 'character' |
Specifies the character (which could be a blank) to print for missing numeric values. Default is a period (.). |
|
YEARCUTOFF = n |
Specifies the first year of a 100-year span that is used by date informats and functions to read a two-digit year. See Section 3.13 for details. Default varies. |
|
VALIDVARNAME= value |
Specifies the rules for valid SAS variable names. Possible values include V7 and ANY. See Section 1.2 for rules for V7. With ANY, variable names can use special characters including spaces, but names containing special characters must use a name literal of the form 'variable-name'N. See Section 3.18 for examples. Default varies. |
Selected options for printing The following options affect the appearance of results in formats meant for printing, such as PDF and RTF (in other words not HTML):
|
DATE | NODATE |
controls whether or not today’s date will appear at the top of each page of output. Default is DATE. |
|
NUMBER | NONUMBER |
controls whether or not page numbers appear on each page of SAS output. Default is NUMBER. |
|
ORIENTATION = orientation |
specifies the orientation for printing output, either LANDSCAPE or PORTRAIT. Default is PORTRAIT. |
|
PAGENO = n |
starts numbering output pages with n. Default is 1. |
|
RIGHTMARGIN = n |
specifies the size of the margin (such as 0.75in or 2cm) to be used for output designed for printing. Default is 0.00in. |