lp - order of files printed

mabrownawa · February 10, 2004, 7:40pm

I have a shell script that is looping through a list of Postscript files to print.

ls -1tr *.PS > print.lst
...
PRINT_LIST=`cat print.lst`
...
for DMFILE in $PRINT_LIST
do
lp -d $PRINTER_NAME -o legal $DMFILE
...
done

The files in print.lst are in the order that they should be printed, however the order in which the files are printed appears to be completely random.

Here is a sample of print.lst, sequenced in the order to print

/prtspool/racprint/debitmemos/MNSF021.M0209137.PS
/prtspool/racprint/debitmemos/MNSF021.M0209138.PS
/prtspool/racprint/debitmemos/MNSF021.M0209139.PS
/prtspool/racprint/debitmemos/MNSF021.M0209140.PS
/prtspool/racprint/debitmemos/MNSF021.M0209141.PS
/prtspool/racprint/debitmemos/MNSF021.M0209142.PS
/prtspool/racprint/debitmemos/MNSF021.M0209143.PS
/prtspool/racprint/debitmemos/MNSF021.M0209144.PS

Here is the output from lpq:

active racuser 619 MNSF021.M0209137.PS 20200778 bytes
1st racuser 627 MNSF021.M0209145.PS 16781507 bytes
2nd racuser 621 MNSF021.M0209139.PS 20925819 bytes
3rd racuser 625 MNSF021.M0209143.PS 17315067 bytes
4th racuser 607 MNSF021.M0209125.PS 20202748 bytes
5th racuser 633 MNSF021.M0209151.PS 16825285 bytes
6th racuser 628 MNSF021.M0209146.PS 17372512 bytes
7th racuser 629 MNSF021.M0209147.PS 17078571 bytes
8th racuser 606 MNSF021.M0209124.PS 20928279 bytes
9th racuser 610 MNSF021.M0209128.PS 20928424 bytes

Why are the files printing in this seemingly random order? Is there a way that I can force the files to print in the order submitted?

Thanks, MB

RTM · February 13, 2004, 8:21am

There may be a couple of reasons - but since you didn't post the OS and version, I'll just have to hope this also applies to your OS (it probably does)

As implemented, the Solaris Operating System's (versions 9,8, and 7) LP spooling subsystem for receiving inbound print jobs, releases print jobs based on when they finish arriving versus when they were actually submitted (for performance reasons). Consequently, a small job submitted second from a client computer may actually arrive first and be released to a physical print device before a large job that was submitted first. This scenario has also been inherit to many other LPR/LPD printing implementations because their original designs all use at least 11 "logical ports" for sending data (LPR requests). Unfortunately, in some implementations, the receiving side (LPD) has not always taken responsibility for FIFO, either as a part of the standard design or as an option. This presents major operational problems in "statement", "invoice", and "check" printing environments.

What makes this problem particularly elusive and troublesome is the fact that by "chance" FIFO is generally maintained under Solaris LP. However, it is NOT guaranteed and is evident primarily when extremely small print jobs (<= 50 Kbytes) are intermixed with more normal or large sized print jobs. This problem has been discussed with Sun and they stand behind the current design and do not consider it to be a defect.

(quote from FIFO of print jobs )

And if I remember correctly, print queues will usually print smaller files first (no matter the OS) - could be a problem on a different print queue than just your OS. You need to also mention the how's and where's - is this a UNIX only print queue or does it ship it off to a LAN/WAN print queue in NT or some other OS?

You might look to see if there is a hold option for your lp command - if so, putting all printjobs on hold and then releasing once they are all there may solve your problem (you will still need to check that it's not going to re-arrange the jobs by size).

mabrownawa · February 16, 2004, 11:08am

Thanks for the followup, RTM. Sorry about the missing information. This problem is occurring on Solaris 8. Your response makes sense in that these files can vary in size.

Only one type of print is sent to the print queue in question. Typically, a large number of debit memos are sent to be printed at one time. The order is important to the people who process the debit memos. In an attempt to rectify, I have put a wait into the script between LP statements, hoping that the delay will allow the file to be processed and the order to be maintained. Seems to be working fine so far, but the sample size is small.

MB