lpsched tends to stop responding, and lpd seems to decide it doesn't feel like processing any jobs after a while. Killing lpsched and lpd then re-starting lpsched seems to solve the issue ... for a while.I eventually got sick of it, and replaced the SCO print system entirely. I would've liked to use CUPS, but getting even the CUPS client to build on SCO was going to be an exciting effort in porting. The fact that one of the SCO patches broke the C compiler didn't help any, either.
In the end I wrote a simple Python script to relay print data to a Python server running on a modern Linux box, where the print data is handed to CUPS for printing. Since replacing the print system on the SCO box I've not had to intervene to fix SCO printing even once.
On the chance that others are stuck running this elderly operating system for their own scary legacy apps, I'm publishing the scripts here as a base for others to adapt to their own uses.
This print client program should be called instead of "lp" on your SCO box. It requires Python 1.5 from Skunkware to be installed. You should probably leave the original
lp in place, instead adapting your PATH or your client apps to call this by preference.The command line processing in this client program is incredibly simplistic. It expects to be called with a print spool file name, and optionally -dPRINTERNAME to specify a queue. It doesn't understand any other arguments. If you need more functionality, you'll have to extend the protocol and client.
https://github.com/ringerc/scrapcode/blob/master/scripts/sco_openserver505_replacement_lp/lp.py
No comments:
Post a Comment
Captchas suck. Bots suck more. Sorry.