SAS Enterprise Guide


When mentioning to friends that I’m going to Orlando for SAS Global Forum 2107, they asked if I would be taking my kids. Clearly my friends have not attended a SAS Global Forum before as there have been years where I never even left the hotel! My kids would NOT enjoy it… but, […]

The post Learn about SAS Studio, SAS Enterprise Guide and (drumroll) SAS Viya at SAS Global Forum 2017! appeared first on SAS Learning Post.


Colors are the subject of many romantic poems and songs, but there isn't much romance to be found in their hexadecimal values. With apologies to Van Morrison:

...Skipping and a jumping
In the misty morning fog with
Our hearts a thumpin' and you
My cx662F14 eyed girl

When it comes to specifying colors within a SAS program, you can always rely on the simple color names: red, blue, yellow, and so on. (You know, the colors you might remember from your first box of Crayola crayons.) You can even predict a few more exotic names such as "lightgreen" and "darkyellow" and even "olivedrab". Are you familiar with HTML color name standards? Most of those names work as well. But for true color precision, you might want to use the hexadecimal values or at least the super-descriptive SAS color names.

In SAS Enterprise Guide, when you type a piece of SAS syntax that expects a color value, you'll find that the program editor pops up a helpful "color picker," displaying a long list of acceptable color names and their hex values. You can scroll through the list or use "type ahead" to find the color you want, then click or press Enter to accept it.

There's a keyboard shortcut that will invoke the color picker at any time: Ctrl+Shift+C. Use that when working on a SAS macro program or at any place the SAS program editor might not otherwise predict. By default, the editor will drop in the color name. You can change that behavior by visiting Program->Editor Options, Autocomplete tab. Select between the SAS color name or the more-obscure hex value. (Guaranteed to make your program more difficult to read, and thus helpful for job security.)

Are you using SAS Studio? You can also color your world with just a few keystrokes. This screenshot is from SAS Studio 3.6:

More colorful resources

tags: SAS Enterprise Guide, SAS programming

The post Tip for coding your color values in SAS Enterprise Guide appeared first on The SAS Dummy.

十二 012016

In my earlier post about WHERE and IF statements, I announced that the DATA step debugger has finally arrived in SAS Enterprise Guide. (I admit that I might have buried the lead in that post.) Let's use this post to talk about the new debugger and how it works.

First, let's address some important limitations. This tool is for debugging DATA step code. It can't be used to debug PROC SQL or PROC IML or SAS macro programs. Next, it can't be used to debug DATA steps that read data from CARDS or DATALINES. That's an unfortunate limitation, but it's a side effect of the way the DATA step "debug" mode works with client applications like SAS Enterprise Guide. (Workaround: load your data in a separate step, then debug your more complex DATA step logic in a subsequent step.)

Ye olde DATA step debugger

1986 called; they want their debugger back

1986 called; they want their debugger back.

If you've been around SAS programs for a while then you might remember the full-screen DATA step debugger in the SAS windowing environment. Introduced as production in SAS 6.09E (E="enhanced!"), it was basic but it did the job, relying on command-line processing to direct the debugger actions. It had only two windows: one for the source, and one for the "log", meaning the debugger console log. You could set breakpoints, variable watch conditions, examine variables and calculate values -- all with commands that you typed. (Even though I'm writing this in the past tense and it seems like I'm eulogizing, this debugger still lives on in Base SAS!)

The new DATA step debugger

The new debugging environment, introduced in SAS Enterprise Guide 7.13, has all of the features of its ancestor. And it's much more usable, with toolbars and windows that allow you to control its behavior. But keyboard junkies, don't worry -- that command line is still there too!

To activate the debugger, click the new "bug" toolbar icon in the program editor window. Once activated, you can click the bug in the left "gutter" of the program editor to begin a debug session. (You can also press F5 to debug the active DATA step.)
Starting the Debugger
Examine the screenshot below. You see the source window on top and the console window at the bottom, plus a convenient "watch" window that shows much of the content in the program data vector (PDV). That's all of the variables defined in the DATA step, plus automatic variables like _N_ and _ERROR_.

