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?
On Fri, Dec 10, 2010 at 8:38 AM, Suzanne McCoy <
> %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:firstname.lastname@example.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
> > the topic, by many respected authors.
> > But the more I read about high degrees of customization (e.g. a separate
> > icon for each project, pointing to a separate config and autoexec for
> > project), the more I wonder how well this would work in an environment
> > multiple programmers work together, sharing code.
> > I've always leaned away from putting more than the minimum in my config
> > (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
> > my programs, run it, and it would work. Similarly, if I inherit code, or
> > to a colleague's office to help them work on some code, I expect to be
> > the review the program(s) to learn what is going on, without asking
> > to also send me their autoexec and config files so that I can see where
> > 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
> > 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
> > 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
> > 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
> > 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
> > default options/libraries/etc), particularly folks who work in
> > with multiple programmers sharing code. Has this been useful, or has it
> > caused problems? Have you ever been in the position of receiving code
> > 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