Bug in *report with -fp

[Bruce Easton]

Bill Akers wrote Wednesday, March 14, 2007 10:14 AM:
[..]
> In effect, you are replacing the normal report format with a 
> processing only format that generates no report but performs some other 
> type of procedure..

Well that's your take on it - and I think it's a good one.  But one could 
just as easily say that in effect you are simply running processing and 
using no format at all - not replacing anything. More importantly, someone 
who started using this flag and observing its present behavior certainly 
might not see it as you do.  Thus my concern for backward compatibility.

> Ergo, if fp complains about a non-existent output 
> format it should, by default, assign the same behavior to  a 
> non-existent processing table that is used as the output format.

That would have been a nice behavior from the start, but that's not 
the way it has been, thus my concern for backward compatibility.

> It is difficult to believe that anyone is running a routine which 
> generates no report and performs no processing, on purpose. Therefore, 
> the argument that someone's programming would be somehow corrupted 
[..]

Well, mabye you missed my example involving how a cron job, where if 
the behavior were to switch to generating an error, and the developer 
didn't consider the changed behavior as a potential problem, they 
might spend hours trying to find out why their cron job got hung.  I 
admit that my example is what many might see as not a conventional 
use of filepro, but we have often seen these kinds of techniques 
implemented.  And that's why, even though I really don't consider 
this to be a big issue, I think it's very important to always consider 
backward compatibility when changing any existing behavior.

And yes, if the behavior changes, I would expect an environ. variable 
to allow the current behavior - even if the current behavior didn't 
make any sense to me - all for the sake of guess what - backward 
compatibility.

Bruce

Bruce Easton
STN, Inc.