no input files message from printer file

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-
> bounces+gccconsulting=comcast.net at lists.celestial.com [mailto:filepro-
> list-bounces+gccconsulting=comcast.net at lists.celestial.com] On Behalf
> Of Scott Walker
> Sent: Sunday, January 06, 2008 5:05 PM
> To: 'Fairlight'; 'FilePro Mailing List'
> Subject: RE: no input files message from printer file
> 
> 
> 
> -----Original Message-----
> From:
> filepro-list-bounces+scottwalker=ramsystemscorp.com at lists.celestial.com
> [mailto:filepro-list-
> bounces+scottwalker=ramsystemscorp.com at lists.celest
> ial.com] On Behalf Of Fairlight
> Sent: Sunday, January 06, 2008 1:11 PM
> To: FilePro Mailing List
> Subject: Re: no input files message from printer file
> 
> Simon--er, no...it was Barry Wiseman--said:
> > That message is generated when filepro closes the pipe to lp to
> direct
> 
> > print output instead to your file.  I believe if you first issue a
> > "printer reset", then the "printer file" command, that will prevent
> the
> > message.
> 
> 
> Mark said:
> 
> I'm still not getting it.  I may not be the OP, but I don't see how any
> of
> the answers concerning "what has to be done to get lp to stop printing
> that
> message" have been relevant so far to his problem.
> 
> FROM the docs:
> 
>      PRINTER FILE "filename"
>                         Send output to file "filename".
> 
> I have used this feature myself on Windows 2003 Server with fP 5.0.14
> to
> send output directly to a file, do not pass Go, do not collect $200.
> It's
> then handled by PrintWiz to convert to PDF for download.
> 
> Key thing being, it does not even -attempt- to print anywhere but to
> that
> file, nor should it.  No spoolers, no programs--nothing except the
> file.
> 
> So far, I'm failing to see where `lp` or any other print spooler should
> even remotely be in play while using PRINTER FILE.  Emphasis:
> ***FILE***.
> 
> Now, my very salient question is:  Why/How is `lp` getting called -at
> all-
> from PRINTER FILE?  When we know the answer to that, we'll have a
> reasonable chance of providing a sane solution that works.  There are
> only
> a few ways I can think of this happening:
> 
> 1) There's a bug in fP at whatever release the OP is using, and PRINTER
> FILE is broken there, and does indeed try `lp`.  I kind of doubt this,
> as
> this feature goes back -at least- to one major version prior.  Pretty
> sure
> this was in 4.8, so I can't see it being left that buggy that long.
> 
> 2) There's some sort of printout-inducing command that is getting
> triggered
> before or after PRINTER FILE, and it's a flaw in processing with a
> drop-through (no END somewhere?) either before or after...somewhere.
> 
> 3) It's a case of *report being called and using PRINTER FILE in a
> process
> table, and -that- goes to file, but *report thinks it should be
> printing
> something to a printer for the current record or what have you.
> 
> Those are the three most logical explanations that come to my mind.
> 
> I just fail to see how multiple people telling someone how to fix lp is
> helpful when lp shouldn't even be in play at all with this command.
> It's
> not addressing a primary root issue.
> 
> No flame intended...I just want to see Scott get a real answer, and
> none
> of
> the discussion so far seems to be headed in that direction.  At least
> not
> to me, it doesn't.
> 
> mark->
> 
> 
> 
> Scott says:
> 
> Mark, I may be mistaken but I seem to remember fp creating some empty
> files and handing them to lp when you use the "printer" commands in
> rreport.  I think I was told that what happens is by the time fp
> encounters the "printer" command it has already opened a print file.
> 
> I seem to remember seeing this when I would use "printer name" on a prc
> table, that was run with rreport, to change the printer that the report
> would go to.  I would end up with (2) print jobs in the spooler.  One
> was zero length.
> 
> I may be totally mis-remembering this but I thought it might be
> relevant.
> 
> Regards,
> 
> 
> Scott
> 
> Scott Walker
> RAM Systems Corp.
> ScottWalker at RAMSystemsCorp.com
> Ph: (704) 896-6549
> 
Just a thought, can you move the initial processing to a clerk function and
then do system *report filename -f report -p filename

This would eliminate fp opening the pipe to the printer at the start.


Richard Kreiss
GCC Consulting
rkreiss at gccconsulting.net