No, it's not magic: De-mystifying the SAS Macro Facility Jay A. Jaffe, PhD

Transcription

1 No, it's not magic: De-mystifying the SAS Macro Facility Jay A. Jaffe, PhD ABSTRACT To get the most out of SAS macros and macro variables, you must know how the Macro environment interacts with the SAS program as it works on your program. Stop puzzling over someone else's macro-laden code, scratching your head and guessing what it's doing and why. Know, don't just guess, when and how macros and macro variables will perform when your programs run. Knowledge is power: This Tutorial will give you a strong conceptual framework, and a few fun Macro techniques, that will help you correctly to leverage the Macro Facility to good advantage. INTRODUCTION SAS macros and macro variables become clear, predictable, and a potent part of your programming toolkit once you understand just how the Macro Facility operates in the context of your SAS programs. This Tutorial is designed to develop in you just such an understanding. You should have at least a little macro experience to get the most out of this presentation. Take this little one-question pretest: What will be the result of the following SAS program? %LET MOTHER=ma; %MACRO WHATHAP(PET,VEHIKLE); DATA _NULL_; PUT "My &vehikle&mother ran over my &pet&mother!"; %MEND WHATHAP; %WHATHAP(dog, kar) Do you confidently know the answer without having to actually run the program? Yes? YOU PASS! please proceed. But this is not an easy paper: a lot of concepts, many highly abstract, are delivered concisely within. And the real world code won t start until way into the paper; but don t worry, it will come eventually and you ll know how it works! THE BUSY LIFE OF A SAS PROGRAM Before you can grasp the operations of the Macro Facility in the course of a SAS program, you need to appreciate how a SAS program, even without macros, is taken in, understood, and processed by the SAS System. HOW SAS SEES PROGRAM CODE When you submit your SAS program to run, the lines you typed in at a keyboard are sent to an area in computer memory set up to receive them, called the input stack. The SAS System s tokenizing parser, called the word scanner, pops input, character by character, off the stack, and turns it into words and other tokens. Linguistically, the characters taken from the input stack are graphemes and the tokens are morphemes, the smallest indivisible units of meaning to the SAS System. These tokens are arranged in what is called the word queue from which the system will pull and deal with them in turn. Tokens are classified into four types: names, numbers, literals, and special characters. A name (in this context) is a sequence of letters, numerals, or underscores, the first of which is not a numeral, Special characters are any characters not letters, numerals, or underscores, numbers are numbers, and a literal is any sequence of characters, including spaces, enclosed in single or double quotes. Tokens are delimited by a space or a linebreak, but in addition, a special character followed immediately by a name, or vice versa, will be correctly parsed. Here is an example of tokenization into the word queue: SET STUFF; input stack WHERE X > 5; IF XSQUARED > 100 THEN SIZE= BIG ; word scanner Word Queue example SET name STUFF name ; special WHERE name X name > special 5 number ; special IF name XSQUARED name > special 100 number THEN name SIZE name = special BIG literal ; special

2 HOW SAS UNDERSTANDS PROGRAM CODE Having turned your input code into meaningful words, the task becomes to turn them into sentences, that is to say, SAS Statements, in a way the system can understand them. The SAS control supervisor, which oversees the appropriate orderly processing of your SAS program, retrieves tokens from the word queue and according to its own internal rules makes sense of them. In the example above, the rules indicate there are three SAS statements, 1 bounded by semicolons; the semicolon is the SAS statement boundary (in this code fragment, the first statement will have followed the semicolon preceding a previous statement not illustrated). Now as you know, a typical SAS program is comprised of program steps, of which there are two kinds: DATA and PROC. DATA Step statements are those of the DATA Step Language (DSL), a powerful programming language allowing many operations on data and providing interface to data structures -- SAS datasets to build, retrieve, combine them and so on. PROC steps typically perform specialized, parameter-driven tasks (SAS software PROCedures ) on SAS datasets, relieving the programmer from having to code the procedure s actions in DATA Step Language (some procedures actions cannot be written in DSL at all). PROC step statements generally provide parametric values describing what data the procedure is to use and what precisely it is to do with the data out of all the possible things it can do. A SAS program step begins with a DATA or PROC statement. A DATA step continues with DSL statements, while a PROC step continues with statements appropriate to the procedure. A program step ends at a RUN statement (some procedures end with a QUIT statement), when the next DATA or PROC statement is encountered, or at the end of the program code. In addition to statements that belong to DATA and to PROC steps, programs will often include state directive statements, such as OPTIONS statements, TITLE or FOOTNOTE statements, and a few others. The state of the various options, or of TITLES, etc, are maintained in internal tables for the duration of the SAS program. When an option or title value has been set by one of these statements, it will normally remain at that value unless another OPTIONS or TITLE statement overrides. (A program may also include statements to make comments or to run system commands, neither of which we will discuss, and Macro Language statements, about which we ll talk later ) Here is a simple SAS program that we will use for illustration. It consists of three steps, two DATA and one PROC, as shown with braces. Statements 1-5 and 7-12 are Data Step Language, statements are PROC step statements as applicable to the PRINT procedure, and statements 14 and 18 are state directives. 2 The RUN statements serve as system commands,explicitly terminating the step and asking SAS to process it. DATA Step DATA Step PROC Step 1 DATA STUFF; 2 DO X=1 TO 15; 3 XSQUARED=X**2; 4 OUTPUT; 5 END; 6 7 DATA MORESTUFF; 8 9 SET STUFF; 10 WHERE X > 5; 11 IF XSQUARED > 100 THEN SIZE='BIG'; 12 ELSE SIZE='SMALL'; OPTIONS NOCENTER; 15 PROC PRINT DATA=MORESTUFF; 16 WHERE XSQUARED < 200; 17 ID X; 18 TITLE 'More stuff'; 19 1 Technically, there is another statement within the IF statement: SIZE= BIG. But that s ok, one of the rules of an IF THEN statement is to execute a statement following THEN if the IF conditions are met. 2 Most state directive statements can appear either inside or outside a program step. Better coding practice here would be to put the TITLE statement outside any step and before the PROC step, eg preceding or following the OPTIONS statement, but we will soon use its inside placement to make a couple of points.

