The concept of an autoexec file (specifically, an autoexec.sas file) has been around in SAS for many years. SAS programs rely on a host of contextual information in the form of data locations (paths, file references or libraries), system options, predefined macro variables and many others. Users find it beneficial to use autoexec.sas to execute pre-processing (you may consider them pre-'program') code because it saves time and simplifies maintenance of execution code, allowing it to run on multiple environments with different settings.
SAS Viya Workbench provides you multiple environments to test, iterate and develop solutions at scale. The ephemeral nature of Workbench instances, however, requires that you take certain steps to ensure that your autoexec specifications are recognised across those instances. Here's a quick overview:
Remember to set up a home directory!
Many prior unsuccessful attempts at using autoexec.sas stem from omitting this first step. As mentioned earlier, every Viya Workbench instance is spun up using containers and unless persisted, data on these containers is specific to the instance alone and go away with its deletion. One therefore requires a persistent storage to house the autoexec.sas file, and this role is performed by the home directory. Watch this quick video to learn how to set up home storage location.
As you might observe, this is fairly easy. Note that users can create only one home storage location, which is automatically treated as the user's home folder only for subsequent workbench instances (not already running ones).
Create an autoexec.sas file
Keep an example autoexec.sas file ready. You might like to keep things simple for the first test. I typically test the same by defining a new libname (pointing to a location on my persistent storage) and then checking if this libname is automatically recognised in a future Workbench instance. Note this means you have to start a Workbench instance (without an autoexec.sas defined, yet), with storage attached, create a file, and then take steps to apply the same. As shown in the following video:
Note: In the video, for convenience, we saved the test_autoexec.sas in our persistent storage area. Ideally, however, you'd like to save this in your home directory for reasons which will soon be apparent.
Associate your autoexec.sas with the SAS session
To do this, we take advantage of the settings within the Visual Studio Code Extension For SAS, available here. A bonus is that you can edit this settings file for any use of the Visual Studio Code extension for SAS (not just Workbench). The following video shows you how.
It's easy to slip up here, so let me point out that you need to click on the tab named "Remote[xxxx.my,workbench.sas.com]" to get to the correct settings.json page. Otherwise you only edit the Workspace settings, which are local to the session.
Further, why bother adding a new autoexec.sas file, when there seem to be some default autoexec.sas files already existing? While you are free to edit those files directly, it might be convenient to add a new reference to your autoexec.sas file so that you can easily manage the same and maintain a separation between default autoexec settings and some settings which may be short-term or more dynamic in nature.
Another question could crop up regarding the need for a home directory. In addition to providing some persistent storage, the home directory also happens to be unique to a user's profile, i.e. there can be only one home directory available. On the other hand, there could be multiple other persistent storage locations defined, but the user's allowed to mount only one of them at a time.
Test your changes
Once you have made your edits, it's time to test if your changes work. As you might observe in the following video, upon creating a new Workbench instance and directly calling a program using a libname MYTEST, I find that MYTEST has been automatically assigned, proving that my autoexec.sas file works!
Have fun testing your autoexec.sas files. Remember, they take effect only for subsequent Workbench instances that you create.
