You do NOT show your entire PROC REPORT code or your SAS log. These would be helpful. Generally, however, one reason that a COMPUTE block does not work is that you have made some assumption that is in error because you either ignore or don't understand the left to right order of processing of the items in your COLUMN statement. Let's take a simple example:
proc report data=sashelp.class nowd;
column name numvar age sex height weight;
define name /order;
define numvar / computed;
define sex / display;
define age / sum;
define height /sum;
define weight /sum;
if sex = 'F' then temp = height.sum * weight.sum - age.sum;
else if sex = 'M' then temp = height.sum*weight.sum;
numvar = temp;
For example, in the above code, you will NOT get any errors in the LOG, but the column for NUMVAR, which you want to compute conditionally using a temporary variable TEMP ( based on the value for the SEX variable) will just contain missing values -- because NUMVAR is in the COLUMN statement before AGE, HEIGHT, WEIGHT and SEX -- all of which are needed for the correct computation of TEMP and NUMVAR. Since PROC REPORT builds report rows by placing report row information from LEFT to RIGHT on the report, the column for NUMVAR is placed before the columns for SEX, AGE, HEIGHT or WEIGHT. Therefore, when the COMPUTE block for NUMVAR executes, it's as if there was NOTHING to test and nothing to multiply.
In order to generate a value for NUMVAR, the correct order of items in the COLUMN statement is:
column name age sex height weight numvar;
This would be the ONLY thing you have to change to make the above program work.
Remember that the PROC REPORT method of building a report is NOT like the DATA step method of operating...for example, there is NO Program Data Vector and no "buffer" areas ... each report row is built one item (column) at a time, from left to right. So, for example, in the above COLUMN statement, when the value for AGE is placed on the report row, there is no visibility of the value for SEX or HEIGHT on the same row. However, by the time NUMVAR needs to have its COMPUTE block executed, all the other variables have been placed on the report row, so they are available for use in the calculation of NUMVAR.
And, just as an FYI, depending on your ODS destination, techniques like @2 and +2 typically do not work for ODS HTML, ODS RTF and ODS PDF -- they are LISTING only techniques .. so if your ultimate destination is something other than LISTING, you may want to use different techniques for placing your LINE output.
If you were willing to post ALL your REPORT code and a sample of fake data or a program that made fake data, it might be possible to help you figure out what was going on. If it's not the order of variables on the COLUMN statement, then I'm betting that it's some combination of ORDER/GROUP items that's making reccnt.sum not available at the break on entryid. Also, do note this restriction statement from the PROC REPORT documentation about LINE statement execution:
You cannot use the LINE statement in conditional statements (IF-THEN, IF-THEN/ELSE, and SELECT) because it is not executed until PROC REPORT has executed all other statements in the compute block.
LINE statements cannot be conditionally executed in a compute block. This is very different from PUT statements in the DATA step. Here both of the LINE statements will be executed regardless of the value of RECCNT.SUM.
The effective form of your compute block becomes something like:
line ' ';
Thanks to all that replied (DataNULL, Cynthia and ArtC) for your time and knowledge. The sharing of knowledge is invaluable and much appreciated. I learned many new things about proc report. For example I was unaware of the left to right order of things and that you cannot conditionally use the LINES statement in a compute statement.