LISTSERV at the University of Georgia
Menubar Imagemap
Home Browse Manage Request Manuals Register
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (December 2010, week 2)Back to main SAS-L pageJoin or leave SAS-L (or change settings)ReplyPost a new messageSearchProportional fontNon-proportional font
Date:   Fri, 10 Dec 2010 14:21:34 -0500
Reply-To:   Quentin McMullen <qmcmullen.sas@GMAIL.COM>
Sender:   "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:   Quentin McMullen <qmcmullen.sas@GMAIL.COM>
Subject:   Re: pros and cons of config, autoexec, etc
Comments:   To: Suzanne McCoy <Suzanne.McCoy@catalinamarketing.com>
In-Reply-To:   <4B7D94293459DE418D902EFAF874C4A708664F16C6@STPPEX.catmktg.com>
Content-Type:   text/plain; charset=ISO-8859-1

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 >


Back to: Top of message | Previous page | Main SAS-L page