Hello Kim,
proc report does present some problems when it comes to creating a subtotal function. The first part of the problem is detecting which row the subtotal starts on, and then, where it should go when the time comes.
If you know how many rows you have, then we can send a formula as a sytle over ride on the break. Being proc report, we could count the rows. But all of that seems like a lot of work. But it would work and work well.
We could modify the tagset so that it could signalled, where to start, stop and where the subtotal should go. Using a style over ride like we do for rotate, format, formula and type, could enable us to do everything you want. The only difference is the tagset would do the counting, and keep
track of which columns get subtotals.
The problem is that proc report has to tell the tagset where to put the subtotal and what rows to put in the subtotal().
Fixing up the tagset to follow guides
given as over rides would work well. But it does take some proc report code to make it work...
With proc print, it is still a little touchy and doesn't always work. The tagset is doing it's best to guess. Multiple totals, and bygroups that
mix in the same table will break it. The way it guesses is it looks at
the table section. Anything that is in the foot portion of the table is a
total. It also starts counting at the first row under the headers. So it knows where everything starts. This is not a perfect methodology. But
it works most of the time.
We've discussed having proc print and report give better clues so that the
tagset can accurately and automatically add subtotal functions. But that will not be investigated until the SAS release after this next one.
Because the tagsets are malleable, we can make them do just about anything.
Let me know if you would like to investigate these idea's. Ultimately proc report is much more capable at doing this sort of thing than proc print.
So there are more options available to us.