First I will make a style comment that may save you a LOT of headaches in the long run. Having a non-SAS automatic macro variable appear in the middle of a macro definition leads to all sorts of questions about "where does that come from and what might it contain" when reviewing code that has the macro calls and definition but possibly not the %let statements or other code that generates the macro variables. So you would be better off providing those variables as Parameters to the macro such as:
%MACRO Printcars(type_name=, origin_location=);
PROC PRINT DATA = sashelp.cars;
WHERE type = &type_name and origin = &origin_location;
RUN;
%MEND Printcars;
/* and use Note the above definition will not work with this call
but for the point about parameters it is an example*/
%printcars(type_name = Sports, Origin_location = Europe);
The second thing to carefully look at how you want to generate code. Do you ALWAYS subset to a Type_name or origin (your question suggests no), or even do you always want a WHERE statement at all?
Ideally the macro code would determine this from the parameters passed OR require an additional parameter to force the use of the Where statement, a style choice depending on the actual use of a macro.
You can parse the values of your type_name and/or origin_location values to indicate what to do.
But first consider the types of code you want to generate. Hint: passing quotes or having quotes in macro variables often can be a mess in the long run.
Here is one way, with my take on making a more flexible macro:
%MACRO Printcars(type_name=, origin_location=);
PROC PRINT DATA = sashelp.cars;
%if %length(&type_name.)>0 or %length(origin_location)>0 %then %do;
/* a where clause is requested*/
where
%if %sysfunc(countw(&type_name.))>0 %then %do;
/* need a type name comparison*/
type in (
%do i= 1 %to %sysfunc(countw(&type_name.));
/* uses default list of separators for possible multiple types*/
%let t = %scan(&type_name.,&i.);
/*place the type inside the parntheses of the IN operator*/
"&t."
%end;
/*close the parentheses for the In operator*/
)
/* if origin is needed place "and" after the type list*/
%if %length(origin_location)>0 %then %do;
AND
%end;
%end;/* of type*/
/* similar for origin_location*/
%if %sysfunc(countw(&origin_location.))>0 %then %do;
/* need a type name comparison*/
origin in (
%do i= 1 %to %sysfunc(countw(&origin_location.));
/* uses default list of separators for possible multiple types*/
%let t = %scan(&origin_location.,&i.);
/*place the type inside the parntheses of the IN operator*/
"&t."
%end;
/*close the parentheses for the In operator*/
)
%end;/* of origin*/
/* next ends the where clause when needed*/
;
%end;
run;
/* WHERE type = &type_name and origin = &origin_location;*/
/* RUN;*/
%MEND Printcars;
options mprint;
%Printcars(type_name=Sports SUV, origin_location=Europe)
options nomprint;
Note that I turned on the MPRINT option to show what the generated code looks like.
I hope the comments help with why each piece is there.
General comment with macro code learning: Save the code before running it! It is very easy with macro code errors to generate stuff that renders the SAS system hard to recover from. Symptoms like "nothing happening" or code in the log with nothing running are common depending on which unclosed quote or parentheses might be involved. Mismatched " ' are another issue.
A more generic approach would be the make the data set a parameter.
You can also make a parameter like Parm= type="Sports" but you still have to check whether you have provided a value for it and whether an Where statement should be generated (plus the origin). What might happen with the longer form of where condition is that you may end up using characters that require macro quoting such a comma, & (consider a company name value like "Jones & Sons"), % and others. Which can be a tad sticky.