3 HOW THE SAS SYSTEM PROCESSES A SAS PROGRAM Having formed a statement out of the word queue, the SAS System control supervisor decides where to send it for further processing. DATA Step statements are sent to the Data Step Language compiler, PROC step statements to the appropriate procedure handler, and directives and commands to other SAS software facilities. We can illustrate the business of seeing, understanding, and processing your program this conceptually by the diagram at left. Your lines of code are read into the input stack, from which characters are delivered to the wordscannerr for tokenization. When a token is completed, it goes into the word queue, effectively a stream of tokens, which are retrieved by the SAS System and understood as statements. If the statement is in a DATA Step, it goes t the DSL compiler. If it in a PROC step, it goes to the appropriate procedure handler. Directives and commands go to some other SAS functional component. Now as you should know, SAS programs proceed step-by-step, with a compile phase followed by an execution phase. This compile/execute action cycle is taken per step, and only after it is completed does SAS proceed to undertake the next step. This is shown in the illustration at right. But it is also true that a SAS program proceeds to run more or less from top to bottom. So between steps 2 and 3 lies a state directive, an OPTIONS statement, and some feature other than the DSL compiler or a procedure handler will take action outside the stepwise compile/execute sequence. Now consider the TITLE statement nestled comfortably within the code for step 3. What happens when the control program encounters this statement? In effect, it suspends compilation of the step to let another software component deal with this state directive. Only after this is accomplished,will the step continue compilation and the PRINT procedure then execute. e. We will see presently that when macros or macro variables are encountered, these will also suspend step execution, and even statement construction, as the Macro Facility is brought into play.

4 ENTER THE MACRO FACILITY Your Great Macro De-Mystifier will be your understanding of the subtle interplay between step compile/execute and the SAS Macro Facility. While an OPTIONS or a TITLE statement might break the compilation flow of a SAS job step, the Macro Facility gets involved during the very tokenization of the program source code, and may cause new, macro- or macro-variable-resolved to go, right then and there, back through the word scanner before the next character is popped from the input stack. Macro processing is all about character strings. At left here is another, functional view of SAS code processing. Source input (the input stack) provides a character stream for tokenization (by the wordscanner into the word queue) which results in statements (constructed from tokens out of the queue) that are sent (by system control) to a DATA step, a PROC step, or elsewhere. constructed statements macro preceded immediately by a percentsign. Finally, open code is any sequence of characters that is neither found within a Macro definition, nor a macro variable reference, a Macro Language statement, or a macro reference. How the Macro Facility comes into play as your program is being processed is illustrated by the diagram at right. Generally, when the Macro trigger tokens & or % appear and are followed immediately by a name token, the Macro Facility will be invoked, then and there. When % is followed by the name MACRO, it signifies a %MACRO statement and thus the beginning of a macro definition. In this case, the Macro Language in the definition, up to the %MEND statement, will be compiled and stored for later use, after which control returnes to word scanner. If % is followed by LET, a macro variable value is assigned to a symbol, which is created if it doesn t already exist; thus %LET provides a macro variable definition. (%GLOBAL also may define a macro variable, but not its value.) But when macros or macro variables appear in program code, things begin to get interesting. Let s begin with some terminology. A macro variable is a name that serves as a symbolic reference to a sequence of characters, which is the value of the variable. Macro variable names and values may be constructed with the Macro statements %LET, %GLOBAL, or %LOCAL, and are stored in a memory structure called a symbol table. A macro variable reference is a symbol name name preceded immediately by an ampersand (&). A Macro Language statement looks like any SAS statement except that it is preceded immediately by a percentsign (%). 3 A macro definition is any sequence of characters that come between the Macro Language statements %MACRO and %MEND; the macro being defined is given a name on the %MACRO statement. A macro reference is the name of a Macro Macro Reference or Variable Reference Macro Definition or Macro Variable Definition Macro Facility 3 An exception is the %INCLUDE statement,, which is not part of the Macro Language but rather a system command.

