<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Keeping the Log Window Clear in ODS and Base Reporting</title>
    <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4197#M1735</link>
    <description>Peter's advice is, as always, very good.  My preference is to retain a single CONFIG file because these are modified by versions of SAS, or even reinstallations on other PCs.  I use alternative autoexec files for different purposes, autoexec for generic use, autobatch for generic batch etc.&lt;BR /&gt;
&lt;BR /&gt;
However, writing logs off to a file where they are never read because they are too big is often used as a "cop out", and if you redirect your log, then I believe you need to make sure that the contents are still analysed in a timely manner.  Very often I have seen logs redirected, never reviewed and a long period of incorrect information pass before someone goes to investigate some anomaly in the report.&lt;BR /&gt;
&lt;BR /&gt;
It is better than turning off Notes with the NoNotes option, but not by much.  I take an approach like the following.  (I am writing this from memory, so it isn't tested.)&lt;BR /&gt;
&lt;BR /&gt;
FileName  INCLLOG  Temp;&lt;BR /&gt;
&lt;BR /&gt;
Proc PrintTo  Log = INCLLOG;&lt;BR /&gt;
Run;&lt;BR /&gt;
&lt;BR /&gt;
&lt;STATEMENTS creating="" lots="" of="" log="" messages=""&gt;&lt;BR /&gt;
&lt;BR /&gt;
Proc PrintTo  Log = LOG;&lt;BR /&gt;
Run;&lt;BR /&gt;
&lt;BR /&gt;
Data _NULL_;&lt;BR /&gt;
  InFile  INCLLOG  TruncOver;&lt;BR /&gt;
  Input  STRING $Char132.;&lt;BR /&gt;
  If STRING Eq: "ERROR"  Then  Put  STRING;&lt;BR /&gt;
  Else If STRING Eq: "WARNING"  Then  Put  STRING;&lt;BR /&gt;
Run;&lt;BR /&gt;
&lt;BR /&gt;
FileName  INCLLOG  Clear;&lt;BR /&gt;
&lt;BR /&gt;
I add other statements to the log to select NOTES that are not expected by scanning for  STRING Eq: "NOTES"  and not containing key phrases for data set creation and so on.&lt;BR /&gt;
&lt;BR /&gt;
Then I have a single log that tells me things I need to know, and when I have to process 600 text files as I did over the weekend I can surface the exceptions to my log and refine the log parse code and the exception reporting.&lt;BR /&gt;
&lt;BR /&gt;
A block of code like this can then be held as a standard piece for inclusion in later programs of this type.&lt;BR /&gt;
&lt;BR /&gt;
Kind regards&lt;BR /&gt;
&lt;BR /&gt;
David&lt;/STATEMENTS&gt;</description>
    <pubDate>Mon, 20 Aug 2007 23:36:39 GMT</pubDate>
    <dc:creator>deleted_user</dc:creator>
    <dc:date>2007-08-20T23:36:39Z</dc:date>
    <item>
      <title>Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4187#M1725</link>
      <description>Hi All,&lt;BR /&gt;
&lt;BR /&gt;
I have an odd query that I hope you can help with. I have a fairly large file that I'm processing, my code is fairly straightforward and runs quickly but there are lots of iterations. For example, I'm currently running a test file with 24,130 iterations and I will later have to execute the code on a file with c.195,000.&lt;BR /&gt;
&lt;BR /&gt;
My problem is that after around 900 iterations the Log window becomes full and needs to be manually cleared. The program is calling a macro so there's no lines of code in the Log window, just notes but there's so many lines of notes that it's filling up. &lt;BR /&gt;
&lt;BR /&gt;
Is there any way to prevent the notes appearing or to automatically clear the Log window so that the program can be left to run by itself?&lt;BR /&gt;
&lt;BR /&gt;
Many thanks in advance.</description>
      <pubDate>Tue, 14 Aug 2007 09:32:06 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4187#M1725</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-14T09:32:06Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4188#M1726</link>
      <description>You can try using Proc Printto to output the log window contents to an external file which can be deleted later .</description>
      <pubDate>Tue, 14 Aug 2007 10:40:34 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4188#M1726</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-14T10:40:34Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4189#M1727</link>
      <description>Why not run your program in batch mode? The log will be written to a file and the only limitation on its size will be how much disk space you have. This way, if something goes wrong, you'll have the log to refer to. If nothing goes wrong, delete the log.</description>
      <pubDate>Tue, 14 Aug 2007 12:25:47 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4189#M1727</guid>
      <dc:creator>Tim_SAS</dc:creator>
      <dc:date>2007-08-14T12:25:47Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4190#M1728</link>
      <description>I hadn't thought of that, although to be fair, I've never actually run anything in Batch mode before.&lt;BR /&gt;
&lt;BR /&gt;
I'm using v.9.1.3 sp3 for Windows, how do I go about running my program in batch mode?</description>
      <pubDate>Tue, 14 Aug 2007 13:36:02 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4190#M1728</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-14T13:36:02Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4191#M1729</link>
      <description>The simplest way to run a batch job on Windows is to open a command prompt window or the Start-&amp;gt;Run dialog box and enter "sas -sysin mypgm.sas". You can also drop the icon for your program file onto the SAS icon.&lt;BR /&gt;
&lt;BR /&gt;
Complete instructions for running SAS in batch on Windows are available in the &lt;I&gt;SAS Companion for Microsoft Windows&lt;/I&gt;. If you don't have a copy, all the doc for SAS 9.1.3 is available here: &lt;A href="http://support.sas.com/onlinedoc/913/docMainpage.jsp"&gt;http://support.sas.com/onlinedoc/913/docMainpage.jsp&lt;/A&gt;.</description>
      <pubDate>Tue, 14 Aug 2007 14:17:55 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4191#M1729</guid>
      <dc:creator>Tim_SAS</dc:creator>
      <dc:date>2007-08-14T14:17:55Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4192#M1730</link>
      <description>Yet another avenue to consider is the use of 'OPTIONS NONOTES;'. Obviously you wouldn't want this set when testing, but you shouldn't really be testing on this volume of data anyway.</description>
      <pubDate>Wed, 15 Aug 2007 13:03:57 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4192#M1730</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-15T13:03:57Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4193#M1731</link>
      <description>Here is an example of code that I put in a batch file that allows a little more control over your environment and output.  Please note, the line that invokes SAS shows up as about three lines in the post.&lt;BR /&gt;
&lt;BR /&gt;
@echo off&lt;BR /&gt;
time /T&lt;BR /&gt;
if x%1==x? goto help&lt;BR /&gt;
if /i x%1==xhelp goto help&lt;BR /&gt;
&lt;BR /&gt;
REM figure out what last month (year and month) are&lt;BR /&gt;
setlocal&lt;BR /&gt;
for /f "usebackq tokens=1,2,3,4 delims=/ " %%i in (`date /t`) do set CCYYMM=%%l%%j&lt;BR /&gt;
set /a xx=%CCYYMM% "%%" 100&lt;BR /&gt;
if %xx% EQU 1 (set /a XCCYYMM=%CCYYMM% - 89) else set /a XCCYYMM=%CCYYMM% - 1&lt;BR /&gt;
@echo %XCCYYMM%&lt;BR /&gt;
&lt;BR /&gt;
"C:\Program Files\SAS\SAS 9.1\sas.exe" "H:\My_Documents\advoss\My_Master.sas" -autoexec h:\sas\autoexec.sas -sasuser h:\sas\sasuser -config "C:\Program Files\SAS\SAS 9.1\sasv9.cfg" -log "C:\Temp\My_Master_%XCCYYMM%.log"  -noprint -nosplash&lt;BR /&gt;
start notepad "C:\Temp\My_Master_%XCCYYMM%.log"&lt;BR /&gt;
goto exit&lt;BR /&gt;
:help&lt;BR /&gt;
echo %0 will run My_Master SAS report&lt;BR /&gt;
echo Invoke as %0&lt;BR /&gt;
goto exit&lt;BR /&gt;
:exit&lt;BR /&gt;
time /T&lt;BR /&gt;
echo on</description>
      <pubDate>Wed, 15 Aug 2007 13:29:22 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4193#M1731</guid>
      <dc:creator>advoss</dc:creator>
      <dc:date>2007-08-15T13:29:22Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4194#M1732</link>
      <description>Cheers All,&lt;BR /&gt;
&lt;BR /&gt;
Using PRINTTO seems to have done the trick. Excellent stuff.</description>
      <pubDate>Fri, 17 Aug 2007 07:07:47 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4194#M1732</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-17T07:07:47Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4195#M1733</link>
      <description>Hi&lt;BR /&gt;
&lt;BR /&gt;
when it gets too large or unwieldy to maintain, you might like to reduce your command line that starts SAS by removing all the extra options (apart from -sysin) into a "batch" sasv9.cfg config file in folder of programs to be run in batch. That might reduce the command line to just&lt;BR /&gt;
&lt;BR /&gt;
"C:\Program Files\SAS\SAS 9.1\sas.exe" "H:\My_Documents\advoss\My_Master.sas" &lt;BR /&gt;
&lt;BR /&gt;
In that "batch" sasv9.cfg config file  [pre]&lt;BR /&gt;
-autoexec h:\sas\autoexec.sas &lt;BR /&gt;
-sasuser h:\sas\sasuser &lt;BR /&gt;
-RsasUser&lt;BR /&gt;
-log "C:\Temp\My_Master_%XCCYYMM%.log" &lt;BR /&gt;
-nosplash&lt;BR /&gt;
-noterminal&lt;BR /&gt;
-batch&lt;BR /&gt;
[/pre]&lt;BR /&gt;
&lt;BR /&gt;
when SAS starts, it will use the sasv9.cfg file next to the sas.exe, and one (when present) in the folder of the -sysin file. &lt;BR /&gt;
You might also like the features of the -logparm option when running SAS in batch, it enables some #directives to put date and time into the log file name. &lt;BR /&gt;
However, I prefer to use the name of the invoked program and it's not obvious how in this context.&lt;BR /&gt;
&lt;BR /&gt;
PeterC</description>
      <pubDate>Fri, 17 Aug 2007 13:22:28 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4195#M1733</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-17T13:22:28Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4196#M1734</link>
      <description>To clear the log at each iteration use something like:&lt;BR /&gt;
   dm log 'clear';</description>
      <pubDate>Fri, 17 Aug 2007 22:35:17 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4196#M1734</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-17T22:35:17Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4197#M1735</link>
      <description>Peter's advice is, as always, very good.  My preference is to retain a single CONFIG file because these are modified by versions of SAS, or even reinstallations on other PCs.  I use alternative autoexec files for different purposes, autoexec for generic use, autobatch for generic batch etc.&lt;BR /&gt;
&lt;BR /&gt;
However, writing logs off to a file where they are never read because they are too big is often used as a "cop out", and if you redirect your log, then I believe you need to make sure that the contents are still analysed in a timely manner.  Very often I have seen logs redirected, never reviewed and a long period of incorrect information pass before someone goes to investigate some anomaly in the report.&lt;BR /&gt;
&lt;BR /&gt;
It is better than turning off Notes with the NoNotes option, but not by much.  I take an approach like the following.  (I am writing this from memory, so it isn't tested.)&lt;BR /&gt;
&lt;BR /&gt;
FileName  INCLLOG  Temp;&lt;BR /&gt;
&lt;BR /&gt;
Proc PrintTo  Log = INCLLOG;&lt;BR /&gt;
Run;&lt;BR /&gt;
&lt;BR /&gt;
&lt;STATEMENTS creating="" lots="" of="" log="" messages=""&gt;&lt;BR /&gt;
&lt;BR /&gt;
Proc PrintTo  Log = LOG;&lt;BR /&gt;
Run;&lt;BR /&gt;
&lt;BR /&gt;
Data _NULL_;&lt;BR /&gt;
  InFile  INCLLOG  TruncOver;&lt;BR /&gt;
  Input  STRING $Char132.;&lt;BR /&gt;
  If STRING Eq: "ERROR"  Then  Put  STRING;&lt;BR /&gt;
  Else If STRING Eq: "WARNING"  Then  Put  STRING;&lt;BR /&gt;
Run;&lt;BR /&gt;
&lt;BR /&gt;
FileName  INCLLOG  Clear;&lt;BR /&gt;
&lt;BR /&gt;
I add other statements to the log to select NOTES that are not expected by scanning for  STRING Eq: "NOTES"  and not containing key phrases for data set creation and so on.&lt;BR /&gt;
&lt;BR /&gt;
Then I have a single log that tells me things I need to know, and when I have to process 600 text files as I did over the weekend I can surface the exceptions to my log and refine the log parse code and the exception reporting.&lt;BR /&gt;
&lt;BR /&gt;
A block of code like this can then be held as a standard piece for inclusion in later programs of this type.&lt;BR /&gt;
&lt;BR /&gt;
Kind regards&lt;BR /&gt;
&lt;BR /&gt;
David&lt;/STATEMENTS&gt;</description>
      <pubDate>Mon, 20 Aug 2007 23:36:39 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4197#M1735</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-20T23:36:39Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4198#M1736</link>
      <description>Realizing my specification of important NOTES messages may be vague, very good information is available from the SUGI paper presented by Delwiche and Slaughter entitled "Errors, Warnings and Notes: Oh my".&lt;BR /&gt;
&lt;BR /&gt;
It is available on the SAS support site.&lt;BR /&gt;
&lt;BR /&gt;
Kind regards&lt;BR /&gt;
&lt;BR /&gt;
David</description>
      <pubDate>Tue, 21 Aug 2007 03:46:59 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4198#M1736</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-21T03:46:59Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4199#M1737</link>
      <description>I don't like disagreeing with &lt;U&gt;dkvj&lt;/U&gt; but if it appears I am on this occasion, it may only be caused by misunderstanding.&lt;BR /&gt;
I recommend &lt;B&gt;never&lt;/B&gt; updating the installed SAS configuration file. The administration or configuration of SAS System installation, provides features that support separating user- and application- specific options from the "platform-install" features. This separation is there by default. It is just unusual to find it because most expertise in this area developed before the "separation" became available in SAS8. In full support of customer legacy, most shrink-wrapped SAS installations invoke a single specific configuration file. Despite this, the separation can still be implemented with a feature demonstrated at the first SAS Global Forum in a paper entitled "Easy SAS® Session Customization" available at &lt;A href="http://www2.sas.com/proceedings/forum2007/051-2007.pdf" target="_blank"&gt;http://www2.sas.com/proceedings/forum2007/051-2007.pdf&lt;/A&gt;&lt;BR /&gt;
&lt;BR /&gt;
David, you point out the reason for not using a single config file. That requires you to modify the SAS installed config file or even a copy of that, which may well be modified on the next update of the SAS System. My proposal leaves that file alone, keeping only customer options in a separate file.&lt;BR /&gt;
&lt;BR /&gt;
I hope this "tirade" is helpful.&lt;BR /&gt;
&lt;BR /&gt;
PeterC</description>
      <pubDate>Tue, 21 Aug 2007 08:06:42 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4199#M1737</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-21T08:06:42Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4200#M1738</link>
      <description>In all the years we have known each other, I don't think we have ever disagreed Peter, just debated alternative points of view.  I suspect the same is true now.  I read your advice as suggesting the use of a config file specific to a purpose and I replied "retain a single CONFIG file because these are modified by versions of SAS, or even reinstallations on other PCs. I use alternative autoexec files for different purposes, autoexec for generic use, autobatch for generic batch etc.".  So it seems we have the same reticence about changing the config.&lt;BR /&gt;
&lt;BR /&gt;
However, I do change it for each installation, and all my version icons have paths to customised configs where I have set up my preferences for email, MsgLevel, FmtSearch and so on.  I must also confess I modify below the line as well, by extending the Macro search path to include the macro libraries I have created for my or for group use.  I then deploy the changed file to a SASWORK directory with other files available to one or all versions of SAS running on the machine.&lt;BR /&gt;
&lt;BR /&gt;
Nonetheless, I define this change as "A THING TO DO VERY CAREFULLY" and to always retain a backup in case you overwrite the original.  I noted for instance while updating a reinstall that the META-ID had changed from one install to another, so I carefully grafted my extra pieces on the new config and tested it.&lt;BR /&gt;
&lt;BR /&gt;
However, please note I said that it is a config for a version, not for a task.  I took your reply as suggesting configs could be at task level, and if I understood that correctly, then I disagree with that.  I feel you might create AUTOEXEC, AUTOEXAF, AUTOBTCH and so on for different ways of using SAS and include application specific statements such as libraries and execution statements in the appropriate autoexec.  I don't extend MgLevel and the other config changes into the autoexec because I think it makes them unweildy, and some of the changes I make are SAS invocation options, which can't be specified after the config.&lt;BR /&gt;
&lt;BR /&gt;
As far as possible, IMHO, a config should contain those commands needed for every execution of that version of SAS, and adding options above the line should usually be safe.  Then you do only have one config file for a SAS version.&lt;BR /&gt;
&lt;BR /&gt;
Kind regards&lt;BR /&gt;
&lt;BR /&gt;
David</description>
      <pubDate>Wed, 22 Aug 2007 03:48:33 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4200#M1738</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-22T03:48:33Z</dc:date>
    </item>
    <item>
      <title>Re: Keeping the Log Window Clear</title>
      <link>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4201#M1739</link>
      <description>my proposal is at application or project level, rather than by task. &lt;BR /&gt;
The translation from these words to implementation: &lt;BR /&gt;
a task means a .SAS program;&lt;BR /&gt;
for a project/application, the SAS programs (tasks) to be invoked, reside in the same folder. &lt;BR /&gt;
Also in that folder is a sasv9.cfg file. It is in this file that application-specific options are defined. &lt;BR /&gt;
My proposal is to have an environment variable which suggests looking (also) in the "current folder" for a config file. &lt;BR /&gt;
&lt;BR /&gt;
In this way the config file created as SAS is installed, can remain "untouched". &lt;BR /&gt;
All your project-based options are stored in the project-folder. &lt;BR /&gt;
In this way you can provide project specific information like &lt;BR /&gt;
. format search paths, &lt;BR /&gt;
. additions to the sasautos  (discover SAS options -insert and -append)&lt;BR /&gt;
. noOVP&lt;BR /&gt;
. noterminal   when appropriate&lt;BR /&gt;
. sasuser pointer &lt;BR /&gt;
. rSASuser (allowing share of sasuser features for concurrent batch work)&lt;BR /&gt;
. set environment variables   to use as libnames and filenames &lt;BR /&gt;
. awsTitle   to name the task to windows (something similar on unix?)&lt;BR /&gt;
. lognote1  to provide support contact info in the saslog  for maintainers&lt;BR /&gt;
. termstmt to invoke program to send email indicating completion&lt;BR /&gt;
. config  to call another config file, e.g. for company-wide common options&lt;BR /&gt;
&lt;BR /&gt;
I'm sure we can add to this list of project-specific options.&lt;BR /&gt;
&lt;BR /&gt;
&lt;BR /&gt;
By making the environment variable pointer to a config file, non path-specific, the server can support multiple projects, each with its own special features, defined in the project-specific folder.&lt;BR /&gt;
&lt;BR /&gt;
The same technique works well for a user environment. The "current folder" holds a config file with options specific to SAS programs in that folder and/or specific to the user's preferences. &lt;BR /&gt;
&lt;BR /&gt;
Having a place for project-specific options, I try to put as little as possible in the autoexec.sas file. My preference/recommendation would be to use the -NOautoexec option for batch work.  &lt;BR /&gt;
&lt;BR /&gt;
Of course the invocation of a SAS session has an even more sophisticated routine for obtaining configuration files when none are defined on the sas.exe command line. However, I think you'll find my proposal is entirely consistent with that scenario.&lt;BR /&gt;
&lt;BR /&gt;
Regards to the Forum&lt;BR /&gt;
&lt;BR /&gt;
PeterC</description>
      <pubDate>Wed, 22 Aug 2007 10:03:56 GMT</pubDate>
      <guid>https://communities.sas.com/t5/ODS-and-Base-Reporting/Keeping-the-Log-Window-Clear/m-p/4201#M1739</guid>
      <dc:creator>deleted_user</dc:creator>
      <dc:date>2007-08-22T10:03:56Z</dc:date>
    </item>
  </channel>
</rss>

