Well, I have to respectfully disagree with @Ksharp that SQL is the "easy" way to do this, especially for real-world problems where there are lots of variables or lots of levels.
I do understand that %TABLEN may not be that easy either, but it will work on real-world problems with lots of variables or lots of levels, but you have to climb up the learning curve, just as you would with doing it in SQL. Once you learn it, then it will work for you on all future problems easily. With SQL, each time you want to use it on a new problem, you have to write new SQL.
In my opinion, the real easy solution is to not insist on a the poor display format of 1185(42.1). which I find difficult to read and for which the numbers in the columns don't align, making the numbers difficult to compare. Put the percents and counts side by side in two separate columns, on the same row, PROC REPORT makes that easy (example from my own work shown below where I have changed the column headings to protect confidentiality); OR keep them in the same cell as PROC FREQ does. Please also note that in the outputs from @Ksharp and the outputs from %TABLEN, the numbers are not vertically aligned, but in my output from PROC REPORT below, the numbers are vertically aligned.
Few people seem to care about making the report readable and clear; most people seem to care only about getting the program to work. I care about making the report readable and clear, and in my opinion, everyone should care about this. (And as long as I am on this subject of making reports readable and clear, counts greater than 999 should use the COMMA format, so 1,276 appears and not 1276 without the comma)
... View more