5 While a macro or macro variable definition does not in and of itself do anything with the rest of the program code, a reference to a macro or macro variable does. When a macro is invoked, 4 the compiled macro definition is activated to create a pseudo-input character stream -- resolved code 5 -- that is sent back through the word scanner. Similarly, when a macro variable is referenced, the symbol table is consulted and the current value of the variable is retrieved and sent as resolved back through the word scanner. WHAT, WHEN, WHERE: A SAS JOB WITH MACROS OR MACRO VARIABLES Pretty abstract so far, yes? Let s see how this works in the concrete context of our example program, by altering the program to use macros and macro variables. Let s look first at macro variables, defining a couple of them and altering the second DATA step to use them, as follows original DATA MORESTUFF; SET STUFF; WHERE X > 5; IF XSQUARED > 100 THEN SIZE= ='BIG'; ELSE SIZE='SMALL'; variant %LET CUTOFF = 5; %LET SETNAME = STUFF; DATA MORESTUFF; SET &SETNAME; WHERE X > &CUTOFF; IF XSQUARED > 100 THEN SIZE='BIG'; ELSE SIZE='SMALL'; As you should know, the results of running the modified step will be exactly the same. But how does SAS get there? As illustrated at left, the two %LET statements set up the macro variables that will be referenced in the modified DATA step, by adding the variables and their defined values to the symbol table. Now that the variables are available in the symbol table, resolution of the SET and WHERE statements proceeds as illustrated at right: The word scanner goes about its business to fill the word queue with tokens. However, when token & is encounted, followed by a name, this process is interrupted while the Macro Facility retrieves the value of the named variable from the symbol table. The resolved code is put back throughh the word scanner and it is this that is tokenized and used to build the statements that are passed on to the compiler. (If we had forgetten to define a macro variable, the ampersand-name will be passed through directly, the SAS log will issue a warning that the referenced symbol is not found; in this and most other cases, the step will fail to compile.) 4 More SAS jargon: When a macro is referenced, the macro has been called, or invoked. The action taken by the Macro Facility at a macro invocation is called expanding the macro, per its definition. When a macro variable is referenced, it is resolved, per its current value in the symbol table. 5 The term resolved code is used to refer r to the pseudo-input that is sent from the Macro Facility out to the word scanner as a result of macro expansion or variable resolution, to substitute for the macro invocation or variable reference in the original code.

6 Now let s look at another variation on the example DATA step, this time using a macro. variant 1 %LET CUTOFF = 5; %LET SETNAME = STUFF; DATA MORESTUFF; SET &SETNAME; WHERE X > &CUTOFF; IF XSQUARED > 100 THEN SIZE= ='BIG'; ELSE SIZE='SMALL'; variant 2 %MACRO SETMAC; SET &SETNAME; WHERE X > &CUTOFF; %MEND SETMAC; %LET CUTOFF = 5; %LET SETNAME = STUFF; DATA MORESTUFF; %SETMAC IF XSQUARED > 100 THEN SIZE='BIG'; ELSE SIZE='SMALL'; Here, too, the results of running the modified step will be exactly the same. But now how does SAS get there? When the macro definition (ie %MACRO %MEND) is encountered, anything else stops, the macro is compiled, 6 and the compilation stored in the macro catalog SASMACR, usually in the WORK library. 7 When a macro invocation occurs here, the term %SETMAC word scanning stops, the macro is retrieved and executed, and its results (ie, the macro expansion) put back through the wordscanner. In this example there will be second trip back through the Macro Facility, because the expansion of the macro SETMAC contains macro variable references: 6 We could, if we had wanted to, have placed the macro definition inside the DATA step, after the DATA or the LENGTH statement, While that would be confusingly bad coding practice, it would work, because the macro would still be defined be,fore it is invoked. 7 unless it is being stored for future reference outside the current program, in which case you provide a library reference with the SASMSTORE= option and code the /store option on the %MACRO statement. But we won t go into this here.

