Bug in *report with -fp

[Bruce Easton]

Mark wrote Tuesday, March 13, 2007 2:31 PM:
>
> > Bruce wrote:
> > Why would a reason for forming an fp-executable line with an
> unresolvable
> > processing name for use with -y, -z, etc. be any better reason than
> > forming an fp-executable line with an unresolvable PROCESSING name for
> > use with -fp?
>
> Because there's -something- to do.  It may not have processing to use, but
> it's still got an output format, and thus something to do.  With use of
> just -fp with a non-existant table, effectively there is -nothing- to do.
> It's like calling clerk without a screen; would you find it acceptable for
> it to just exit silently without telling you what's up if you
> omit a screen
> name or give it a bogus one?  I wouldn't.
[..]

But filePro can run where there is nothing to do.  Not that I advocate
using it this way, but maybe someone who started using filepro
just after the advent of -fp like to stand at the command prompt
of and use a command string with *report <filen> -fp nnnnnn -a to see how
high the records count up on larger files?  Who knows?

Maybe this same person designed a posting protection script that runs from
cron and moves processing tables out of the way at certain times of the
day so that users cannot affect files normally affected by them.
Who knows? (Again, not that I would design something in that way,
but my point is in small minor things like this, backward compatibility
is paramount - and that's the only reason I felt compelled to keep it
alive.)

> Personally, I don't care one way or another what happens from here on out.
> They can leave it or change it.
[..]

I really don't either, Mark, as long as any change is backward compatible -
even if someone will have to use:
PFLEAVEMINUSFPTHEHECKALONE=leaveminusfptheheckalone
and it's documented :)

Bruce

Bruce Easton
STN, Inc.