Folks,
Have a SCO OpenServer 5.0.5 legacy box on site that has run our legacy ERP system for about 15 years now. Primarily uses an Okidata 321 ML Turbo line printer (defined as 'printer') attached to the system's parrel port at /dev/lp0. System primarily operates as a terminal server with clients using vt220 emulators.
Printing has been working OK for the life of the machine, but it appears about a month ago that the printer suddenly stopped actually printing. However, SCOADMIN confirms the configuration is still correct...
Print commands from the ERP system (or from simply printing a file, i.e. lp somefile.txt) send documents to the print spooler OK, but nothing happens from there, and whatever is in the queue sits there. Probably worth noting that this printer has a plainly visible alarm when it has an issue, such as being out of paper, misfed, etc. and there is currently no active alarm.
Here are some command-line results that may help:
# lpstat printer
printer-##### <username> 12345 Nov 18 15:14
# lpstat -t
scheduler is running
system default destination: printer
device for printer: /dev/lp0
printer accepting requests since <date>
printer printer waiting for auto-retry. available.
stopped with printer fault
.
.
.
So far, tried clearing out the queue, restarting the services (lpshut / lpsched), rebooting, checking connections / cables to no avail. My guess is the issue is that the server isn't 'seeing' the printer, especially as when SCO boots up when the printer is on and connected, it typically makes a few whirring and clicking noises corresponding with the boot sequence, which no longer occur. It would make sense then that spooled docs would sit there forever until they have a printer to process to.
In the above example, a job I ran from the command-line is active in the spooler. A cancel command will properly kick any spooled documents out.
Anything I'm missing? Any help would be appreciated...