7 RESCANNING You have just seen an example of the Macro Facility rescanning, Actually all resolved code from the Macro Facility is re-scanned ie goes back through the word scanner -- but in SAS jargon the term refers more narrowly to the 8 loop back through the Macro Facility after a macro trigger is encountered in the resolved code. Always remember that the macro facility deals with character strings. True, Macro Language provides for some numerical manipulations, but the input word scannerr throws, and output the Macro Facility returns back, are character strings. This illustration, tration, culled from the diagram presented earlier, depicts the process. So long as the word scanner throws a macro trigger (macro definition or invocation, macro variable var definition or reference) the code will again be passed through the Macro Facility for processing. Only after all macro triggers, from however many passes, are resolved, does the fully resolved code go on to the SAS System for processing. More about rescanning later will be revealed later in this Tutorial. COMPILE AND EXECUTE OVERRIDES THE LOOP OK, now that you think you ve got it, I must throw a curve ball at you, because things are always more complicated than they seem, especially as far as the he power of the SAS System goes. As a macro or macro variable is being resolved, it maintains a more dynamic relationship with tokenization than I have depicted. Remember that when the end of a SAS job step is recognized, compilation is completed and tthe he step code executes? Well, if the Macro Facility produces the end of a step, execution commences and after that the Macro Facility picks up where it left off. The following code segments produce exactly the same output: variant 3 variant 2,, and the PROC PRINT step. assuming %SETMAC and %LETs as above, and using a variant datasetname, just because. DATA MORESTUFF2; SET STUFF; %SETMAC IF XSQUARED > 100 THEN SIZE='BIG'; ELSE SIZE='SMALL'; OPTIONS NOCENTER; PROC PRINT DATA=MORESTUFF2; WHERE XSQUARED < 200; ID X; TITLE 'More stuff' V2 ; 8 %MACRO ODDMAC; 'SMALL'; OPTIONS NOCENTER; PROC PRINT DATA= %MEND ODDMAC; DATA MORESTUFF3; SET STUFF; %SETMAC IF XSQUARED > 100 THEN SIZE='BIG'; ELSE SIZE= %ODDMAC MORESTUFF3; WHERE XSQUARED < 200; ID X; TITLE 'More stuff V3'; You may have noticed ced that in the example code, the macro definition appeared in code before the %LET statements defined the macro variables. This could have been the other way around. It didn t matter because the macro definition stored the & characters as they are; it s only at macro invocation that these need to have their values. Indeed, most macro compilation involves the storage of fixed text. It is only when the Macro Language actually has to predicate actions for example, in a %DO %END group, an %IF statement, etc. that computer instructions are truly compiled. Even if the %LET statements were placed inside the macro itself, after the %MACRO statement, these would be stored as text, and put back through the word scanner only onl at macro execution.

8 What happens pens is that the Macro Facility duly processes %ODDMAC, but in the middle of ODDMAC is a RUN statement. At that point, the DATA step executes. After that, the he resolution of %ODDMAC continues where it left off, and the processing continues: What would uld happen if, instead of an odd macro, we used an odd macro variable? variant 3 %MACRO ODDMAC; 'SMALL'; OPTIONS NOCENTER; PROC PRINT DATA= %MEND ODDMAC; DATA MORESTUFF3; SET STUFF; %SETMAC IF XSQUARED > 100 THEN SIZE='BIG'; ELSE SIZE= %ODDMAC MORESTUFF3; WHERE XSQUARED < 200; ID X; TITLE 'More stuff V3'; variant 4: Macro Variable instead nstead of Macro %LET ODDITY = %STR( 'SMALL'; OPTIONS NOCENTER; PROC PRINT DATA= ); DATA MORESTUFF4; SET STUFF; %SETMAC IF XSQUARED > 100 THEN SIZE='BIG'; ELSE SIZE= &ODDITY MORESTUFF4; WHERE XSQUARED < 200; ID X; TITLE 'More stuff'v4 ; You guessed it: The result would be the same. TWO HELPFUL SAS SYSTEM OPTIONS: MPRINT AND SYMBOLGEN If you want to see macros and macros in action in your very own programs, you can turn to your SAS log. The MPRINT option shows you the fully resolved code emergent from macro and macro variable resolution as the SAS System will see it. First, let s see what the MPRINT option does with Variant 3. Here s the SAS log (macro definitions not shown)