EG debugger
As you step through the DATA step, the line pointer in the source window advances to show the next line that will execute. You can use keyboard shortcuts (F10), the toolbar, or typed a typed command ("step") to execute that line and advance. With every step, the watch window is updated with the latest values of the variables in your step. When a variable changes value, it's colored red. If you want to the DATA step to break processing when a certain variable changes value, check the Watch box for that variable.

Diving deeper with advanced debugging

Here's another example of debugging a different DATA step program. This program uses a BY statement and FIRST.variable logic, and you can see the additional automatic variables (FIRST.Make and LAST.Make) that the debugger is tracking. I also used END=eof on the SET statement; that adds the eof "flag" variable into the mix during run time.

In the Debug Console window you can see that I've issued some pretty fancy commands. The DATA step debugger allows you to set breakpoints that trigger on specific conditions. For example, "b 8 when (running_price > 10000)" will break on Line 8 when the value of running_price exceeds 10,000. "b 8 after 5" will break on Line 8 after 5 passes through the DATA step. You can set and clear line-specific breakpoints by clicking in the "gutter" (that left-hand margin next to the line numbers).

The "list _all_" command reveals the details about your open data sets and files. Here's what I see during the run of my program.

list command
Other commands let you SET variable values, EXAMINE variables, CALCulate expressions, GO and JUMP to specific lines, and more. The SAS documentation contains a complete reference for DATA step debugger commands, and most of those work exactly as documented, even within SAS Enterprise Guide. Here's the list:

This old-but-still relevant SAS Global Forum paper (written by a SAS user) also covers some useful debugging concepts in SAS which you can apply in this new environment.

A personal note: eating my words

I've presented "SAS Enterprise Guide for SAS programmers" as a topic in one form or another for the past 15 years. Every so often the topic of the DATA step debugger comes up, and I've said "don't look for it anytime soon." Knowing how the full-screen debugger is closely tied to the SAS windowing environment, I didn't hold out hope for a client application like SAS Enterprise Guide to get it working. Kudos to the R&D team! They creatively found a solution with the "/ldebug" option, an even more obscure debugging approach that works in SAS batch mode. I think this feature will be tremendous productivity boost for experienced SAS programmers, and a useful learning and teaching tool for those just getting started with the DATA step.

tags: SAS Enterprise Guide, SAS programming

The post Using the DATA step debugger in SAS Enterprise Guide appeared first on The SAS Dummy.

十一 272016

In the DATA step, the WHERE statement and the IF statement (a.k.a. the "subsetting IF") have similar functions. In many scenarios, they produce identical results. But new SAS programmers are taught early on that these two statements work very differently, and in important ways. To understand the differences, it helps to step through the program line-by-line to see how SAS "thinks." Fortunately, the new DATA step debugger in SAS Enterprise Guide 7.13 makes this really easy to do.

Difference between WHERE statement and IF statement

Here are the basics: the WHERE statement is applied when the DATA step is compiled. Incoming data (from a SET or MERGE statement) is filtered immediately to just those records that match the WHERE condition, so only those records are ever loaded into the program data vector (PDV). This results in fewer iterations through DATA step code, but provides no opportunity for "dynamic" decisions about which records to examine.

In contrast, the IF statement is evaluated at run time, and operates on the variables in the PDV. When the IF condition is met, the current observation is kept for eventual output. Unlike the WHERE statement, the IF statement can examine values of new variables that are defined within the step.

Consider these two DATA steps. They produce identical output of 10 records, but the first one processes only those 10 records whereas the second step processes all 19 records from the input.

data results1;
  set sashelp.class;
  /* WHERE applied at compile time  */
  /* Processes ONLY matching obs    */
  where sex='M';
data results2;
  set sashelp.class;
  /* IF evaluated at run time  */
  /* Processes EVERY obs       */
  if sex='M';

Using the DATA step debugger to understand the DATA step

The new DATA step debugger in SAS Enterprise Guide makes it very easy to illustrate how WHERE is processed differently from IF. I loaded each of the above programs into my session, then clicked the new "bug" toolbar icon to activate the debugger. Once activated, you can click the bug in the left "gutter" of the program editor to begin a debug session. (You can also press F5 to debug the active DATA step.)
Starting the Debugger
Watch this first animation of a debugger session and see what you notice about the WHERE statement.

