As I was preparing for a customer introduction to using SAS Enterprise Guide, I asked them to send me all the questions they had regarding the Enterprise Guide usage. It turned out that many of their questions can be answered with a single feature called an autoexec, or automatically executable file.
Handpicked Related Content: Creating reports in style with SAS Enterprise GuideAn autoexec file generally contains a mini SAS program that is run when the SAS System starts up. Autoexec files can help SAS developers eliminate many routine actions and repetitive tasks such as assigning libraries and SAS options, particularly when these routine actions set up an environment that is used from project to project and from program to program. They prove to be very handy whether you’re using SAS in either an interactive mode or in a batch mode.
Compared to the classical SAS programming, where the autoexec file executes on a startup of a SAS session, SAS Enterprise Guide provides more flexibility in determining when the code is run. You can customize the autoexec start-up sequence in SAS Enterprise Guide by using either user-specific autoexec or project-specific autoexec, or both.
If you are a SAS developer working solo on a proof of concept, you would definitely want a user-specific autoexec. However, if you work on a larger project as a team member and want to set up a common environment across the project then project-specific autoexec is the way to go. You can even combine both autoexecs, user-specific and project-specific, to get the best of each – access to the common project resources and yet have some convenience of your own personal environment, for concept testing, for example. Just don’t forget to remove your user-specific autoexec when you release your project back to the team.
Preparing the autoexec file
The first step is to prepare the code for your autoexec file. Autoexec files are routinely used to set up SAS data and format libraries, macro variables, SAS system options, etc. Here is a typical autoexec file:
%let saspath = D:\SAS\Lev1\SASApp\SASEnvironment;
%let projpath = D:\Projects\proj1;
/* SAS Format library */
libname fmtlib "&saspath\SASFormats";
option
fmtsearch=(fmtlib)
nodate
mautosource sasautos=('!SASROOT\sasautos', "&saspath\SASMacro", "&projpath\code")
;
/* Input data library */
libname dwlib ODBC datasrc=PROD_DTA schema=DBO user=Sasread PASSWORD="{sas001}T8teQzIkMq==" access=readonly;
/* Output data library */
libname rptlib BASE "&projpath\outdata";
/* Report folder */
filename htmlout "&projpath\reports";
For more information about how to create and use autoexec files, see the SAS® 9.4 Companion for Windows or SAS® 9.4 Companion for UNIX Environments.
Setting up a user-specific autoexec
In SAS Enterprise Guide, autoexec code can be set up to execute every time a connection to a workspace server is made:
- From the top Menu bar: Tools -> Options ->SAS Programs
- In the Additional SAS code section, select the checkbox for Submit SAS code when server is connected
- To the right of this checkbox, click the Edit button and enter the code to be run whenever you connect to a workspace server. You can also reference an external SAS autoexec file, such as %include ‘/path/autoexec.sas’
- Click the Save button to close the Edit window
- Click the OK button to save and close the Options window
As you can see, there are two other options available to execute Additional SAS Code:
- Insert custom SAS code before submitted code
- Insert custom SAS code after submitted code
This additional SAS code is stored as a customization option in your instance of SAS Enterprise Guide, making them user-specific.
Setting up a project-specific autoexec
You can apply an additional “layer” of customization by creating a process flow named “Autoexec” in a Project Tree. That process flow can be set up to run automatically whenever your or a member of your project team opens the project.
You can put anything you want in this process flow: a program with library assignments or macro definitions, one or more "Assign Library" tasks, Upload or Download data set tasks, even custom tasks. Note that a project can contain only one process flow named “Autoexec”.
By default, when you open a project that has an Autoexec flow you are prompted to run the Autoexec process flow. You will see the following prompt asking if that's what you want to do:
However, if you prefer not to have this prompt pop up every time you open the project, you can change that behavior by setting an option on the top menu bar.
- From the top Menu bar: Tools -> Options ->General
- Select the checkbox for Automatically run “Autoexec” process flow when project opens
- Click OK button to save and close the Options window.
Autoexec is a very convenient and powerful productivity feature of SAS Enterprise Guide. Use it to your advantage.
Additional resources
- You asked for it: the Autoexec process flow shares a little more insight on advantages of autoexecs in SAS Enterprise Guide.
- Check this paper for more tips on Writing Code in SAS® Enterprise Guide.
Handpicked Related Content: Creating reports in style with SAS Enterprise Guide
12 Comments
Thank you for this informative post. I was a bit concerned because one has to open the project to see the "autoexec.sas" in EG and it would not be easy to jump between systems, for instance to PC SAS. I overcame this by %INCLUDE'ing the autoexec.sas. This should allow me to just transfer the programs and the appropriate autoexec.sas programs and allows me to make changes to the autoexec.sas file in just one place.
HTH,
Kevin
Thank you, Kevin, for your comment. The autoexec is what SAS implicitly %includes at the beginning of SAS session. You can always explicitly %include any file (code) at the beginning or elsewhere in your SAS program. In a sense, it's a matter of personal preference.
At the company they had just purchase a very very large brand new unix server. It was slow on the old one and slow on the new one. How do explain my PC enterprise guide learning edition which ran on a SAS institute server being so slow? I am talking slow just using little data sets and data step stuff. My computer has an I7 processor.
Jon,
From your comment it is unclear whether you are running SAS on your company "very very large brand new unix server" or "on a SAS institute server" or whether you are running commercial EG or learning eddition.
As I mentioned in my response to your prior comment, perceived SAS EG slowness has nothing to do with the EG itself or PC it is running on, but has everything to to do with the SAS server and network data exchange between client PC and SAS server.
I noticed that at many companies their firewall or other security measures (e.g. scans) substantially slow down data exchange between client PCs and servers. If that is the case it could be addressed with your IT department.
Unfortunately, I cannot troubleshoot your environment using this blog. I suggest you contact SAS Technical Support at support@sas.com, they will be able to sort thing out.
Best regards,
Leonid Batkhan
I find one word adequately describes enterprise guide: SLOW.
I found that for the learning version I purchased.
My previous company was going to force everyone to use enterprise guide on a server. After 1 year it was scrapped because it was so slow. It became optional.
For the amount of money and time needed to maintain, and get it to work up to speed, you could just train your SAS programmers to be better SAS programmers.
Jon, I am sorry to hear about your bad experience with SAS Enterprise Guide.
However, SLOW is not Enterprise Guide itself, but rather inadequate usage of the server where SAS runs. I don’t know your company’s particular situation, but it seems that they either have too small a server for the amount of users it is supposed to serve, its poor configuration, or some network bottleneck. Anyways, SAS EG is just a client software (like a web browser), and like one can’t blame a browser for slowly responding website, we can’t blame EG for slowly responding server.
As for training to be better SAS programmers, again SAS EG does not prevent you from doing that, besides it has embedded Program Editor that allows you to write your programs right there, in SAS EG, and submit them just like you would in the classic SAS environment.
Jonathan,
Thank you for your comment. When you run SAS on your PC, you may delegate some code to be run on a server. With SAS EG, your SAS code is run on the server. EG is just a client that allows to submit your code to the server and return results to EG. With EG, you don't have SAS running on your PC.
Ah, I see what you mean. That makes sense and a great point.
After looking at it more, I was able to create an autoexe project/process flow that went through different programs which are assigned to specific servers that would, more or less, create that same functionality as an autoexec.sas program in PC SAS. It works fairly well, if only there was a way to automatically close that autoexec project/process flow after it executes.
Ah, here's a better approach to what I'm looking for:
Instead of using a project to autoexec, I create an autoexec macro that runs based on the sas server name (e.g. _SASSERVERNAME macro variable). So the code would look something like this:
%macro autoexec;
%if &_SASSERVERNAME = %NRSTR('Local') %THEN %DO;
setting libraries, formats, macros etc.>
%END;
%ELSE %DO;
setting libraries, formats, macros etc.>
%END;
%mend;
%autoexec;
You could then copy and paste that in the "Editor" option of the "Submit SAS code when server is connected" or reference it with the %include statement.
Just thought I would share for those looking to achieve that similar PC SAS feels with autoexec.
As you see there is a lot of flexibility in using autoexec files 🙂
Leonid,
This is a great knowledge share. One thing I have been perplexed about regarding autoexec in E.G. is that in PC SAS, I can run an autoexec that has both local and server options (i.e. using an rsubmit/endrsubmit functionality), libraries, macro calls, etc that I would use on a regular basis. How would I implement such an autoexec in E.G. that would automatically know what pieces of code to process via local and what to process via server side if I am set up on a SAS Grid server? I can't seem to find anything out there that would, such a way, programmatically alter what server to run what parts of code.
Leonid,
Your post is excellent is it is setting the focus to customer business, not IT-staff, not SAS techies. SAS has that lot of options it can give that lot of cooperation to fulfill the customers/business requirements and expectations. Just know those options, explain them. ....
Let the choice of what will be done by the responsible business persons. It would be a win/win.
That is quite different than what I see often happening