9 536 OPTIONS MPRINT; 537 DATA MORESTUFF3; SET STUFF; 540 %SETMAC MPRINT(SETMAC): SET STUFF; MPRINT(SETMAC): WHERE X > 5; 541 IF XSQUARED > 100 THEN SIZE='BIG'; 542 ELSE SIZE= 543 %ODDMAC MPRINT(ODDMAC): 'SMALL'; MPRINT(ODDMAC): MPRINT(ODDMAC): OPTIONS NOCENTER; MPRINT(ODDMAC): PROC PRINT DATA= 544 MORESTUFF3; 545 WHERE XSQUARED < 200; 546 ID X; 547 TITLE 'More stuff V3'; 548 The MPRINT option has caused the Macro Facility to tell you what the two macros we ve invoked have done. If you mentally remove the macro invocations and substitute the results of MPRINT in their place, you see what the DATA and PROC steps saw. If we add the SYMBOLGEN option, we get a log that fully documents the actions taken on macro variables as well: 551 OPTIONS SYMBOLGEN; * (LEAVING THE MPRINT OPTION STILL ON); 552 DATA MORESTUFF3; SET STUFF; 555 %SETMAC SYMBOLGEN: Macro variable SETNAME resolves to STUFF MPRINT(SETMAC): SET STUFF; SYMBOLGEN: Macro variable CUTOFF resolves to 5 MPRINT(SETMAC): WHERE X > 5; 556 IF XSQUARED > 100 THEN SIZE='BIG'; 557 ELSE SIZE= 558 %ODDMAC MPRINT(ODDMAC): 'SMALL'; MPRINT(ODDMAC): MPRINT(ODDMAC): OPTIONS NOCENTER; MPRINT(ODDMAC): PROC PRINT DATA= 559 MORESTUFF3; 560 WHERE XSQUARED < 200; 561 ID X; 562 TITLE 'More stuff V3'; 563 Here the information is redundant, but when you use macro variables outside of a macro definition, you need SYMBOLGEN to tell you what has happened because MPRINT doesn t do anything outside a macro invocation. Let s run Variant 4: 1488 %LET ODDITY = %STR( 1489 'SMALL'; OPTIONS NOCENTER; 1492 PROC PRINT DATA= 1493 ); 1494 DATA MORESTUFF4; SET STUFF; 1497 %SETMAC

10 SYMBOLGEN: Macro variable SETNAME resolves to STUFF MPRINT(SETMAC): SET STUFF; SYMBOLGEN: Macro variable CUTOFF resolves to 5 MPRINT(SETMAC): WHERE X > 5; 1498 IF XSQUARED > 100 THEN SIZE='BIG'; 1499 ELSE SIZE= 1500 &ODDITY SYMBOLGEN: Macro variable ODDITY resolves to 'SMALL'; OPTIONS NOCENTER; PROC PRINT DATA= 1501 MORESTUFF4; 1502 WHERE XSQUARED < 200; 1503 ID X; 1504 TITLE 'More stuff' V4; 1505 If you save your SAS logs as documentation of program runs, it s nice to have MPRINT and SYMBOLGEN on. 9 RESCANNING REVISITED: DELAYED AND INDIRECT VARIABLE REFERENCE When two or three ampersands (&) butt up against each other before a name, things happen that you may find quite useful in Macro Language practice. 10 My term for using two ampersands is delayed reference, and for three ampersands indirect reference. Combined with DATA Step Language including CALL SYMPUT() and CALL EXECUTE(), described later below, you can do very powerful things. DELAYED REFERENCE When the Macro Facilithy receives two ampersands before a name, by design it scrunches them into one. When the code goes back to the wordscanner, it will be rescanned, because there s still an ampersand there. Consider some macro variables MV1, MV2, and MV3, as illustrated. If we construct some text using these macro variables and send it through for proessing, the values of these variables will be applied by the usual wordscanner/macro Facility cycle. But these macro variable names are related, aren t they: They have the same first two letters, with the last character looking like an ordinal sequence number. Let s write the macro WHATHAVE as follows: %MACRO WHATHAVE; %DO K = 1 %TO 3; a &&MV&K, %END; %MEND WHATHAVE; and use it in a DATA Step, as follows: DATA PETS; PUT "We have %WHATHAVE"; 9 For debugging programs with complicated macro language, or just to see how they work, try the MLOGIC option. 10 Actually, interesting things can happen some of them even useful -- if you butt together more than three ampersands, or percentsigns, or both, but we won t be getting into that...

