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...

You need to confirm that you can print through lp0

date > /dev/lp0

Tony,

Thanks for your response - actually I realized the reason while reading your article and hitting the word 'bios'.

This server is a Compaq ProLiant 800 series, which of course uses softpaq instead of a more traditional boot ROM, but I recalled that we moved the server a few months back to a new location and that the BIOS battery was probably long dead (due to the age of the hardware), which would have wiped out the settings once unplugged from AC power.

Sure enough, we had been running this server using the default Compaq settings for SCO since the move, without issue save for printing (which we have not done much of since having migrated to a new ERP system this year). This server requires configuration using the old SmartStart disc set, which then autoconfigured the BIOS again, including initializing the parallel port, which was not being done since the move.