Compiled macro code?

[Dundee]

Hi,

I would like to be able to analyze the code of a sas program.
The problem is: the macros.
Is there a way i could see/obtain/interact the code after it went trough the macro compiler, so it is cleaned of any macro references?

Example. If i have:
%let year=2007;
data temp;
set historic_&year.;
run;

What i want to analyze is:

data temp;
set historic_2007;
run;

The only 2 ways i found so far are:
- Run the program, analyse the log. Which is bad because reading the log isnt easy and the program must be run.
- Create my own macro compiler in java/C/etc to resolve all macro references, and then analyze the code. I dont think creating a macro compiler is an easy task 🙂 hehe
- Get hired by SAS to get access to the inner working of the SAS program. Nothing easy there! 🙂

[deleted_user]

I guess the first 16 lines of my reply could be "Why do you want to do this?"

Forget about option 3, being hired by SAS won't give you anything you haven't already got as a user.

Forget option 2, replicating the macro compilation rules and getting it correct would be an herculean task.

Run the program and analyze the log. Just make sure that in running the program you aren't killing anything essential like a permanent data set, and you should be able to run it multiple times with impunity.

If you want a file of generated macro code, then use the MPrint and MFile options to create a file reference and redirect the code to this file. You'll find these well documented in the SAS factual material.


But again, why do you need to do this? The macro facility is a text substitution facility. If you have developed your macro according to Hoyle (and Zender) then you started with a plain SAS program that worked. Then you substituted macro symbols for the variable pieces, testing along the way. Finally, you have a piece of code that has had fixed elements replaced by macro symbols and you should have the right result. So why would you need what you ask for?

Cynthia has explained the golden path to macro creation in many posts in the forum. I'm sure a search of the index would get you her well-chosen and helpful words.

Kind regards

David

[Dundee]

Thanks a lot for your reply David.
I guess i could answer a lot of your questions by mentioning that it is not my code i want to analyze, but programs from everyone in the company.
I guess my question was kinda weird if you thought it was for my code hehe

Why do that? Many things. To know what directories are used on import/export for example. And with the macro references unresolved it was impossible.

I'll try your MPrint/MFile suggestion. And maybe having an options such as obs=0 would be good.


Benoit

[advoss]

ComplementSoft has a tool called ASAP that can graphically analyze a SAS program (or better yet a SAS log). I haven't used it for a while and it didn't quite meet my needs, but it might help you a bit if the programs are not too big.

[deleted_user]

Be careful Dundee, "Obs = 0" is a great debugging statement but it is not going to save you from overwriting a permanent data set with an empty permanent data set.

Redirecting the permanent libraries is a much better solution.

Kind regards

David

[Dundee]

Yeah, thanks for the advice.
So there is no such things as "noexec" for datasteps?

Also, is it possible to read a text file without importing it into a table?

[deleted_user]

or,
have a look at the file generated on fileref MPRINT (as long as you pre-assign it) when you switch on the MFILE option.

This is the syntax submitted after all macro substitution. Of course using this feature is probably better described in the onLine-Doc as at http://support.sas.com/onlinedoc/913/getDoc/en/mcrolref.hlp/a000209304.htm.

Good Luck

PeterC

[deleted_user]

In response to DKJV's Why?

The reason I found this feature most compelling when it first became available (remember NOreservedB3), was to push the generated data step code through the data-step debugger !

PeterC

[deleted_user]

apologies for repeating points already made in messages posted earlier by DKVJ

In order to attempt to provide something new, I would recommend that "production" processes (upon which business or clinical trials depend) should include space to store SASlogs. These provide much better evidence of the process by which results are obtained. Such useful information as indicated by "Dundee/Benoit", input/output files are fully defined in a SASlog along with many other bits.
A big problem comes when a problem arises in a process that is best resolved with mPrint type information, but the Log has be "minimised" with such features as NOsource2. Worse would be noSource or NOnotes........

Anyway,
Apologies for my earlier redundant repetitious posts..

PeterC

[Dundee]

Thanks for your help everyone.
I'll be more specific, so maybe you will understand better why i am asking those questions, and which direction im taking.

I work for a company with a lots of programs. Suppose we need to make some changes to a file such as:
W:\TarificationFiles\2007\WesternCanada.xls
And this file is imported by SAS programs.

Because of the modifications, we need to make sure all programs using this file will still be running correctly. If i search for the file in the programs' code, it might be tricky because it can be stored in a macro var, or imported by a macro, etc.

Option 1
So, in a perfect world, i would put an option in the sas program such as
"analyse_input_output_files" and when SAS would run the program "MyProg.sas", it
would create a table such as:

Program Input_Output Filename
------------------------------------------------------------------
MyProg IN W:\TarificationFiles\2007\WesternCanada.xls
MyProg OUT W:\Results\2007\Results.xls
MyProg OUT W:\Results\2007\Validation.xls

Option 2:
I run a program, either Java/C/SAS, or anything. This program will read MyProg.sas, resolve macro code, and find out which files are used. This option is tough, but is good because MyProg.sas doesnt needs to be run. (of course some problems might appear if some macro vars are defined in an sql statement or in a data step)


Option 3:
MFile option is used. The automatic launcher that launches all programs on daily/weekly schedules set this option for every program. Then, i can analyze the logs with another program. The problem with this option is that the program needs to be run.



So.
I dont see how to do anything like option 1, unless i was working for SAS.

Option 2 could be nice, but i would need to find a way to resolve macro stuff without spending years to create a macro compiler 🙂

Option 3 is the one i can do pretty easily, but programs needs to be executed. Not so great when programs takes hours to run...



I guess i should have given those details in my first post 🙂

[Cynthia_sas]

Hi:
There just is no way to resolve the references without running the code. Even working for SAS, only the developers who work on the Macro processor can see the "internals" of how the Macro processor works. Here's what I would try:

1) Search the code for some piece of the name that never changes, like 'historic' or .xls or &year or &fname (or whatever you set) -- there have to be %let statements or CALL SYMPUTS. If you are lucky and the people who wrote the macro programs were organized, you may find that they used the same kind of macro variables...like &year or &yr or &yyyy. Once you find the code where the macro variables are set, you will at least have narrowed down the universe of places to start.

2) Did the programmers do ANY documentation? ANY at all? Usually f olks who do macro programming put a comment block at the top of the code to document the dependencies and usages and if you're lucky, the input parameters and input and output files.

3) Take a macro class. After 2- 3 days of intensely working on macros, sometimes, you get the hang of resolving simple macro references in your head....at least enough to get you pointed to the some places to start.

4) Start documenting those macro programs. Don't just run them without looking at the log after each one to try to put together some beginning notes and comments/run documentation. Even if it's just [pre]
/* ******************** ********************
This macro is named: %makefile
It uses: &year and &i
This macro calls: %wombat and %koala
the outputs are 2 SAS data sets perm.sales_&year and perm.returns_&year
************** ******************** */ [/pre]

You can refine the comments as you discover more about each macro program.

Good luck!
cynthia