How to continue running SAS program after %include fails?

[ChrisW75]

Hi,

 I have a master program which sets up a bunch of parameters and libraries, then uses a number of %include steps to run a series of other SAS programs. Each of these SAS programs is a separate test and after running appends output to a table, but they are all essentially independent of each other.

the problem is, if one of those programs has an error, SAS goes into debug mode (sets OBS to 0 just does SYNTAXCHECK from then on) and so will not run any of the subsequent programs.

What I want to know is, is there a way to reset the error condition after each %include, so that if one program fails, the next one can still run.

I saw that there's an "options NOSYNTAXCHECK;" method, but that would cause the failed program to continue running as well, which isn't what I want.

Failing this, I'd need to move each individual program into the batch script instead, and do a bunch of additional logic etc in each SAS program, which I'd rather not do if I can avoid it.

options compress='Y';

%include "setup.sas";

* Logic to check day of week *;

%include "daily_test1.sas";
* If daily_test1.sas fails, daily_test2.sas will run with obs=0 *;
* I want it to run properly, can I reset the error status here? *;
%include "daily_test2.sas";

Cheers

Chris.

[Patrick]

%include allows you to store SAS code in multiple files but using %include runs everything as one big program in one big session. It's logically the same like having all the code together in a single file. If something falls over then the SAS Workspace can get seriously messed up so switching into syntax check mode is the right thing to do and you shouldn't attempt to change this.

Have a look into %sysexec() as this will allow you to have a master program and run your other stuff as child processes - either synchronous or asynchronous. I believe that's what you're really after.

And if using %sysexec(): Don't point to the sas.exe but the sas.sh/sas.bat under your application server context (i.e. C:\SAS\Config\Lev1\SASApp).

[ChrisW75]

Thanks for your response Patrick, I can do it this way, but it would start a new SAS session for each program, and so they would each need to run the setup.sas program independently. That's not such a big deal I guess, but it would mean I'd have to also pass parameters to the child SAS programs from the master SAS program...

Actually, it's probably just 1 parameter that I need to pass, then with setup.sas running in each child program, that'd work, and I can probably make a change to setup.sas to update collect that parameter so it doesn't need to be set up in each program individually. I'll work on that and see how it plays out.

The reason behind my logic here is that I'm an external "consultant" working on a large project, and the code I'm leaving behind will need to be maintained by the locals once I'm gone, potentially for many years, so I'm trying to keep the process of adding new child programs and maintaining the existing ones as simple as possible, while making the process as robust as I can, as these are important processes.

[Patrick]

@ChrisW75 What's the appropriate design depends of course always on the details as well as on the maturity of your client as they must in the end also be able to maintain what you leave behind.

From what you describe I'd consider a design where each program is "self-contained" and can run on it's own. I'd then implement a control table where I list the programs together with possible parameters to be passed in. My master wrapper program would then process this control table and execute the "child" programs in the control table (either as %includes or via %systask).

Such an approach should make it simple to add or remove additional programs and you don't need to change existing production code but you add/remove records from a control table - which in a "big" environment normally allows for a simpler change process and shorter turnaround cycle.

[mkeintz]

If you really don't care about errors in previous %INCLUDEs, you can interleave the %include statements with

     OPTIONS OBS=MAX;

statements.