I had three students who successfully completed the Introduction to SAS class that I am teaching at UMKC. Here is the advice that I offered about how to continue to learn more about SAS.

SAS Institute has an excellent support network and all of their documentation is online, so I would certainly encourage you to check their material. SAS Publications offers numerous books that are all carefully vetted and written by nationally recognized experts. The prices on SAS publications are fairly reasonable. SAS also maintains various peer support communities.

SAS hosts many conferences and the regional conference (Midwest SAS Users Group) usually is held at a location not too far from Kansas City. There used to be a Kansas City Area SAS Users Group with quarterly meetings, but I could not find any recent information about this group on the web.

There is a SAS training center in Overland Park. The courses are not cheap but are worth the money.

SAS Institute offers various certification programs. These also cost money, but provide you with a credential that may help you get a better job.

There’s not a lot of resources outside of SAS that help. The one major exception is the UCLA Institute for Digital Research and Education. This site has lots of resources not just for SAS, but for SPSS, Stata, and R. I can’t say enough good things about this site.

The one big thing about SAS is that most of the resources cost money. The three exceptions are the online documentation manuals, the peer support communities, and the UCLA site. Pretty much everything else costs money. The prices are not bad, but you have to decide on your own whether the benefits outweigh the price.

A couple of my students are having difficulty with restructuring data sets in SAS. This is not surprising. Restructuring is very important, but not so easy. I decided to run a few simple examples of PROC TRANSPOSE to help clarify things. Here is the code and output.

The simplest application is taking a data set  with six rows and one column and converting it into a data set with one row and six columns.

data original;
  input c;
cards;
1
2
3
4
5
6
;
proc transpose data=original out=transposed;
  var c;
run;
proc print data=transposed;
run;

This is what the transposed data set looks like.

Obs    _NAME_    COL1    COL2    COL3    COL4    COL5    COL6

 1       c         1       2       3       4       5       6

The BY statement will transpose separately for each level of the BY variable and then stack those transposes one beneath the other beneath the other. In the artificial data set, there are two rows per subject and three subjects so SAS will create a data set with one row and two columns for subject 1, stack another data set with one row and two columns for subject 2 beneath that and a third data set with one row and two columns for subject 3 beneath that. The final data set has three  rows, one for each subject. This is the simplest example of going from a tall and  thin format to a short and fat format.

data original;
  input a c;
cards;
1 1
1 2
2 3
2 4
3 5
3 6
;
proc transpose data=original out=transposed;
  by a;
  var c;
run;
proc print data=transposed;
run;

The transposed file looks like this:

Obs    a    _NAME_    COL1    COL2

 1     1      c         1       2
 2     2      c         3       4
 3     3      c         5       6

The names that SAS chooses for the new columns are rather undescriptive. You can use the ID command to borrow the variable names from a column in the original data set. In this artificial example, SAS names to two columns pre and pst.

data original;
  input a b $ c;
cards;
1 pre 1
1 pst 2
2 pre 3
2 pst 4
3 pre 5
3 pst 6
;
proc transpose data=original out=transposed;
  by a;
  id b;
  var c;
run;
proc print data=transposed;
run;

The transposed file looks like this:

Obs    a    _NAME_    pre    pst

 1     1      c        1      2
 2     2      c        3      4
 3     3      c        5      6

You can’t use a number for a variable name in SAS, but if you want to number your variable names, the PREFIX option can help.

data original;
  input a b c;
cards;
1 0 1
1 1 2
2 0 3
2 1 4
3 0 5
3 1 6
;
proc transpose data=original out=transposed prefix=time;
  by a;
  id b;
  var c;
run;
proc print data=transposed;
run;

The transposed file looks like this:

Obs    a    _NAME_    time0    time1

 1     1      c         1        2
 2     2      c         3        4
 3     3      c         5        6

If your data is tangled up, the ID statement will untangle the data for you. In this example, the second subject has the pst value listed before the pre value. SAS will re-orient that subject so that the pre values will fit in the first column and the pst values will fit in the second column.

data original;
  input a b $ c;
cards;
1 pre 1
1 pst 2
2 pst 4
2 pre 3
3 pre 5
3 pst 6
;
proc print data=original;
run;
proc transpose data=original out=transposed prefix=time;
  by a;
  id b;
  var c;
run;
proc print data=transposed;
run;

The transposed file looks like this:

Obs    a    _NAME_    time0    time1

 1     1      c         1        2
 2     2      c         3        4
 3     3      c         5        6

