BI Tools

Tips and tricks for building information maps, OLAP cubes, reports, and dashboards

BI Admin

Learn your way around a SAS BI installation.

Visual Analytics

Learn your way around the SAS Visual Analytics tool

Coding & Data

Extract, transform, and load your data into the SAS BI toolset

Stored Processes

Create and design stored processes like a rock star

Home » BI Tools, Enterprise Guide, Stored Processes

Using an Autocall Macro Library in SAS BI

Submitted by on 2013-07-10 – 7:26 AM 6 Comments

sas autocall macro libraryAs a SAS programmer, I am dependent on my SAS autocall macro library.  It stores a bunch of utility macros that I use on a daily basis. When I started learning about stored processes and other BI tools, one of my first thoughts was “How can I access all of my utility macros?”  And it turns out, it’s pretty straight forward to define an autocall library in a SAS BI setting.  And the best part is, you don’t have to be a SAS administrator or modify SAS configuration files.  You can do it with just a single line of code.

What’s An SAS Autocall Macro Library?

Autocall libraries are one way to make SAS macros easily accessible.  Suppose you have a bunch of macros, and you want to be able to invoke them in a program.  You could paste all of the macro definitions into your program, or if you have each macro definition stored in its own .sas file, you could %INCLUDE each file.  But it is easier to create an autocall library. To create an autocall library, you:

  1. Store each macro in a .sas file with the same name as the macro.  So the definition of %MyMacro is stored in the file mymacro.sas.
  2. Store all of the .sas files with macro definitions in a single directory, call it /MyAutocallMacros.
  3. Tell SAS to look in /MyAutocallMacros when looking for macro definitions.

Once you have defined an autocall library, all of the macros stored inside it are available to your program.  If you invoke a macro that has not been previously compiled, SAS will look in the autocall library for the definition, compile it, and execute it.

Even if you have never created an autocall library, you already have one.  SAS provides a suite of autocall macros by default.  If you use stored processes, you probably use %STPBEGIN / %STPEND.  While they may seem like magic, they are just autocall macros.  If you search around your server, you’ll find stpbegin.sas and stpend.sas, with the definition of each macro.

How To Point To An Autocall Library

As with most things SASsy, there are many ways to point to an autocall library.  If you are an administrator for your SAS server, there are a plethora of configuration and autoexec files that would allow you to point to the library.   If you are a developer, I think the easiest way to point to an autocall library is adding an options statement to your code:

options insert=(sasautos="/MyAutocallMacros") ;

When you run that, the directory /MyAutocallMacros will be added to the front of the search path for autocall macros.  I put that line near the top of all of my stored processes.  I also put it near the top of all of my DI Studio jobs, and in Enterprise Guide I automatically run it every time I connect to a server.  Once it has run, my entire macro library is available for use.

Is It Really That Easy?

Yes.  For the most part…

There are two possible gotchas worth mentioning.

If your code is running on a Linux/Unix server, make sure the file names of macros stored in your autocall library are all lowercase. File names are case-sensitive in *nix.  If the definition of %MyMacro is stored in MyMacro.sas, the autocall facility will not be able to find it.  The file must be named mymacro.sas.  Years ago I lost about half a day when I was bit by that problem, trying to figure out why half of my autocall macros wouldn’t work.

Regardless of the operating system, it is essential that when your SAS code executes, it can read the macro definitions stored in your autocall library.  When using PC SAS or SAS Enterprise Guide, this is rarely an issue.  If you wrote the .sas files in your library, you can read them.  If users don’t have read access, the macros are not found. But as a BI developer, you are probably creating stored processes and other tools that will be executed by other users.  When a user runs the code, that user must have read access at the operating system level to read the .sas files in the autocall library (some stored processes run under a service account such as SASSRV, in which case the service account must have read access). If they don’t have read access, the macro definitions will not be found.  So check the permissions on the files in your autocall library to make sure they are readable by your users.  Sometimes it’s acceptable just to make your autocall library readable by “world.” 