Debugger with WHERE
Watching this little movie, I see a few things that reveal some insights.

  • The statement pointer never lands on Line 5 (the WHERE statement). That's because the WHERE statement isn't processed at run time.
  • Even though the CLASS data contains 19 records, the value of the _N_ automatic variable reaches only 11, indicating that only 10 records were processed.
  • The variable watch window uses red to indicate when a variable changes between iterations. The Sex variable never changes from 'M', and thus stays colored black through the entire session.

Let's compare that to the IF statement. Study this animation and see what stands out to you.

Debugger with IF
Here's what I see:

  • The statement pointer begins at Line 2, then 5, and moves to Line 6 (the RUN statement) only when the record has made it past the IF condition and into the output. For each observation where Sex='F', the DATA step stops processing the record and the RUN statement is skipped.
  • In this program, _N_ reaches 20 -- that's because all 19 records in SASHELP.CLASS are processed and the step exits at the end-of-file condition.

Learning more about subsetting IF, IF-THEN, WHERE, and debugging

There are several good articles about how the IF statement works, on its own and in combination with IF-THEN-ELSE constructs. Here's a recent article by SAS trainer Charu Shankar. And here's another reference that's included in a piece about the Top 10 SAS coding efficiencies.

The new DATA step debugger in SAS Enterprise Guide opens a new world of understanding for beginner and veteran SAS programmers. It has all of the functions of the "classic" debugger available in the Base SAS windowing environment, but with a much friendlier user interface, keyboard shortcuts, and useful watch windows. In a future post, I'll cover the debugging functions in more detail.

tags: SAS Enterprise Guide, SAS programming

The post Debugging the difference between WHERE and IF in SAS appeared first on The SAS Dummy.

十一 142016

I've supplied dozens of custom tasks for SAS Enterprise Guide, but the Copy Files task is easily the most popular. The Copy Files task allows you to capture "file transfer" steps inside your process flow, so that you can automate any file upload and download operations between your PC and your SAS workspace session. It has proven to be an essential task for customers who move from using PC SAS to SAS Enterprise Guide. Many of you still need a method to copy data and results to and from your SAS session. When the SAS session is on a remote server, then this task fills that important gap.

Because "Copy files" is a custom task, you have to download the task package (from this blog) and follow a few steps to install the task into your SAS Enterprise Guide environment. When installed, the task can be found in the Tools → Add-In menu.

Copy Files task moves to the Tasks → Data menu

Copy Files in new menuThat's about to change with the next release: SAS Enterprise Guide v7.13. We're going to make an honest task out of "Copy Files," as it becomes an official feature in SAS Enterprise Guide. That's great news for a couple of reasons: no more custom install steps, and you can now get official support from SAS Tech Support when using it (although they would have always helped before now). The task works exactly the same way and if you have existing projects that use it, you don't need to make any changes. However, there is one change you need to know about: as an "official" task, it will appear in an official menu location. As of SAS Enterprise Guide 7.13, you'll find Copy Files in the Tasks → Data menu, near the bottom with some other utility-type tasks. And if you had previously installed it as a custom task, it will no longer appear in the Tools → Add-In menu.

SAS Enterprise Guide 7.13 is set to release within the next couple of weeks (near the end of November 2016), and it contains several exciting new features that I'll describe in this blog. Many of you will see it immediately when SAS Enterprise Guide prompts you to update. Stay tuned!

tags: Copy Files, SAS custom tasks, SAS Enterprise Guide

The post The Copy Files task is going legit (and moving) appeared first on The SAS Dummy.


SAS Enterprise Guide has come a long way since version 1.0 was released in 1999! Are any of you original users that remember the Help characters, Clippy, Peedy or Merlin?  I was working as a statistician for another company that year, and I attended a SAS user group meeting where […]

The post New features in SAS Enterprise Guide 7.1 appeared first on SAS Learning Post.


SAS Enterprise Guide has come a long way since version 1.0 was released in 1999! Are any of you original users that remember the Help characters, Clippy, Peedy or Merlin?  I was working as a statistician for another company that year, and I attended a SAS user group meeting where […]

The post New features in SAS Enterprise Guide 7.1 appeared first on SAS Learning Post.


