On our test system the page prints and does a Form Feed to the next page. This is good.
When I release the program to our customer it prints the page but waits 5 or more seconds before doing a page throw. They say the the final FF delay is unacceptable.
Any ideas where to start? I have experimented with SEQUENTIAL and LINE SEQUENTIAL files but I feel that it is a configuration issue (BSD queue).
Name of queue qrintronix
ACTIVATE the queue? yes +
Queuing DISCIPLINE first come first serve +
ACCOUNTING FILE pathname [FALSE] /
HOSTNAME of remote server [printronix]
Name of QUEUE on remote server [d1prn]
Pathname of the SHORT FORM FILTER for queue [/usr/lib/lpd/bsdshort] +/
status output
Pathname of the LONG FORM FILTER for queue [/usr/lib/lpd/bsdlong] +/
status output
Have you tried adding a form feed just before closing the print file. Test if doing this will cause the printer to immediately do a form feed, and then not add its own form feed when it (the printer) finally realizes there is no more data coming and goes to top of form.
Thanks for that. I just tried it (WRITE NOTE-PRN-REC BEFORE ADVANCING PAGE) and it gives me the required form feed immediately - but then it throws another (unwanted) page...
Are you printing one page at a time (invoice/packing slip/etc)? Is there a tear off function on the printer? If you tear off the printed form, and press the top of form button on the printer, does the printer suck the unprinted form back so that no forms are actually wasted. And is this behavior different than the test printer that you used?
Hi Jack,
This is a Delivery Note print program. Sometimes one Delivery Note (running to 1 or more pages) is printed, sometimes many Notes (many spool files with around 1-5 pages each) are printed. The printer (a Printronix PSA3) does not suck unprinted forms back. The development printer and customer printer are the same model.
Since the print method is LPR/LPD is it possible to print on the production printer from the test cpu and on the test printer from the production cpu?
Is there a way to stop the printing from starting until the file is completely received by the printer. In other words bury the 5 seconds in the beginning of the print job.
Thanks for your advice. I am not sure how to do that at the moment. I think I will now try to get a queue set up in my office that exactly mimics the customer's queue. If I can reproduce the problem I may be able to spot the difference(s) between the queue configurations. If not, I will follow up your suggestion. Many thanks.
Assuming that there is more than one different printer.
For elimination have you tried printing from the test system to the live printer and from the live system to the test printer? Are there differences in the physical printer's settings for the idle timeout between live and test printers?
Thanks. We are comparing the queue settings now. Might be some sort of "delay" setting.
We have yet to try printing to the customers printer from our office as they do not have someone available at the moment.
Interestingly, I have been told that it has been found that if the filename is shortened (renamed) to x.x it will print without a delay...bizarre!
---------- Post updated at 12:39 PM ---------- Previous update was at 11:31 AM ----------
It does not seem to be the physical printer settings as the two test printer queues we have set up here behave differently. On the BSD queue there is no delay before the FF. On the other queue (set up us AIX) there is a delay...
Can anyone advise me regarding any of the following to do with this issue. It is becoming very high priority and I'm stuck...
Shorter pages wait before the final form feed. Longer ones usually do not. Why would this be?
Is there a Printronix start/end page control sequence I should've been issuing? I don't see any notes about this.
On our test system, issuing an lp command (from Unix prompt) after having done a cd to the directory seems to make it print without a pause. Introducing the folder name before the filename causes the printer to wait. Are there any known bugs/limitations with printing (and service packs to fix the issue)?
No, I didn't. After even more testing I found that the customer's Production system did not have this issue - only their Test environment does. No one has any idea what the difference is! The customer is happy that there is no delay in their Production environment and so has accepted the software. I'd love to know what causes it.