Thanks Ron,

But I'm not sure I'm following you.

I'm all about batch submissions (well, typically develop in interactive and then batch submit at the end). And understand that if you have project-specific auto-exec and config, you could I guess have these files out in a shared directory along with the other code and data.

But I still don't see the benefit of an autoexec, and don't see the benefit of the config file (other than that there are options that are required to be set when SAS starts). Particularly for the autoexec (which is just a SAS program), I would agree with Jack. As long as I'm creating a file to have a bunch of setup code to be invoked when SAS starts, I might as well %include that program at the beginning of my code. Which would make it explicit to everyone reading the program that start-up code is being executed, and everyone will know where the startup code is. The cost of writing one %include (or a macro call to %setup) seems very low. The benefit being that the program itself contains all of the information on what code is being executed by the job.

--Q.

On Fri, Dec 10, 2010 at 8:51 AM, Fehd, Ronald J. (CDC/OCOO/ITSO) < rjf2@cdc.gov> wrote:

> Quentin: > examine your assumptions: > > * many programmers, on their own desktops, reading data from server > > * many projects, on central server, w/many programmers having rights to > project folders > > the essential Q is: > How do you start SAS? > which means you are opening a SAS session. > > Consider this Q: > How do you submit SAS programs? > > using config+autoexec in a project folder changes assumption from > opening a session > to submitting programs as batch processing > > see also: > Batch Processing under Windows > > TinyUrl: http://tinyurl.com/6zlqoh > > http://www.sascommunity.org/wiki/Batch_processing_under_Windows > > Setting Up Project Config and AutoExec > > TinyUrl: http://tinyurl.com/27oaapt > > http://www.sascommunity.org/wiki/Setting_Up_Project_Config_and_AutoExec > > Ron Fehd the project maven > > > > -----Original Message----- > > From: owner-sas-l@listserv.uga.edu [mailto:owner-sas- > > l@listserv.uga.edu] On Behalf Of Quentin McMullen > > Sent: Thursday, December 09, 2010 4:34 PM > > To: SAS-L@listserv.uga.edu > > Subject: pros and cons of config, autoexec, etc > > > > Hi All, > > > > Recently I've been reading up on how to customize your SAS programming > > environment, using config file, autoexec, etc. Lots of nice SUGI > > papers on > > the topic, by many respected authors. > > > > But the more I read about high degrees of customization (e.g. a > > separate SAS > > icon for each project, pointing to a separate config and autoexec for > > each > > project), the more I wonder how well this would work in an environment > > where > > multiple programmers work together, sharing code. > > > > I've always leaned away from putting more than the minimum in my config > > file > > (recognizing there are some options that must be set here), and I don't > > think I've ever used an autoexec file, because I liked the idea that a > > program could stand on its own. So the person next door could open one > > of > > my programs, run it, and it would work. Similarly, if I inherit code, > > or go > > to a colleague's office to help them work on some code, I expect to be > > able > > the review the program(s) to learn what is going on, without asking > > someone > > to also send me their autoexec and config files so that I can see where > > they > > have defined libraries or setup system options. When I archive a > > project, I > > want the archived code to have as much of the logic and programming > > environment as possible. > > > > Given that we have the gift of the macro language, I would much rather > > see > > standard options, libnames, etc, be created at the top of a program by > > a > > call to %setupProject(project=), than have them created by a > > project-specific autoexec file. With the macro, there is an indication > > in > > the code that some setup code is being run, and I can look at the macro > > definition or log to see what is happening. Similarly, I could see > > %term() > > instead of the new (?) -termstmt (or whatever it is where you can > > specify > > the converse of an autoexec). I recognize some people argue against > > the > > macro language (too complex, hides code) using a similar argument as > > I'm > > using against the autoexec and config.sas, so perhaps I'm being > > hypocritical > > in my critique of these constructs. > > > > Wanted to ask what other folks think about customizing their config and > > autoexec files (rather than e.g. using a macro or even keyboard macro > > to set > > default options/libraries/etc), particularly folks who work in > > environments > > with multiple programmers sharing code. Has this been useful, or has > > it > > caused problems? Have you ever been in the position of receiving code > > from > > a colleague and not being able to successfully run it because it relied > > on a > > config file or autoexec that was inaccessible to you? > > > > Kind Regards, > > --Quentin >