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 » Coding & Data, Enterprise Guide

PC SAS Programmer Facing UNIX? SAS Enterprise Guide to the Rescue

Submitted by on 2013-03-20 – 6:22 AM 6 Comments

Time for another confession.  For more than a decade I have been running SAS jobs on UNIX servers, but I don’t really know any UNIX editors.  Not Emacs.  Not vi.  I could work around this without SAS Enterprise Guide, but it was painful sometimes.  Now that I have started using Enterprise Guide, it is *so* much easier to use a Windows PC to write code that will be stored and executed on a remote server.

The Dark Ages (Before Enterprise Guide)

I have worked a lot of places where we had both PC SAS and UNIX SAS.  People tended to use PC SAS by default, but if a program ran on biggish data, or needed to be scheduled, we would run it on a server.  Most people were more comfortable developing code on a PC in Display Manager SAS.  When writing code that would run on a server, often the process was something like:

  1. Develop SAS program in DM SAS.
  2. FTP the program to the UNIX server.
  3. Open a terminal window on the server and batch submit the program.
  4. FTP the log file back to Windows.
  5. Review log file on Windows, debug, goto #1.

Depending on the tools available at a particular site (Samba, WinSCP, UltraEdit, etc), the process might be a bit easier, but it was usually enough of a hassle to run jobs on the server, that most people stuck to PC SAS as much as they could.  Of course there were always one or two UNIX-philes in a group who shunned Windows, lived on the UNIX server, and would laugh at the ridiculous gymnastics most of us went through as they wrote, ran, and debugged their code purely on UNIX, using their favorite insanely customizable ‘nix editor.

Enterprise Guide Enlightenment

Enterprise Guide makes all this cross-platform work easier because Enterprise Guide does not care where your code is stored.  You can write a program, save the .sas file to a remote UNIX server, run the program on the remote server, review the log, and debug, all from an Enterprise Guide session running on your PC.  (More impressively, even if you choose to store your .sas files only on your PC, you can still use Enterprise Guide to execute the code on a remote server.)

Here is a process flow with links to two .sas files: 

EGunixImg1

 

Where are the actual .sas files stored?  Enterprise Guide doesn’t care.  They could be on my PC.  They could be on a remote server.  It doesn’t matter.  They are just links.  Want to edit a .sas file sitting on a remote server? Use Enterprise Guide.  Want to create a new .sas file and save it to a remote sever? Use Enterprise Guide. 

Because this post is about creating and editing .sas files on UNIX, these files are on a UNIX server.  Here is a listing of the files in /home/…/Demo/EGunix/Code:

sas enterprise guide putty

 

Using Enterprise Guide to Create a .sas File on UNIX

Using Enterprise Guide to create a SAS program and save it to a server is straight-forward:

  1. Open Enterprise Guide
  2. File->New Program
  3. Write program
  4. Save As and indicate it will be saved to the server

Starting with the process flow above, let’s create a third program, MakePlot.sas, and save it in the same directory on the UNIX server.  Picking up at step 4, I have written the program, and just hit Save As.  The dialog box looks as below: 

sas enterprise guide unix servers

 

To save the file on the UNIX server, first click Servers, and a list of available servers will appear.  The server named SASApp is my UNIX server.  Double clicking it will open your home directory, and then you can navigate down to the directory of interest.  Below you see I have clicked my way down to /home/…/Demo/EGunix/Code, and can see the two .sas files that are already in the directory.

sas enterprise guide with unix 

Enter a name for the program, MakePlot.sas, hit save, and that’s it.  The code was just saved to the UNIX server.  And a link to MakePlot.sas was added to the process flow.  You can even use the SAVE dialog box to create and rename directories on the server.   

Here is a terminal window showing MakePlot.sas is now sitting on the server.

EGunixImg5

 

One side note: When I first tried navigating the UNIX directory structure from Enterprise Guide, I couldn’t access any directories that were outside of my /home directory.  Then I found a great tip on Angela Hall’s blog.  On the UNIX side, create a symbolic link which links from your /home directory to the desired directory.  That link will then show up as a folder in Enterprise Guide’s SAVE dialog box, and allow you to access the desired directory.

Using Enterprise Guide to Edit a .sas File on UNIX

Editing code is just as easy.  The File->Open Program dialog box allows you to navigate the remote directory structure, the same way as the SAVE dialog box.  When you open the program, a link to it is added to your process flow.  After that point, to edit the program, just double-click the link.

