This is an introduction I give to PhD students at LSE.


Why use SAS and not the WRDS online interface?

Because you can change the data on the WRDS server before you download the output, which can be especially useful for very big data sets.


Step 1: Set up

Get a WRDS account. Link on the website.

Get IT to install: SSH Secure Shell, a File Transfer program (I like FileZilla which is free), and StatTransfer.

You’ll need SAS which is on all LSE desktops. You can get a private license for your laptop from the library IT desk. They’ll also give you CDs to install it but I ended up trying for days and giving it to IT Support 2 (Kuldip) to install it. Kuldip is also the mastermind who knows anything about SAS in the IT Support.


Step 2: Write SAS Code

Our home address is /scratch/lse. You can create folders within that you can refer to as your home library in your code.

There is also a personal folder that only you can access but that’s smaller.

Useful to know: data set list on WRDS with variable names and addresses for their data:

WRDS also has example codes that you can start off with.

CRSP and Compustat: LSE only subscribes to “Annual update”. Don’t refer to the monthly/quarterly update addresses.


Step 3: Upload code

(and other data files in SAS if using) to WRDS, using your file transfer program. Host: s, Port 22

On your file transfer program you can also create a folder so that your files are not mixed with everyone else’s from LSE.


Step 4: Run code

Use SSH secure shell

“quick connect”

cd scratch/lse, enter (or your folder)



Step 5: Check log

SAS creates a log in the folder of your SAS code. Download it to check your progress. I prefer to open it in word because the format is messed up in my text editor.

In general, if your files are locked, the code is still running.

If you send another code for execution it will only start after the current one stopped (or you kill it).


Step 6: Download the data


Step 7: Use stattransfer to transfer data to Stata (if using)


Step 8: Enter what you did in your data diary. You can use any format you like but include the following items

  • Objective
  • Code changed (historic name, new name with path)
  • Changes made. If possible copy the pieces of code
  • Errors that you found in the process and corrected
  • Errors found or other points to be checked later
  • Data created (name and path)
  • Things left to do

You should do that in general, not only when using SAS. For more professional advice on version control see

Leave a Comment