SAS users do have the ability to create their own SAS PROC's. They have to license SAS/Toolkit and code in C or in some other languages SAS has many different parts. Macro is (or used to be) the most (and probably the only) universal tool in SAS that can put (almost any but not every) parts together.
Given how primitive and strange the macro (language) is, this is a bit funny but true.
SAS users do have the ability to create their own SAS PROC's. They have to license SAS/Toolkit and code in C or in some other languages. SAS has many different parts.
Macro is (or used to be) the most (and probably the only) universal tool in SAS that can put (almost any but not every) parts together. Given how primitive and strange the macro (language) is, this is a bit funny but true.
Thanks for the reminder about SAS/Toolkit - I had forgotten about that product. – cmjohns Oct 21 '10 at 16:58.
It's kind of like asking why do we have Perl, Python, ksh, bash, etc. When we have all the programs that are available in UNIX. Macros are the scripting language that gives users a great deal of flexibility and control over what they want SAS to do. You can easily generate dynamic code as well.
Existing procs are fairly rigid in what they can take as input and what you get as output. Proc FCMP has opened up the data step to user defined functions, but this is still no substitute for the flexibility that you get with the macro language.
1 for mentioning that SAS Macro code can write code dynamically. This in my mind is the main reason for writing macros. – Rob Penridge Oct 22 '10 at 18:44.
You can create a custom macro without licensing toolkit- and to my recall not many people seem to use SAS Toolkit for custom procedures. Macros help run programs repeatedly with customized parameters and are invaluable for variable manipulation and creation procs are generally output devices. Macros can help with repeated data step manipulation as well.
There are lots of uses and advanced features of macros, but I mainly just use them so I can try to stay true to the DRY Princicple. If you find yourself in a situation where you are repeating blocks of code frequently, you might want to do this. For example, I export datasets to excel all the time.
If I end up doing it over a few times in my code, I just put the code in a macro: %macro export_set_excel(data,path,filename,sheetname); PROC EXPORT DATA= &data. OUTFILE= "&path. &data."
DBMS=EXCEL REPLACE; SHEET="&sheetname. "; NEWFILE=YES; RUN; %mend export_set_excel; Then as I'm going along in my code. I make a dataset, and I want to export it, I can just write: %export_set_excel (data=MyDataSet, path=C:\Temp\, filename=mydata.
Xlsx, sheetname=exportedData); That is one simple line I have to write 30 times in one file instead of having to write 7 or 8 lines 30 times. It makes it easier to track down mistakes, and if I want to change something about how I'm exporting, I just have to change it in one place. I use it for a lot more than just exporting, but that should give you a general idea.
If you are familiar with other languages, you will find the sas macro language pretty lacking and cumbersome, but it is most definitely better than nothing.
Most of the SAS procedures perform specific operations on data. Macros allow run-time conditional processing of blocks of SAS code, such as repeating a procedure call on different data sets using a DO loop, or decidng to run a data step based on whether a file exists. While the code seems clunky to newcomers, it is actually relatively easy to pick up once you learn BASE SAS, since the syntax is nearly identical (with a sprinkling of %s and @s for flavor).
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.