11 What will be written to the SAS log? You guessed it: We have a Cat, a Dog, a Goldfish, Not perfect (the comma at the end, no and ), but still. Observe that a total of six trips throughh the Macro Facility are created by this %DO group, two for each value of K. When K=1, &&MV&K resolves as & (the two ampersands were scrunched down to one) + MV + 1, or &MV1. The second pass is caused by the remaining ampersand, and &MV1 resolves to Cat. By this method, we have fully resolved each &&MV&K term by delayed reference: we will resolve &MV1, but only after we know it is &MV1. INDIRECT REFERENCE When the wordscanner encounters three ampersands before a name, the Macro Facility also scrunches the first two consecutive ampersands down to one, and continues to work on the remainder of the term, after which it immediately rescans. Here s how it works: Consider the two macro variables PET and CAT created by %LET statements as illustrated here. When these are dereferenced later in the program, &PET of course resolves to CAT and CAT to Persian, so My &PET is a &CAT becomes My CAT is a Persian. But notice something else here: The variable is the name of another. value of one macro When the value of a macro variable is the name another macro variable, you can get at the value of the second variable by reference to the first. This is done by coding three ampersands in a row in front of the name of the first. The Macro Facility encounters two ampersands, and scrunches them into one. Next it sees an ampersand-name term, and resolves that. So on the first scan of &&&PET, it turns && into & and is left with &PET which resolves to CAT. The term &CAT, having an ampersand, is re-scanned, and resolves to Persian. DEFINING MACRO VARIABLES AND INVOKING MACROS FROM A DATA STEP A SAS data step, when executing, can communicate with the Macro Facility. It can write macro variables to the symbol table, or read variable values from the table, or delete variables from it. It can invoke macros conditionally. It can even ask for the resolved value of a macro without actually invoking it. Of these abilities, writing to the symbol table with CALL SYMPUT() is the most useful in practice, and the second most useful is conditional macro invocation with CALL EXECUTE().

12 CALL SYMPUT: DEFINING A MACRO VARIABLE AT DATA STEP EXECUTION A DATA Step, while executing, can write macro variables to the symbol table in real time using CALLSYMPUT(). This technique can serve several purposes, including to pass information from a DATA step to a subsequent job step, or to a subsequent macro invocation. Here is an example, very simplified, from the real world. Medical center outpatient pharmacies at a certain managed care hospital system issue a claimcheck to a customer when she presents a prescription at the counter. This claimcheck will be presented when she returns to the counter to pick up her medicine after the order has been filled. The computer systems at various pharmacies record the prescription transactions in a DB2 database, and we want to do some analyses on the throughput times of prescription preparation at specific pharmacies over the previous month. Our first order of business is to gather the relevant information for a each pharmacy out of a database table PIMS.VOUTPAT_RX, and the following macro is defined. The keyword parameter PHM refers to the pharmacy identifier in the database (PHARMACY) and the other database fields of interest are TAKEIN_DATE, actually a datetime value, that tells when the claimcheck is issued, and FILL_DATE, the datetime the prescription was ready for pickup. The program to get data for August for pharmacy A10 might look something like this: 1 PROC SQL ; 2 CONNECT TO DB2 (SSID=DSN2); 3 CREATE TABLE DD1.A10 AS 4 SELECT * FROM CONNECTION TO DB2 5 (SELECT PHARMACY 6,TAKEIN_DATE AS TAKEIN_DT 7,FILL_DATE AS FILL_DT 8 FROM MYDB2.TABLE 9 WHERE PHARMACY = 'A10' 10 AND TAKEIN_DATE BETWEEN '08/01/2009' AND '08/31/2009' 11 ORDER BY TAKEIN_DT 12 ); QUIT; To avoid changing theprogram code at line 10 each month, we can define a macro, GETA10: 1 %MACRO GETA10(START,END); 2 PROC SQL ; 3 CONNECT TO DB2 (SSID=DSN2); 4 CREATE TABLE DD1.A10 AS 5 SELECT * FROM CONNECTION TO DB2 6 (SELECT PHARMACY 7,TAKEIN_DATE AS TAKEIN_DT 8,FILL_DATE AS FILL_DT 9 FROM MYDB2.TABLE 10 WHERE PHARMACY = 'A10' 11 AND TAKEIN_DATE BETWEEN &START AND &END 12 ORDER BY TAKEIN_DT 13 ); QUIT; 14 %MEND GETA10; and now if we want to get the September 2009 data for pharmacy A10, we could invoke %GETA10('08/01/2009', '08/31/2009') The invocation parameters become, of course, local macro variables and will be substituted for &START and &END at line 11 of the macro when it executes, resolving to what was line 10 in the non-macro program. (By the way, the single-quotes in the date parameters here are because DB2 needs single quoted constant values.) Now when we want to get the following month s data, we only need to change the parameters in the macro invocation. Although this is just about as easy or hard as changing the code in line 10 of the original program, imagine another, more complicated program that has more values to change. on different lines. But the real reason we want to do this is so we can put the program in production to run automatically each month, getting the data for the previous month. Although there are other ways to approach this, 11 here s one that illustrates CALL SYMPUT in action. We change 11 A more elegant, albeit less readable, approach would be to use the %SYSFUNC macro function within the GETA10 macro definition, but we won t get into that in this paper.