If a subject has one or more missing rows, SAS  will put a missing value in the appropriate column after transposing. In this example, subject 2 has a row for the pre value, but no row for the pst value. In the transposed data set, SAS will put a missing value code for pst for subject 2 in the transposed data set.

data original;
  input a b $ c;
cards;
1 pre 1
1 pst 2
2 pre 3
3 pre 5
3 pst 6
;
proc transpose data=original out=transposed prefix=time;
  by a;
  id b;
  var c;
run;
proc print data=transposed;
run;

The transposed file looks like this:

Obs    a    _NAME_    time0    time1

 1     1      c         1        2
 2     2      c         3        .
 3     3      c         5        6

In all of the examples seen so far, a single column of data (c) is converted into two (or six) columns. You can convert in the opposite direction, gathering two or more columns into a single column by specifying two or more variable names in the VAR statement.

data original;
  input a pre pst;
cards;
1 1 2
2 3 4
3 5 6
;
proc transpose data=original out=transposed;
  by a;
  var pre pst;
run;
proc print data=transposed;
run;

The transposed file looks like this:

Obs    a    _NAME_    COL1

 1     1     pre        1
 2     1     pst        2
 3     2     pre        3
 4     2     pst        4
 5     3     pre        5
 6     3     pst        6

If you have a complex data set, such as one multiple outcomes spread across mulitiple times, you can still use PROC TRANSPOSE, but it is easier to transpose each outcome separately and then combine the results. You may need a bit of “trial and error” as it is difficult to put up examples of every type of option that you might want when your data is very complex.

Obs    a    _NAME_    time0    time1

1     1      c         1        2
2     2      c         3        4
3     3      c         5        6

The SAS System      23:35 Wednesday, March 28, 2018  10

I’m teaching a couple of classes, Introduction to R and Introduction to SAS, and I’m finding that students will turn in homework a variety of different ways. I’m fine with this up to a point, but I think that I should encourage a simple uniform approach, because out in the real world, your boss or your clients will not appreciate a haphazard and disorganized approach. Here’s a suggested format for homework assignments that will (hopefully) get you in the practice of turning into things in an organized fashion.

Here are some guidelines for submission of your homework. Do not follow these guidelines slavishly, and if you have a good reason to ignore one of these recommendations, you will not be penalized. Try, however, to follow these guidelines as best you can. In the real world, you will find that your boss and your clients will appreciate an organized and consistent format.

Every assignment that you turn in should have a report of one page or less. The report is followed by tables, figures, and appendices.

Write your report in plain English with no formulas, no jargon, no computer code, and no raw output. Include the verbatim text of the homework assignment as part of your report, but use a style such as bold, italic, indentation, etc. so it is clear what you have written and what you have copied from the homework assignment.

Your report should have a header with your name, the name of the class, and the name of the homework assignment, and a date.

Your report should be short. Normally one page is sufficient, and for some assignments, you may need as little as a couple of sentences.

If you have graphs, they should be numbered and appear one per page with a brief descriptive title. You can put two or more graphs on the same page, but only if your intent is to compare or contrast those graphs in your report. The interpretation of your graph belongs in the main section and not with the individual graphs, with the possible exception of a brief title or a few labels on the axes or in the graph itself. If a graph that does not warrant a comment in your report, put it in the appendix or (better yet) leave it out entirely.

Each table should numbered and appear one per page with a brief descriptive title. With very rare exceptions, no table should take more than a single page. You can put two or more closely related tables on a single page, but only if your intent is to compare or contrast those tables in your main section. The interpretation of your tables belongs in the main section and not with the individual tables, with the possible exception of a brief title or a few footnotes. If a table does not warrant a comment in your report, put it in the appendix or leave it out entirely.

If you do not know how to interpret a graph or table that you generated, please post a question  in the trouble shooting section of the discussion board.

Your appendix will consist of the data dictionary for the raw data that you used and a changelog file if you made any changes to the raw data. You do not need a data dictionary for any files that you create as part of your homework assignment.

Also include the program code and the unedited computer output as separate appendices. For SAS, you should also include the log as a separate appendix. For R, include your code as a separate appendix, even if you are using R Markdown. For SPSS, make sure that you include the generated syntax with the output, but you would normally not have any code in SPSS if you are using the menu system.

If you use multiple programs to complete your assignment, you can use multiple appendices, but take care so the number of appendices does not become excessively large.

Do not submit any code, log, or output that has error messages in them. If you are getting an error message that you cannot fix, please post a question in the troubleshooting section of the discussion board.

If your code produces warnings, explain what those warnings mean and why it is safe in your particular context to ignore them.

