EG - %abort and abort behavior

[chetan3125]

I am working in SAS EG windowing environment with some large macros which have conditional abort statments.

while running code if it encounters error, all datasets are deleted and log is also cleared. is there any way to keep the datasets and log errors so that I can see what is happening and debug ?

[SASKiwi]

Unfortunately there is currently no SAS option for this but it has been long-requested item in the SASware ballot. The closest option I can think of is SYNTAXCHECK which will force a SAS session to go into syntax check mode - run the code but not process any data. That way your log and datasets will be retained.

[chetan3125]

Thanks for your answer. 
Some progress. Can see the log now but datasets are still cleared.

For ex. Can't see datasets if I run following code. 

options syntaxcheck ;

data c;
 x=1 ;
run;

data d;
set c ;
if x =1 then abort; ;
run;

[ballardw · Accepted solution]

---

@chetan3125 wrote:

Thanks for your answer. 
Some progress. Can see the log now but datasets are still cleared.

For ex. Can't see datasets if I run following code. 

options syntaxcheck ;

data c;
 x=1 ;
run;

data d;
set c ;
if x =1 then abort; ;
run;

---

Some options: Do not write to the Work library. I doubt that anything written to a permanent library is deleted.

Investigate the USER option for a library. Changes how single name data sets are stored to library specified as User but should not delete any. However, since the library is basically as permanent library you are responsible for cleaning it up as needed.

[SASKiwi]

Sorry no data is produced once in syntax check mode, but the log is retained and you can see datasets up to the point the syntax check mode is triggered. That should be good enough for debugging purposes.

Also remove the ABORT as that will override the behaviour of SYNTAXCHECK. 

[ChrisNZ]

SAS really dropped the ball by deciding to do nothing when this has been requested for many years. See here to vote, and for a dirty workaround.

[NicoM]

Do you have access to the code behind these macros? And are the macros compiled using the SASAUTOS path? If so, you could consider:

1. Copying the macro definitions, replacing all %abort and abort-statements with something like %put and put.
2. Compile/run these macros before running the actual code you want to debug.
3. Run the program.

Since the macro are already compiled before step 3, SASAUTOS will no longer look for the actual code, but use your version. This could allow you to debug the problem.

[chetan3125]

Thanks.
These are huge macros uised in my company designed to do multiple tasks.
So it would be unpractical and tedious to locally recompile and replace abort statements.
I wish the macro creators would have made it more debug friendly or SAS developers would have introduced any flexible system option to retain log and datasets.
I really ended up wasting lot of time to debug this though. Feeling helpless about it.

[Tom]

Sounds like the original code was designed for batch/background execute not interactive (or pseudo interactive of EG) mode.

You might make some progress using new SAS sessions to run the macros.  For example you could use SIGNON command of SAS/Connect to open a new session from your program to run the macro.  You could setup that session to not clear the WORK directory when it ends, or perhaps use the USER libref (and now USER option) to have it create one level dataset names into a libref other than WORK.  Then your main session could look into the files left behind by the aborted run.

Of course building that might take more work than just fixing the original macros to be more interactive friendly.

[NicoM]

@chetan3125, not sure how you ended up solving this. Just a thought for a longer term solution hoping you have some ability to influence that.

I am currently working in an environment where we have the following setup:

• Macros and programs only throw errors, they never directly abort.
• Depending on environment (Development, Test, Acceptance vs Production) the option NOERRORABEND or ERRORABEND is set.
• In a Production environment a run with an error will abort immediately as a result of ERRORABEND. Otherwise, during development or when debugging something an error will not result in an abort.
• Setting ERRORABEND / NOERRORABEND is controlled by a system wide "debug mode". Turning on debug mode also makes the logging more verbose by turning on MPRINT, MLOGIC, SYMBOLGEN, FULLSTIMER, etc.
• You can make much more dependent on this debug mode, such as cleaning up of temporary files.

Of course this requires some initial investment, but once you have it set up, it will make your life easier.

[chetan3125]

Thanks for your reply. 
As these macros are set up by my organization and they are many so there is no way for me to modify. 
Currently I am going through tedious task of batch running the code an fix as much as I can and then run again. 

I guess the people in my company who developed these macros did not bother about making users life easy.

[Kurt_Bremser]

Behavior like you describe is typical for batch programs. Anytime something unexpected happens, the program needs to fail in a way that the scheduler can recognize, and at best before faulty data causes the program to destroy something (like updating a production table with faulty data). You also want to fail such a program as early as possible, so the error fixing chain goes to work immediately (no one wants a program to run 3 hours, exit with an ERROR code, and having had the ERROR after 5 minutes of runtime),
So the macros MUST be used as documented, and allow no mistakes. I have created several macros for our production batch codes that act like this.

[NicoM]

@Kurt_Bremser, I fully agree that you want behavior like this for batch programs. That is, aborting on the first error that you encounter. However, like I explain above the macro does not need to do the abort. It can throw an error and setting the option ERRORABEND on the Production environment would be sufficient to achieve what you want. In my opinion a more flexible approach. 

[Kurt_Bremser]

The macro can check for the existence of a typical Enterprise Guide macro variable and change its behavior based on that.

[chetan3125]

Ok. Thanks. I have better perspective now about why they decided to use abort.