SAS Stored Process: Benefits of Minimalist Programming

Minimalism

SAS stored processes can do a lot.  While I haven’t taken on the life of a true minimalist, recently I have come to see the benefits of limiting my stored process source code to just one statement.  And the best part of this practice is, I can still do everything I want.

When you create a stored process, SAS writes the source code somewhere (see Tricia’s post on where the code is stored).  Typically you enter the source code in the stored process wizard.  I am now in the habit of typing just one %INCLUDE statement in the source code, and I end up with a stored process window that looks like below.  I use the /source2 option to make sure the included code is written to the log. 

Minimalist Stored Process

The full stored process source code ends up as below, because SAS adds a bit of wrapper code:

Minimalist Stored Process: Source Code

The main code is DoSomething.sas.  It has the usual DATA steps, PROC steps,  macro calls, maybe even %INCLUDE statements to call other other sub-modules.

Minimalist Stored Process: Main Code

So what are the benefits?

1. You can store the main SAS code (DoSomething.sas) wherever you want.  I’ve been writing SAS code for MUCH longer than I’ve been writing stored processes.  I’m used to storing my SAS code in /Project directories.  With this approach, I can put the source code for the stored process in a central location managed by the SAS Administrator, but have DoSomething.sas in the project directory structure.
    
2. Easier development of stored process.  DoSomething.sas can be written with anything.  Like Display Manager SAS and interactive tools like the data step debugger? Use DM SAS.  Like process flows and point-and-click generation of code? Use Enterprise Guide.  Like vi? Emacs? Ultraedit? Notepad?  Use what you like to write the program.  Then just have the stored process %INCLUDE it.
    
3. Easier updates to stored processes.  Tricia has a great post on 3 ways to edit a stored process.  With this method, editing stored process code can be done with any program that can edit a .sas file (see #2 above).  You don’t need write access to the actual stored process source code, you only need access to your program, DoSomething.sas.
    
4. Logical separation of stored process itself (stored in the metadata) from the main code.  Want to edit the stored process (modify prompts, change which server it runs on, etc.)?  Open the stored process.  Want to update the code?  Open the code.  I often have a simple Enterprise Guide project for each stored process, with a link to the stored process, a link to the code, and sometimes links to sample code used for reference materials, test scripts, etc. The visual workspace of EG makes it an excellent tool for organizing and accessing all of the files related to a stored process.
    

Want More Indirection?

Having the stored process source code be simply a %INCLUDE statement which calls another program is an example of indirection.  Don Henderson has a great post where he describes a setup having a single stored process capable of running ANY code module.  He uses the macro language, rather than %INCLUDE, to invoke code.  The equivalent %INCLUDE approach would be having a stored process with the source code: %INCLUDE &program /source2;  and have a prompt which allows the user (or more likely a developer) to specify the name of a SAS program to be invoked.  So it’s another layer of abstraction.  Neat stuff.

What Say You?

As I’ve mentioned before, I’m still new to stored processes.  So I look forward to hearing any thoughts as to the pros and cons of this approach.  I’m excited that Tricia invited me to start blogging here on occasion.  And mostly see it as an opportunity for me to share some ideas, and hopefully get some feedback for improvements!