@saslove
Some PROC's support reporting tables ordered the same as the incoming data. For instance PROC FREQ, PROC TABULATE, and PROC MEANS (and the DEFINE statement in PROC REPORT) honor the "ORDER=DATA" option. So, without resorting (pun intended) to formats, you could create a data set view (as opposed to a data set file) with data from your original dataset processed in the desired order, which then can be submitted to the proc, as in:
data vtemp /view=vtemp;
set sashelp.class (where=(sex='M')) sashelp.class (where=(sex='F'));
run;
proc tabulate data=vtemp order=data;
class sex;
var height weight;
tables sex all='Total',
(height weight)*(mean N);
run;
Here I've prevented the default behavior of PROC TABULATE to have the row with sex="F" precede the row with sex="M". And remember, the data set view (VTEMP here) is merely a process, it does not write data to disk, so this is a fairly efficient approach (certainly faster than actually sorting the data) The actual data is processed only when the view is named in a subsequent step.
You don't even need to order the entire dataset. You only need to order the first encounter with each value of interest. I.e. in my example, you can just write one dummy record with sex="M" followed by a second dummy record with sex="F" preceding the original dataset of interest, as in:
data vtemp2 /view=vtemp2;
if _n_=1 then do sex='M','F'; output; end;
set sashelp.class;
output;
run;
proc tabulate data=vtemp2 order=data;
class sex;
var height weight;
tables sex all='Total',
(height weight)*(mean N);
run;
The downside with the 2nd solution is that I've added 2 observations not in the original data set, which would generate erroneous results if all I wanted was a frequency table of SEX. But PROC TABULATE doesn't care in this case, because I asked it to analyze height and weight (missing only in the added obs) classified by sex.
There are ways to avoid this problem too, but I've gone far enough.
