What do you use for error checking in EG?

[mdavidson]

It's been a few years since I've really looked into error checking for production SAS EG jobs. What I've done in the past is write the SAS logs to a folder, then import the log and scan the text of the log for errors and warnings. My company is currently on SAS EG 7.15 and I was wondering if there was another way to check a log for errors. Is there anything built into the EG tool that will do this or is the log scan process I described the best way to accomplish this? Perhaps the Project Log?

The idea would be to notify someone if a job fails.

[Quentin]

I use EG for development only, so I don't have production EG jobs.  That said, I often do log scanning in EG just as you discuss, because it allows me to search for errors, warnings, and NOTEs that I think should be unallowed.  If you have a good log scanning macro, you can use it at the end of a PC SAS job, batch job, EG job, DI studio job, stored process, etc etc. It can send an email if it finds problem.

That said, EG does have a nice built-in log filtering window, which makes it easy to check for warnings and errors ad-hoc.

There are lots of user group papers on log scanning (search lexjansen.com) My favorite approach is still http://www.nesug.org/proceedings/nesug01/cc/cc4008.pdf.

[SASKiwi]

Personally I'm not a fan of log-scanning. I find the log summary in EG is perfect for my needs. At a glance it will tell you how many errors, warnings and notes are in your job. If there are errors then I use the Cntrl E function in the log to jump to each of the errors.

We also run a lot of batch jobs for production purposes and there we rely on the sending of emails if there is an error in the job along with automatically switching to syntax check mode using the SYNTAXCHECK option.

Like @Quentin, EG is primarily used for development and ad-hoc analytics and we use batch jobs exclusively for production.

[Kurt_Bremser]

"production SAS EG jobs" is some kind of oxymoron. EG is a nice development environment, but, being desktop-only, not suited for a production environment. Production jobs should always run in batch on the server under control of a solid scheduling environment, either that supplied by SAS, or the one already in use in your organization.

With batch jobs, you can include all kinds of error checking in the shell script that is used by the scheduler. And since SAS already provides proper return codes for WARNINGs (1) and ERRORs (2), the scheduler will easily flag the run as unsuccessful.