Thanks Suzanne,

I have not worked in heavily regulated environments, but would image a %setup macro (with parameter specifying dev/test/prod) could be useful here, and to me is more clear/documented than relying on an autoexec file. So I can't see the benefit of running code in a config or autoexec if it could run in the main session.

If a group does take the approch of having project-specific config and autoexec files, then I would assume the requirement is that everyone working on a project use the same shared config and autoexec files (when they are working on that project), correct? So you need to have 1 person managing these files at the project level?

I guess what I'm really asking is that would you agree that if you had a group of programmers, and each had their own personal autoexec and config (setting libnames, global options, etc), or worse-yet each had their own suite of project-specific autoexec and config files, this could be a recipe for disaster if they should ever attempt to run each other's code?

Which would suggest that for the programmer who works in a group, the autoexec and config should not be used for personal customization (beyond roughly non-functional settings such as -nosplash). Agree?

--Q;

On Fri, Dec 10, 2010 at 8:38 AM, Suzanne McCoy < Suzanne.McCoy@catalinamarketing.com> wrote:

> %include is great as long as the path isn't hard-coded in the statement. > If it is hard-coded then you have to modify the code before promoting it to > another environment(dev/test/prod). Changing code after it is checked into > source control and before it can be deployed to another environment violates > change control standards in a SOX auditable environment. > > -----Original Message----- > From: Jack F. Hamilton [mailto:jfh@alumni.stanford.org] > Sent: Friday, December 10, 2010 1:12 AM > To: Suzanne McCoy > Cc: SAS-L@LISTSERV.UGA.EDU > Subject: Re: [SAS-L] pros and cons of config, autoexec, etc > > I agree with those benefits, but I would use a %INCLUDE instead of putting > the central point of control into an autoexec. You get the benefits you > mention below, and in addition you can look at the code and tell where the > siurce of the code can be found; you can't do that with an autoexec. > > > On Dec 9, 2010, at 19:49 , Suzanne McCoy wrote: > > > Quentin, > > > > I like to use the autoexec for a specific application or environment > because it gives you one central point of control and only one place that > needs to be updated when moving from dev to test to prod. This makes change > control boards very happy because source code can be deployed directly from > the source control system without having to be modified for environment > differences. Everything assigned in the autoexec is global to every macro > executed so when you need something that you know was assigned in the > autoexec it is as simple as calling the applicable macro variable. For > example, %let mydata=libname mydata '~/sas_data'; *assigned in the > autoexec; Macro downstream needs to use the mydata library simply has > &mydata; within the macro code. > > > > The autoexec method also works great for masking database login > credentials from the users if you tie the autoexec to a workspace and/or > stored process server via metadata. This is great when using application > ids instead of individual user ids for database connections, expecially > default readonly connections. It also controls the environment when you > have multiple developers working on the same application or project so you > know they are all coding to the same standard connections, library names, > format libraries, custom macros, etc. > > > > Another benefit to using autoexecs happens with scheduled jobs. If you > scan the jil (AutoSys terminology)/scheduler command lines for instances of > a specific autoexec call, you can quickly determine any and all jobs that > are a part of that particular job stream/application data flow. > > > > I must have been working in production environments for too long! > > > > Hope this helps, > > Suzanne > > ________________________________________ > > From: SAS(r) Discussion [SAS-L@LISTSERV.UGA.EDU] On Behalf Of Quentin > McMullen [qmcmullen.sas@GMAIL.COM] > > Sent: Thursday, December 09, 2010 4:33 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 >