Jay, As described in my first post, I'm trying to set up a process where when a user submits a stored process to generate a report, the stored process will scan the SAS log for any problematic messages (errors, warnings, or bad notes), and if there are bad messages, will return those to the user, instead of the report. So it's roughly: 1. Run a report and write the report to a file (html/pdf/rtf/SASREPORT), but do NOT display the results to the user. 2. Scan the log from running the report. 3. If the log is clean, I will want to stream the report to user. If the log has errors, I will display an error message to the user. [Another option I played with was using ods document as a tool to hold the report and later replay it.] I'm new to working on stored processes/application development for use by non-programmers. As a SAS programmer, I always run a %logcheck on my log before trusting (even looking at) results. So I feel like as a developer, I should give users the same level of error-detection. Of course ideally code will trap errors before they are encountered. But especially in the BI world, where the person who programs a stored procedure may not have any control over the live source databases that are inputs to the procedure, it seems worth checking the log, rather than assuming that if SAS returned a result, everything must have run fine. But I'd be happy to hear thoughts from you or others on this sort of approach. I've tried to start threads here and on SAS-L, with little interest generated. So maybe I'm off-base. But in my gut, I feel like it would be close to negligence to release an application that used SAS but completely ignored the SAS log.... --Q.
... View more