13 the macro definition of GETA10 to use no parameters (ie, %MACRO A10;, rest of definition the same) and run a DATA step to use CALL SYMPUT (which is part of the DATA Step Language), and then invoke GETA10: 1 DATA _NULL_; 2 T=TODAY(); 3 SD=INTNX('MONTH',T,-1); 4 ED=INTNX('MONTH',T,0)-1; 5 S="'" PUT(SD,MMDDYY10.) "'"; 6 E="'" PUT(ED,MMDDYY10.) "'"; 7 CALL SYMPUT('START',S); 8 CALL SYMPUT('END',E); 9 10 %GETA10 The INTNX functions in assignment statements at lines 3 and 4 create SAS date values representing the first and last days, respectively, of last month. Because DB2 wants its date constants of the form mm/dd/yyyy so long as they are bounded by single quotes, we build data step variables S and E as shown.at lines 5 and 6. (We could do the job without creating any data step variables at all, putting all the logic in the second parameter of the symput calls, but that would make the program very hard to read, much less debug.) Line 7 will put the value of the data step variable S into the symbol table in macro variable START when the step executes (another reason it s always good to use an explicit RUN statement at the end of a SAS data step). Similarly, line 8 enters the macro variable END in the symbol table, giving it the value of the data step variable E. Running this program in September 2009, the macro invocation %GETA10 results in the following: MPRINT(GETA10): PROC SQL ; MPRINT(GETA10): CONNECT TO DB2 (SSID=DSN2); SYMBOLGEN: Macro variable START resolves to '08/01/2009' SYMBOLGEN: Macro variable END resolves to '08/31/2009' MPRINT(GETPHARM): CREATE TABLE DD1.A10 AS SELECT * FROM CONNECTION TO DB2 (SELECT PHARMACY,TAKEIN_DATE AS TAKEIN_DT,FILL_DATE AS FILL_DT FROM PIMS.VOUTPAT_RX WHERE PHARMACY = 'A10' AND TAKEIN_DATE BETWEEN '08/01/2009' AND '08/31/2009' ORDER BY TAKEIN_DT ); MPRINT(GETPHARM): QUIT; Notice that we can run this in any month with no code changes to get the data for pharmacy A10 for the previous month, and we can put our program in production and forget about it. CALL EXECUTE: CALLING A MACRO BY CONSTRUCTING ITS INVOCATION IN A DATA STEP Or can we? Suppose we want to run the data on other pharmacies (which we do). We can make a small modification to the macro, adding back a parameter for the pharmacy id (actually we ll need two of these, one without singlequotes and one with, for the SAS dataset name and the DB2 column name respectively): 1 %MACRO GETPHARM(PHM,QPHM); 2 PROC SQL ; 3 CONNECT TO DB2 (SSID=DSN2); 4 CREATE TABLE DD1.&PHM AS 5 SELECT * FROM CONNECTION TO DB2 6 (SELECT PHARMACY 7,TAKEIN_DATE AS TAKEIN_DT 8,FILL_DATE AS FILL_DT 9 FROM MYDB2.TABLE 10 WHERE PHARMACY = &QPHM 11 AND TAKEIN_DATE BETWEEN &START AND &END 12 ORDER BY TAKEIN_DT 13 ); QUIT; 14 %MEND GETPHARM; and invoke as %GETPHARM(A10, A10 ). Then if we want the same data for pharmacy B11 (for example) we invoke again as %GETPHARM(B11, B11 ), and so on for any pharmacy. We could make this a little cleaner by using only one parameter in the macro definition and macro language in the definition to create another one with quotes, but for illustration here this will do. We have two problems in the real world: (1) we re not sure from month to month which pharmacies data will be required in libref DD1; (2) we still want to put the program in production and forget it. Fortunately for us, there is a