Want More?

If you want to learn more about autocall libraries (or any macro language topics),  I would whole-heartedly recommend you buy a copy of Art Carpenter’s excellent book, Carpenter’s Complete Guide to the SAS Macro language.  Of course, user group papers are always a great resource as well. Searching LEXJANSEN.COM for autocall macros will turn up a number of helpful papers, including (hopefully) a paper I wrote on an automated method to generate documentation of the content of an autocall library.

What Say You?

Do you use autocall libraries in SAS BI tools you develop?  Feel free to share any tips you have on using a macro library.  Especially if you have thoughts on how I could be doing this better! 


Learn More about SAS Stored Processes and Prompts

You can learn more tips and tricks for creating, debugging, and using SAS stored processes in the 50 Keys to Learning SAS Stored Processes book. It's a complete guide to SAS stored processes. Check Amazon for best pricing and quick shipping!

 
The following two tabs change content below.

Quentin McMullen

Quentin McMullen has been programming in SAS for 15 years, and for the past year has been working on SAS BI projects. He has presented at national and regional SAS user group conferences, and can often be found corresponding with colleagues on SAS-L.

Tags: , ,

6 Comments »

  • Excellent point Paul. I don’t know if all Administrators makes these directories open – maybe unintentionally.

    Are there any directories that write the macros for you? 😉

  • Paul Homes says:

    Hi Quentin,

    I’m a big fan of autocall macros too. Perhaps your readers would also like to know that standard SAS platform installations come with a built-in, often empty, environment-specific autocall library location pre-defined and ready for sites to drop their autocall macros into. The SAS Deployment Wizard pre-configures one in the SASEnvironment/SASMacro subdirectory of the SASApp application server directory. For my installation this is at:

    /opt/sas93m2/config/Lev3/SASApp/SASEnvironment/SASMacro

    People with the right file system permissions can just drop their autocall macros in that directory and they are automatically available, with no code or configuration changes to all DI jobs, EG projects, stored processes etc that use that application server. Being environment-specific the autocalls can be independently versioned and migrated between dev, test and prod environments too (ideally using a version control system). As a bonus there’s also a pre-defined format library right next to it (in SASEnvironment/SASFormats).

    Cheers
    Paul

  • Also great for migrating and managing ETL processes and tools with Base SAS! Users don’t have to remember file system paths.

  • Quentin says:

    Thanks Don,

    I agree, the Request Init facility looks much more appealing than defining autocall in every stored process. And it’s how I do it with PC SAS (specifying path in config.sas).

    But with server SAS, that is applied at the server level, right? So with a corporate server, seems like that would be an appropriate place to define the corporate macro library.

    And I like your approach to soft coding the autocall path for project-specific macros using information from metadata folder path.

    But I have a lot of macros that are for broader use than project specific, but they are not for corporate-wide use. So say I work in HR, and write stored processes for various projects. And there is a macro library used within HR. Short of having our own (logical) server to allow us to use Request Init, seems like I am stuck hard coding the autocall path (?)

    But I certainly agree there is the potential for maintenance headaches resulting from hardcoding this path, so I appreciate the warning and your suggestions!

  • Thanks Don.

    I hope readers take note of your new book SAS Server Pages as well.

  • I too use the macro autocall facility. In fact, I almost always just drop a new macro into an autocall library instead of writing a new stored stored process. I wrote a series of blog entries about this approach back in 2010. You can find them on this sasCommunity.org article on my runMacro Stored Process.

    And I would strongly discourage anyone from defining the location of the autocall library in every stored process. They should be defined in one place. I do that using the Stored Process Request Init facility.

    And if you have a need for separate autocall libraries for groups of stored processes, consider an approach like what I describe in my blog entry Where, oh where, do my Macros live?
    . The metadata folder path could be used, instead of a parameter, to create the autocall path.