12-05-2013 02:56 AM
My problem is
I have a sas code embedded into an enterprise guide project.
The code does what I want it to do - I rather complicated recursive macro which has a defined result.
There is one last table which is is created fine, so there shouldn't be an endless recursion or endless loops.
However, executing the code, the code symbol stays green, and the following steps stay yellow, and don't get executed.
It can only be stopped by disconnecting the sas system.
What could go wrong?
12-05-2013 08:45 AM
There was no log when I ended the process. The file lib.cashflows looks perfect.
I cannot attach the code here because the browser doesn't let me cut and paste
Here is a picture of the end of the macro read_alle and the execution statement of it:
There are some loops before that, but they all end perfectly befroe the data step with the creation of
lib.cashflows is executed.
Is there some sort of quit or run statement missing?
12-05-2013 09:02 AM
Perhaps try temporarily commenting out the call to the macro function read_alle and just code a data step to output lib.cashflows to see if it is the macro function that is causing the issue.
12-05-2013 01:07 PM
Yes that is what I meant. If the following steps are executed, then this shows the issue is in the macro.
Have you tried using the following options before you call the macro function?:
options mprint macrogen symbolgen;
If you're able to capture the log, the options should show you more information about the macro code, for example, what values macro variables are resolving to, which should help diagnose issues such as Tom described.
12-05-2013 09:33 AM
What is the test that the macro uses to stop the recursion? You should concentrate on that because it sounds like the recursion is continuing longer than you expected.
A common mistake with macros is to reference a macro variable within a macro without being clear whether the macro variable is local to this instance of the macro, global, or simply "external" to the current instance (either global or locally defined in an outer macro execution scope).
When this gets messed up there are two main risks:
1) It can either not return the value to the caller because the macro is local and its value disappears when the macro execution finishes.
2) It can override the instance of the macro variable a calling macro scope is using and cause an impact on the branching or looping of the calling macro.
Sometimes this is masked in testing because you might have already created a global macro variable with the same name that is used by your macro, but then when you re-run the macro in a new session that global macro variable does not exist and the macro variable becomes local to the macro execution environment.
02-11-2014 02:29 AM
Hi everybody. I am very sorry that I haven't responded to your posts. My problem was depriorized by pre holiday stress, and when I came back from my vacations, the program suddenly ran perfectly. I know this was very bad style. Sorry again.