Have you seen this error when running a program in SAS Enterprise Guide?

ERROR: You cannot open WORK.YOURDATA.DATA for output access with member-level 
control because WORK.YOURDATA.DATA is in use by you in resource environment IOM 

It has a simple cause: the data set that your program is trying to write (or rewrite) is open in the data viewer. With regard to this data file, your program is in contention with the SAS Enterprise Guide application.

Usually SAS Enterprise Guide closes all open data sets before running a program or task, and that's meant to help you avoid this error. But sometimes a data set file remains open for one reason or another, and the conflict results in the error message. Fortunately, there is a simple fix.

Close All data sets window

Select Tools->View Open Data Sets. The View Open Data Sets window shows the names of the data files that SAS Enterprise Guide has open. And it offers a convenient Close All button to clear the list. Closing the data doesn't affect the contents of the file or its place in your project. It simply removes the lock that SAS Enterprise Guide is holding on the file.

If you are running multiple SAS Enterprise Guide sessions, it's possible for one session to have a lock on a file that you're trying to update in another session. The View Open Data Sets window shows only those data sets from your current session, so be sure to check your other projects if you're multitasking.

The default behavior -- close all data before running SAS programs -- is controlled in Tools->Options->SAS Programs. If you don't want SAS Enterprise Guide to close your data windows, clear that checkbox. (It's difficult for me to imagine why you would do that...but hey, we have options for everything.)

tags: SAS Enterprise Guide

The post Tip: How to close all data sets in SAS Enterprise Guide appeared first on The SAS Dummy.


Would you like to see the latest features of SAS Enterprise Guide in action? Of course you would! That's why it's well worth the 12 minutes of your time to watch this video from SAS Global Forum 2016.

In the video, Casey Smith (SAS' R&D manager of the SAS Enterprise Guide team) shows off the favorite new features, including:

Casey also talks about his unique perspective as a second-generation SAS user. His Mom is a long-time SAS user; Casey was raised with SAS in the house! It's only appropriate that Casey went on to join SAS as an employee. He frequently presents for user groups and you can often find Casey (as CaseyS_SAS) on the SAS Enterprise Guide discussion board in SAS Support Communities.

tags: SAS Enterprise Guide, SAS global forum, SAS GloFo

The post Video: Demonstrating the new features in SAS Enterprise Guide 7.1 appeared first on The SAS Dummy.


These days SAS programmers have more choices than ever before about how to run SAS.  They can use the old Display Manager interface, or SAS Enterprise Guide, or the new kid on the block: SAS StudioAll of these are included with Base SAS.


SAS Display Manager


SAS Enterprise Guide


SAS Studio

Once upon a time, the only choices were Display Manager (officially named the SAS windowing environment), or batch.  Then along came SAS Enterprise Guide.  (Ok, I know there were a few others, but I don’t count SAS/ASSIST which was rightly spurned by SAS users, or the Analyst application which was just a stopover on the highway to SAS Enterprise Guide.)

I recently asked a SAS user, “Which interface do you use for SAS programming?”

She replied, “Interface?  I just install SAS and use it.”

“You’re using Display Manager,” I explained, but she had no idea what I was talking about.

Trust me.  This person is an extremely sophisticated SAS user who does a lot of leading-edge mathematical programming, but she didn’t realize that Display Manager is not SAS.  It is just an interface to SAS.

This is where old timers like me have an advantage.  If you can remember running SAS in batch, then you know that Display Manager, SAS Enterprise Guide, and SAS Studio are just interfaces to SAS–wonderful, manna from heaven–but still just interfaces.  They are optional.  You could write SAS programs in Word or Notepad or some other editor, and submit them in batch–but why would you?  (I know someone is going to tell me that they do, in fact, do that, but the point is that it is not mainstream.  Only mega-nerds with the instincts of a true hacker do that these days.)

Each of these interfaces has advantages and disadvantages.  I’m not going to list them all here, because this is a blog not an encyclopedia, but the tweet would be

“DM is the simplest, EG has projects, SS runs in browsers.”

Personally, I think all of these interfaces are keepers.  At least for the near future, all three of these interfaces will continue to be used.  What we are seeing here is a proliferation of choices, not displacement of one with another.

So what’s your SAS interface?