Date: Fri, 10 Dec 2010 15:32:26 -0500
Reply-To: Suzanne McCoy <Suzanne.McCoy@CATALINAMARKETING.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Suzanne McCoy <Suzanne.McCoy@CATALINAMARKETING.COM>
Subject: Re: pros and cons of config, autoexec, etc
In-Reply-To: <AANLkTi=FHP78CPhShZSenrr4J9afsfTOCW3tw8VOY2+v@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Good questions Quentin!
q: 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?
a: Yes and Yes - Especially in team development environments, whether interactive applications, batch run streams, or Stored Processes running from web interfaces. The project lead/environment manager can coordinate all the details of environment changes with the sysadmin and dba teams then roll the changes out in the autoexec without impacting development efforts. A heads-up communication and an 'environment update complete' communication usually suffice for dev team communications. Environment changes are easy to get through a change control board if the only piece of code impacted is the autoexec ;-)
q: 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?
a: Yikes, run away, run away farther.... This scenario is definitely what I would consider worst case. If every programmer is allowed to do their own thing you will never have standardized code. This makes peer review and user acceptance testing very frustrating and the documentation trail can become a total nightmare.
q: 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?
a: Agree. An added bene is that they have to talk to each other about the environment and how any changes they make could impact other programmers. Yeah for improved communication!
In my 20+ years as a SAS consultant and Alliance Partner I have seen many many production environments in heavily regulated industries. The approach has worked well for me and my teams in nuclear power, energy trading, banking, healthcare, pharmaceutical and manufacturing industries. Is it needed in a strictly adhoc environment or strictly for reports? Probably not because SOX audits don't typically happen at this level.
Each situation has it's own needs so one methodology doesn't fit all. The 'productionize the environment' methodology is habit with me now and my clients have appreciated the structured methodology for execution environment control.
Happy coding,
Suzanne
From: Quentin McMullen [mailto:qmcmullen.sas@gmail.com]
Sent: Friday, December 10, 2010 2:22 PM
To: Suzanne McCoy
Cc: SAS-L@listserv.uga.edu
Subject: Re: [SAS-L] pros and cons of config, autoexec, etc
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<mailto: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<mailto:jfh@alumni.stanford.org>]
Sent: Friday, December 10, 2010 1:12 AM
To: Suzanne McCoy
Cc: SAS-L@LISTSERV.UGA.EDU<mailto: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<mailto:SAS-L@LISTSERV.UGA.EDU>] On Behalf Of Quentin McMullen [qmcmullen.sas@GMAIL.COM<mailto:qmcmullen.sas@GMAIL.COM>]
> Sent: Thursday, December 09, 2010 4:33 PM
> To: SAS-L@LISTSERV.UGA.EDU<mailto: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
| 