If your output includes a printout of your raw data and/or your modified data, please print only the first ten rows and the first five columns of data. If clarity mandates a larger printout, you can exceed these limits but try your very hardest to keep to a single page for each data set. Please do not print out any intermediate data sets.

Each appendix should have a descriptive title.

Combine the report, tables, graphs, and appendices into a single file. I prefer PDF format, but will take html, doc/docx, or ppt/pptx files. Other formats may be okay, but ask me first. If you have trouble combining your files, please post a question in the troubleshooting section of the discussion board.

I will try to create some simple examples of what a homework submission should look like.

I’m teaching an online workshop for The Analysis Factor on survival analysis. It’s not announced yet, and I have a LOT of work to do before it is ready. One thing that will save me time is that I am taking many of my examples from the excellent textbook, Applied Survival Analysis Second Edition. One nice perk of this book is that the helpful folks at UCLA have taken every textbook example, and written up code (with comments!) to reproduce the book’s results. With the exception of a few advanced methods in later chapters, where only one or two software packages have the right capability, the code is written in parallel in R, SAS, SPSS, and Stata. They also have links to the raw data at the publishers website, and datasets stored in SAS format and SPSS format. How nice! Browse around and you’ll find software code for all the examples in other popular statistics textbooks as well.

Warning! The R examples look like they are from the first edition, not the second edition. A small nitpick for an otherwise very nice resource.

UCLA Institute for Digital Research and Education. Textbook Examples Applied Survival Analysis. Second edition by David W. Hosmer, Jr., Stanley Lemeshow, and Susanne May. Available at https://stats.idre.ucla.edu/other/examples/asa2/.

I got a question about how to export a graph in SAS to a program like PowerPoint. There are several ways to do this, and I explained that you can right click on any graph that appears on your screen and copy it to the clipboard and then open up PowerPoint and right click on a slide and paste it in. That’s fairly standard on any Windows system. I presume that SAS supports similar approaches on the Macintosh and Linus, but I have no easy way of testing this.

But there are other ways to export a graph. You can tell SAS to save a particular graph to a file and then you can import that file into PowerPoint. It works, but there is a twist.

I found a really simple example of saving a SAS graph as a file, and I adapted the code. It takes advantage of the very useful built-in data sets. Thank you SAS! Here’s’ the code.

* graph_export.sas;
* written by Steve Simon;
* March 23, 2018;

ods graphics off;
filename grafout 'c:\temp\temp.gif';
goptions reset=all gsfname=grafout gsfmode=replace device=gif;
proc gchart data=sashelp.class;
vbar age / discrete;
title 'Age Distribution for Students';
run;
quit;
filename grafout clear;

It didn’t work and it took me forever to figure out why. Let me show you what the log window looks like when you run this on my system.

NOTE: Writing HTML Body file: sashtml.htm
NOTE: 8894 bytes written to C:\Users\simons\AppData\Local\Temp\SAS Temporary
      Files\_TD9268_KC-MED-917PFJ1_\gchart.gif.

It appears that SAS is creating an html file, which is okay by me, but it is also creating a graphics file, gchart.gif, buried deep in the bowels of my computer’s temporary file structure. You can traverse that bizarre path,

C:\Users\simons\AppData\Local\Temp\SAS Temporary Files\_TD6560_KC-MED-917PFJ1_\

and you’ll find the file, but I want it in a folder that I choose and I want to give it a name that I like. You have to google this to get an answer, but apparently the default, at least on my system, is to override the goptions statement when you are producing results using HTML and not creating a listing.

I’m guessing a bit here, but I think that a listing is the old-fashioned way of displaying SAS output and HTML is a more recent innovation (though more recent probably means sometime in the late 1990′s). More recent than either is ODS, which I have already mentioned, though very briefly.

If you want goptions to work, you have to change how results are displayed in SAS. You do this from the menu. Select TOOLS | OPTIONS |PREFERENCES and click on the RESULTS tab. Make sure that the CREATE LISTING option is checked. You can leave the HTML box checked to give you an old work and a new world view, if you like, or you can live in the Stone Ages with just the listing output. There are some other interesting options that I want to experiment with when I have time.

Anyway, with the CREATE LISTING option checked, you get the following log.

NOTE: 8797 bytes written to c:\temp\temp.gif.

And if you navigate to the temp folder, you’ll see the file you want. Hooray!