14 dataset created each month by an earlier program that contains, among other things, the pharmacy identifiers we will need. Let s make a little temporary dataset whose rows contain a single variable, the pharmacy identifier: PROC SORT NODUPKEY DATA = DD0.PHARMSET (KEEP=PHARM) OUT= PINPUT; BY PHARM; Suppose for example here that the this month s dataset PINPUT turns out to have the following rows: PHARM A10 A14 B10 B11 C12 which represent the pharmacies for which we want to run our SQL select against DB2. Is there a way to do that? Does it involve CALL EXECUTE()? Yes, and yes. The EXECUTE call reoutine lets you construct a string at DATA step runtime, that will be submitted to SAS after the DATA step concludes. For example; DATA _NULL_ ; COLOR1='Blue'; CALL EXECUTE ('DATA A; INCOLOR ="' COLOR '"; PUT INCOLOR= ; '); includes a full DATA step as the single argument to CALL EXECUTE, which will be (compiled and) executed immediately after the DATA _NULL_ step terminates. The argument to CALL EXECUTE can be just about anything, so long as SAS can put it through the wordscanner, as you can see from the example above, the power of EXECUTE is to use variables from the originating DATA step to help compose the argument. In this case, we could have write the program as DATA _NULL_ ; COLOR1='Blue'; STRING = 'DATA A; INCOLOR ="' COLOR '"; PUT INCOLOR= ; '; CALL EXECUTE (STRING); and get exactly equivalent results. Do you see where we re going with this? Using the GETPHARM macro defined above, with its signature GETPHARM(PHM,QPHM), we can automate the production of data for all the pharmacies in PINPUT by coding something along these lines: 1 DATA _NULL_; 2 IF _N_=1 THEN DO; 3 T=TODAY(); 4 SD=INTNX('MONTH',T,-1); 5 ED=INTNX('MONTH',T,0)-1; 6 S="'" PUT(SD,MMDDYY10.) "'"; 7 E="'" PUT(ED,MMDDYY10.) "'"; 8 CALL SYMPUT('START',S); 9 CALL SYMPUT('END',E); 10 END; 11 SET PINPUT; 12 INVOKE='%GETPHARM(' PHARM ",'" PHARM "')"; 13 PUT / INVOKE= ; 14 CALL EXECUTE (INVOKE); 15

15 The result will be five macro invocations, one for each of the rows in PINPUT, because for each DATA step iteration the lines outside the DO-END END group will of course be processed, and CALL EXECUTE is one of the statements. To illustrate, let s create another macro and use that in the DATA step instead. All that macro will do is write a line to the log using the two parameters. To declut declutter ter the results, we ll turn off the MPRINT and SYMBOLGEN options %MACRO DEMO(PHM,QPHM); %PUT PHARMACY &PHM SINGLE SINGLE-QUOTED IS &QPHM; %MEND DEMO; OPTIONS NOMPRINT NOSYMBOLGEN; DATA _NULL_; IF _N_=1 THEN DO; T=TODAY(); SD=INTNX('MONTH',T,-1); 1); ED=INTNX('MONTH',T,0) ED=INTNX('MONTH',T,0)-1; 1; S="'" PUT(SD,MMDDYY10.) "'"; PUT(SD,MMDDYY10.) "'"; E="'" PUT(ED,MMDDYY10.) "'"; CALL SYMPUT('START',S); CALL SYMPUT('END',E); END; SET PINPUT; INVOKE='%DEMO(' PHARM ",'" PHAR PHARM "')"; CALL EXECUTE (INVOKE); And here is what we see in the SAS log, PHARMACY A10 SINGLE-QUOTED QUOTED PHARMACY A14 SINGLE-QUOTED QUOTED PHARMACY B10 SINGLE-QUOTED QUOTED PHARMACY B11 SINGLE-QUO QUOTED PHARMACY C12 SINGLE-QUOTED QUOTED IS IS IS IS IS 'A10' 'A14' 'B10' 'B11' 'C12' SUMMARY AND CONCLUSION SAS parses program code into tokens, the smallest units of meaning. Tokens are taken from a queue and analyzed to form understood SAS statements. These statements may be part of a DAT DATA A or a PROC step, and are compiled or handled accordingly. When a step ends, the compiled code is executed. If during the compile stage the special character tokens & or % are encountered followed by a name, compilation is interrupted and the code is sent to the Macro Facility The Macro Facility creates and resolves macro variables and macro code. If two ampersands are encountered together, the Macro Facility resolves these to one and continues scanning Resolved code is sent back for tokenization as n needed until it is fully resolved. When code is fully resolved, job step compilation continues. If resolved code contains the end of a job step, macro processing is interrupted and the step executes. An executing DATA step can communicate with the Macro Fac Facility ility to populate the symbol table A DATA step can conditionally trigger macro execution Macro acro processing is not magic at all, but a part of the orderly SAS processing of your program. You have seen how it works. Go and learn more. Look at others programs and make mental sense of them. If there is macro language you don t understand, such as functions and quoting, look it up in your documentation. Bring my Macro class to your company. Soon you will get ideas how to use the Macro Facility in your own practice. Live long, and prosper. PRESENTATION 2009 JAY A. JAFFE SAS IS A REGISTERED TRADEMARK OF SAS INSTITUTE INC.