Five Scripting Concepts Every SAS Programmer Should Know

Get a grasp on these basics if you want to better utilise the operating system in SAS.

Got these down? Find out how to utilise your scripting power in SAS here!

Command Shell

“Shell” is the generic term for a text window, through which you can interact with a computer’s operating system (OS). They’re generally favoured by people like system admins, because with practice (or a script) they’re quicker than a point-and-click interface.

A shell is an interactive environment, where the user types in commands live from the keyboard and gets an immediate response.


Because a shell’s commands are just text, they can be stored in a plain text file and recalled when needed; this is a “script”. Scripts differ from full blown applications, they tend to be very limited in scope and don’t have a user interface. This doesn’t limit their usefulness though! Jobs like deleting all the logs in a folder over 30 days old, or creating a new folder for your results, can be very easily scripted.

In Windows, a .bat (batch) file is often used to store a script. They can be very powerful but do add complexity to your SAS program; because you’ve spread the code over two different types of file.


Windows features at least a couple of built-in command shells these days, CMD and PowerShell are most common (there’s a Linux bash environment in Windows 10, apparently). PowerShell is newer and aimed at system admins, its very much more powerful than CMD, hence the name.

CMD is the shell directly available from SAS. It is less powerful, but does plenty of things that could make a SAS programmer’s life easier. To open CMD, search cmd from the Windows home, or hit Windows Key+r (to get the run dialogue), then type cmd and hit enter.

Type echo hello, World! and press enter, you should see the text hello, World! appear directly under where you typed. This is basic, but is the first step to becoming a scripting wizard!

There are tons of pages listing native CMD commands and deeper concepts on the web, have a quick browse to get an idea of the building blocks; pay particular attention to dirmkDir, rmDir and copy.

Lots of third party software also comes with its own command line interface (CLI). SAS itself has command line options for invoking it from CMD, the ever popular 7zip does too.

Return Code

When a program finishes running in a shell, it will often set a return code (rc). The return code is used to store information about how the last program exited; it is overwritten by each successive program that runs.

In general, a 0 is good and anything else is potentially bad. I say potentially, because it’s up to the program’s creator to specify which return codes are given in each situation. Niche, point-and-click or in-house applications might use return codes differently, or not use them at all.

When in CMD, you can see the current return code by submitting echo %ErrorLevel%. Try submitting a dir command, then inspecting the return code; it should be 0. Now, try submitting a made up command like bring me cake, then read the error message and check the return code. Return codes can be inspected and programmed for in SAS, just be sure what each one means before you code logic around them!


“Piping” refers to taking the output of one command or program, and sticking into the input of another. The advantage being that data is created and then immediately consumed by something that needs it, without the slow process of making a file or the need to tidy up afterwards.

If you’ve seen SAS code that reads a directory’s contents into a .txt file, then reads the .txt file into SAS, this is not piping. Piping the contents of a directory into SAS would result in no messy .txt files to clean up (“later, I’ll do it later…”, yeah right!).