Print job still spooling after FORM command executed

[Brian K. White]

Kenneth Brody wrote:
> Boaz Bezborodko wrote:
>   
>> Kenneth Brody wrote:
>>     
>>> Boaz Bezborodko wrote:
>>>       
>>>> There is an older program on my system that I didn't write.  While in 
>>>> IUA on an invoice record an @KEY command calls a separate processing 
>>>> table to print the invoice.  The table calculates the necessary 
>>>> fields and then generates the printout with a FORM command.  What I 
>>>> noticed today is that the job remains open for spooling in the queue 
>>>> after this is done and the queue doesn't close allowing the job to 
>>>> print until you exit out of IUA.
>>>>
>>>> Apparently it's always acted the same way, but I didn't know this 
>>>> since I don't run this program myself and no one told me about it.
>>>>
>>>> According to my reading of the manual FORM should close the spool and 
>>>> allow the job to print.  What could stop this from happening?
>>>>         
>>> If filePro thinks the output is going to a file, rather than a pipe, 
>>> then it will not close the file after each form.  What is the exact 
>>> destination filePro has been told to use?
>>>
>>>       
>> It is going to a file.  Is there a way to get it to close the file from 
>> within the processing table?
>>     
>
> If it's going to a file, then what is sending it to the spooler?
>
> I forget if PRINTER RESET will force the file to be closed in this scenario, 
> but you can try it.
>   

We do 100% of our printing to file since 4 or 5 years ago with no 
problems and that is exactly what we do.
We always do printer reset and/or printer flush the last thing just 
before anything else is expected to touch the file.
And we definitely have to do that. Whenever someone doesn't, there are 
the expected problems from the file not being flushed or released.

When the printer flush command appeared I started inserting it before 
the reset sometimes but I can't think of any time where the reset didn't 
take care of everything.
I use reset because aside from flushing the write buffer, I want to be 
as super duper sure as possible that the file is released, so if I 
entered clerk/report with -p /dev/null and/or the fp config file has the 
default print destination going to some spooler command or to /dev/null, 
then printer reset not only flushes the pending writes but also breaks 
all connection to the file.

The general recipe is just to use command line options to prevent fp 
from touching or creating any files or start any pipes to the default 
spooler destination as clerk/report starts up, build a unique temp 
filename in a variable, use system() to create that temp file with 
whatever permissions you may need so that your external step later can 
read/modify/delete the file, THEN tell filepro about the file only after 
it's already been created by system() or by anything other than filepro 
itself, with "printer file variable". Then formm's & form. Then printer 
reset. Then your external system command or call table or whatever it is 
that needs to take the output file. Then usually delete the file if your 
external process didn't do that.

rreport ... -p /dev/null -pc nocodes
   then: tf="/path/to/tmp_file_"{rand(){".pcl"
   then: system noredraw "umask 0;>"<tf
   then: printer file tf
   then: printer type "hplaser"
   then: formm "fooa"
   then: formm "foob"
   then: form "fooc"
   then: printer reset
   then: system "echo Do something with"<tf<"here."
   then: x = remove(tf)


Depending on your particular situation various bits of this can change 
or go away.
Maybe you know, or could know, your desired filename in some parent cron 
job or cgi shell script before even calling clerk/report? Then you can 
create the file in that parent shell which is a lot more efficient than 
calling system() from inside filepro. And maybe you will, or could, be 
doing your external thing with the file after exiting clerk/report? Then 
it could go like this:

umask 0
tf=/path/to/tmp_file_${$}.pcl
 >$tf

rreport ... -p $tf -pc hplaser
   then: formm fooa
   then: formm foob
   then: form fooc

echo Do something with $tf here.
rm $tf


Advantage there is, aside from the efficiency of avoiding the 
unnecessary system(), you have a dirt-simple clerk/report processing in 
the middle there and all the temp file handling is done in the 
surrounding shell script and that's all generic, several scripts could 
all have exactly the same code just with a different report dropped in 
the middle, which means really, it could be one script that takes a few 
command line options and the same script could run any number of reports.

-- 
bkw