I don’t use SAS that much anymore. Not because it’s a bad program. Mostly it’s because it’s hard to keep on top of too many statistical packages all at once. But I’m teaching an Introduction to SAS class this semester, and I need to keep up with recent innovations. One of the more important of these is ODS, which is short for Output Delivery System. ODS allows you to customize the output using formats like HTML, RTF, PDF, or PostScript. ODS also produces PowerPoint and Excel files.

ODS also allows you to customize how your output appears. Finally, ODS makes some big changes to procedures that used to only produce printed output. With ODS enabled, these procedures will add in extra high resolution plots, which you can also customize.

I do not know if the Introduction to SAS class should incorporate ODS or not. It’s similar to asking if the Introduction to R class should incorporate markdown documents or not. In general, I tend to think that we should teach plain vanilla versions of SAS and R, but I do worry that we may be missing something important if we don’t teach ODS or markdown.

SAS. Getting Started with the SAS 9.4 Output Delivery System. Last updated: September 28, 2017. Available at http://documentation.sas.com/?cdcId=pgmsascdc&cdcVersion=9.4_3.2&docsetId=odsgs&docsetTarget=titlepage.htm&locale=en.

I’ve gotten some helpful feedback that I need to encourage more interactions among students in the on-line classes, Introduction to R, Introduction to SPSS, and Introduction to SAS. No just interactions of the students with the teacher, but interactions between the students.

In many online classes this is done by encouraging online discussion of the material in the class. This is not so easy, however, for these three classes. I can just imagine myself posting the following on Blackboard. “Tell me what you think about the read.csv function in R.”

There are a couple of ways, however, that make sense for technical classes like these.

An obvious strategy is to encourage students to comment on anything they find confusing in the videotaped lectures. For example, as student might say

“I got a strange error message when I tried to import the dataset with “read.csv(file=fn, header=TRUE)”

When you see this, rather than answer it right away, ask

“Did anyone else have this problem?”

Then wait a bit. If you’re lucky, another student might chime in and say

“I had that problem also, but when I stripped the first line from the file, and changed the option to “header=FALSE” it worked just fine. Except, I lost the variable names for each of the columns of data.”

Then another student might chime in and say

“I got the variable names back by cut-and paste of the first line into the R program itself. I had to reformat a bit, but it worked nicely.”

That’s the theory, anyway. It mimics the situation in a class where one person asks a question, and another student answers the question before the instructor can (which is ideal from the instructor’s perspective).

Now, it is hard to get students to offer commentary, either online or in a live class, but that’s something that you need to encourage if you want to be a good teacher. I must confess that I am not nearly as good at this as I should be. I tend to dominate any classroom discussion, to the detriment of myself and my students. But I’m working on it.

Another strategy for encouraging student interactions is to require peer-grading of assignments. These are pass/fail classes, so I’m not interested in a grade per se. What I want is some helpful commentary about the good things and bad things in another student’s assignment.

Again this is tricky for a programming class. Someone shares the code they used and the output that the code produced, and what is there to comment on other than the trivial comment that it worked.

One thing that you can get one students to critique about another student’s work is the quality of the documentation. One thing these classes need to emphasize more is placing a greater emphasis on documentation.

So a student might submit a project where they imported a text file, created value labels, and recoded obvious outliers as missing values. The first student submits their code and output, but also their data dictionary and their changelog. The second student provided feedback by answering the questions

1. Did you understand the information in the data dictionary?
2. is there any information that you wanted to see in the data dictionary that wasn’t there?

In order for peer evaluation to work at its best, you need to make sure that the second student is not working on the exact same data set that the first student is working on. It’s easy to overlook a poorly documented data dictionary for a data set that you’re already intimately familiar.

Fortunately, there are so many open source data sets out there that it won’t be hard to give each student a different data set to work on.

A second thing that one student can critique about another student’s work is the quality of the interpretation of the output. This requires a change in emphasis again. These classes do ask for interpretations when appropriate, but when the output is just a two by two crosstabulation like

       Dead Alive
Female  154   308
Male    709   142

there’s only so much you can say. So these classes need to incorporate things like a Fisher’s Exact Test for any two by two crosstabulation, so that students can say that males have a statistically significant increase in mortality in this data set compared to females.

I don’t want to go too deeply into statistical tests in these classes. My goal is to teach coding, not statistics. But adding a few more tests and confidence intervals, very simple ones, will allow for more interesting interpretation of the output.

So assignments should ask for the output and the code (for R and SAS) and the log (for SAS). But it should also ask for a brief report (no more than one page) interpreting the results. When the first student submits the report, ask the second student to address the following questions

1. Did you understand the interpretation provided?
2. Was it consistent with the raw output?
3. Was there anything else you wanted to see in the interpretation?