Executing Code on Unix

To execute the code, just hit run.  Assuming your Enterprise Guide session is connected to the UNIX SAS Server, the code runs there. 

Uhmm, Why?

At this point (perhaps earlier), a reasonable question would be, “Since Enterprise Guide allows you to store code on your local PC and execute it on a remote [UNIX] server, why would you want to save the .sas files on the server?”  Truth is, if you want to use Enterprise Guide for all of your work, it doesn’t matter where you save the code.  But if you want to run the code as part of BI applications (stored processes, DI jobs, etc.), the code needs to be accessible to the server.  Also, sometimes I like to open a terminal window and do an old-fashioned batch submit, perhaps even schedule a batch job using the UNIX cron scheduler.  And every once in a while, a UNIX-phile might ask me for help with SAS code.  Instead of reading their code in a terminal window, I can open Enterprise Guide, and have all the benefits of a GUI development environment (more on that to come in my next post…)

Never miss a BI Notes post!

Click here for free subscription. Once you subscribe you'll be asked to confirm your subscription through your email account. You email address is kept private and you can unsubscribe anytime.
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 »

  • Quentin McMullen says:

    Hi Jaap, You are right that many of the Unix die hards I have known were using Xceed primarily. That’s interesting that you found Xceed tools buried inside of EG. I couldn’t find much about it online, but did find this old tech support note, where the error message shows Xceed calls: http://support.sas.com/kb/39/928.html. The good news is that if SAS is leveraging Xceed in EG, that might mean there is more hope for control over ‘nix permissions etc in the future (per Don’s comments). Thanks for commenting.

  • Jaap Karman says:

    The Unix diehards were not only using the command line.
    The X11 interface is meant for the mouse and graphics using it like a Windows machine. At many Unix like (Linux Android IOS) based machines you still can find it.
    Using the X11 interface you needed an graphical terminal emulator. One of them was called Xceed.

    Getting in the Eguide Libraries, dll-s, you will find the name Xceed.com. See: http://xceed.com/ look at the programmertools
    No wonder Eguide is behaving that nice working cross platform.

  • Quentin says:

    Interesting, I’ll definitely take a second look at this in SMC. And easy enough to triple check by just renaming the directory that holds the links in my home dir, and make sure my stored processes are still happy. Thanks Don.

  • You might want to check the paths for your stored processes. In the example I described, EG was used to create the stored processes and the paths in EG looked right (i.e., they did not appear to use the symbolic links), but if you examined them in SMC, they did.

  • Quentin says:

    Thanks Don,

    Can see how WinSCP might give better control over permissions. And would hope UltraEdit would do this as well. Perhaps EG will grow to allow this in the future. With EG I still end up going into PuTTY every once in a while.

    Good point about the potential down side of relying on symbolic links in a user’s home directory. I do not use these links when I register a stored process. And I don’t use them in my stored process code (or any SAS code) either. I only use them when opening code in EG.

    So when I register a stored process the source code might go to /StoredProcesses (outise my home dir). And my main code (%included by the source code) might be in /Projects/ProjectA/Code (outside of my home dir). I might have a symbolic link in my homedir /home/links/ProjectA which points to /Projects/ProjectA. But none of my code uses /home/links/ProjectA. That is just there for EG to be able to open a code file.

    So I think by not using symbolic links in my home dir in any of my SAS code / metadata, I’ve avoided that trap. If some day they delete my home dir, I think the only down side would be that the links to code modules in my .egp files would no longer work. I’m okay with that, since in my head the .egp file is a convenience (all links), not a necessity. The stored processes themselves should keep working fine. But thanks for pointing it out, as it will keep me vigilant about that.

    –Q.

  • I use EG for Unix based projects but I have to say that a far better solution is to use a windows based editor with built in file transfer – like WinSCP. Gives you much more control as you can easily set permissions and it is easy to move files from one directory to another if you decide to. And don’t overlook the importance of this if you are working with others – you want them to be able to access/edit/update your files.

    And while the idea of the symbolic link to other locations sounds good on the surface, there is a trap there that may very well come back to haunt you one day. Specifically if you register any stored processes, the path that EG uses goes thru your home directory. I had a client last year who discovered that none of the stored processes that a colleague of his had written worked anymore. The reason? He had left the firm, his id had been removed per policy and the symbolic links no longer worked.