While You Were Sleeping… SAS Is Hard At Work Andrea Wainwright- Zimmerman

Overview Bomb-Proof The Code Handle Any Errors Store The Log Confirm Success Determine Possible Scenarios Schedule Code To Run

Bomb-Proof The Code Any SAS code that you plan to schedule needs to be as error free as possible. – No syntax errors – Run many time through all possible scenarios without errors or issues

Handle Any Errors No matter how well written the code, there still may be unavoidable errors. Where in the code can they happen? What methods can be used to catch these errors? How should they be handled? Examples: – Bad data provided – Database is down – Password has expired

Handle Any Errors - Bad Data Determine what types of bad data are possible. Code logic to catch such issues. Send notification of the data issue. – Both to you and the data provider if possible – Provide noticeable, clear subject line – Determine what useful details to include in the body Skip over sections of code that shouldn’t (or won’t) run on the bad data. – GOTO and LINK are helpful – If no more code is needed ENDSAS is an option

Handle Any Errors - Database Issue To capture an issue with the connection to a database, use the following %check libname macro immediately after the libname statement %macro check_libname; %if &sysdbrc ne 0 %then %do; %send_ (subj=LIBNAME FAIL,text=%superq(sysdbmsg)) endsas; %end; %mend;

Store The Log No matter how well you write the code, and no matter how well you plan for all possible issues, there still is a chance of failure. In these cases you’ll need to review the log to see what happened. proc printto log="C:\My Documents\ project\log_&sysdate..log" new; run;

Confirm Successes At certain points in the process you will want to be notified of successes. If there is a macro that loops s notifying you of the success of step X of Y can be helpful in catching anomalies. – For example, if you get a message about 2 of 2 but never got a message about 1 of 2, you’ll want to review the log.

Confirm Successes - Send_ %macro send_ ( to= &my_e_mail, from=&my_e_mail, subj=, cc= &my_e_mail, text= ); filename sendmail ; data _null_; file sendmail; put '!EM_TO!' "&to"; put '!EM_FROM!' "&from"; put '!EM_CC!' "&cc"; put '!EM_SUBJECT!' "&subj"; body="&text"; put body; run; %mend;

Confirm Successes - Outlook Issues Outlook will want to know if you really want the sent. This defeats the purpose of having the code run overnight and report on it’s progress. There are a few options to handles this.

Confirm Successes - Outlook Issues This is an optional Outlook behavior that can be turned off if you have the permissions or can influence those that do. There are free programs available on-line that will simply “Click Yes” for you that you can install if you have the permissions. You can edit the SAS CFG file to use SMTP instead. See for details.

Determine Possible Scenarios Will the code always produce something? Will there always be something the code needs to do? Are there iterative loops (macros) that notification would be beneficial for? Don’t leave yourself wondering what happened.

Determine Possible Scenarios

Schedule Code To Run Does this code need to run on a repeating schedule or do you just want it to run after hours? To run SAS after hours, use the SLEEP function. For repeating running, each environment has it’s own scheduling tool. For Windows, there is the Scheduled Task.

Schedule Code To Run - Sleep To SLEEP till a specific start time: data _null_; now=datetime(); start=’25JUN2010:19:00:00'dt; wait_sec=start-now; zzz=sleep(wait_sec); run;

Schedule Code To Run - Sleep To SLEEP for a set amount of time: data _null_; hour=5; min=30; wait_sec=(60*60*hour)+(60*min); zzz=sleep(wait_sec); run;

Questions? Andrea Wainwright-Zimmerman